Systemd-ratkaistu on rikki

Link: http://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is-broken.html

Koko julkistamista, en ole fani systemd. Aloitin Linux-90-luvun lopulla ja katsoin sen kasvaa syrjäytyneitä käyttöjärjestelmä kaikkein hallitseva käyttöjärjestelmä datacenter. Olen elänyt läpi niin monta “year of the Linux desktop” vuotta en muista, kun se ei ollut vitsi. Omasta näkökulmastani, hallinnoinnista Linux-palvelimia ammattimaisesti lähes 20 vuotta, systemd on Linux-työpöydällä hinnalla Linux datacenter.

Miksi tunnen tällä tavalla? Se on lähinnä keksiminen ja virheellisiä toteutuksia ydin UNIX-työkalut ja menettelytavat. Siellä on paljon tietoa systemd siellä. On paljon harhaa mukana. Joten, tänään en aio puhua siitä. Aion käsitellä kriittisen virheen systemd-ratkaista daemon, joka toteuttaa DNS-hakuja järjestelmät systemd.

Hyppään oikeus työ-ympärillä. Jos käytät järjestelmää, joka on käyttää systemd, sinun pitäisi luultavasti olla käynnissä systemd-ratkaistu määritetty käyttämään yhden DNS resolver, 127.0.0.1, ja ajaa Vapaan. On olemassa resursseja, miten määrittää ja ajaa Sitoutumaton, mutta paras on. Elohopeakloridin on Sitoutumattoman Opetusohjelma. Jos sinun täytyy säilyttää johdonmukainen, luotettava DNS-resoluutio, joka on yhteensopiva aiempien versioiden Linux, ainoa tapa tehdä se on saada yksi DNS-palvelimen /etc/resolv.conf.

Miksi Tällä on Väliä

Tämä lanka systemd-ratkaistu selittää asiaa. Kyllä, laittamalla ulkoisia DNS-palvelimia omaan sisäiseen palvelimien /etc/resolv.conf ei ole suuri muodossa, mutta se puuttuu kokonaan kohta altistuvat tämän vikailmoituksen.

systemd-ratkaistu toteuttaa valtion seuranta vastaan kansalaisuudeton protokolla.

Ei vain, että, mutta se tekee sen huonosti. Tapauksissa kuvataan kommenttien, väliaikainen häiriö yhteyden sisäiseen DNS-palvelimet päätyi mustalle listalle niitä loputtomiin. Minun lähes 20 vuotta kuin Linux-admin, olen nähnyt lähes jokainen juniori admin keksiä saman idean sen jälkeen, kun heidän ensimmäinen DNS-katkos, “Miksi emme vain seurata, mitä DNS-palvelimet vastata ja sitten sivuuttaa ne, jotka eivät onnistu?” Se kuulostaa hyvältä, mutta koska DNS on kansalaisuudeton protokolla, jonka suunnittelu, määritetään “työ-palvelin” “ei toimi palvelin” on todella vaikeampaa sitten antaa HTTP-pyynnön tila handler. Se on monimutkaista.

Vanhaa toimintaa

Joten, siellä on paljon väärinkäsityksiä siitä, glibc: n resolver kirjasto, joten toivon, squash vähän ja osoite kuinka useimmat nimi päätöslauselmia toimii useimmissa Linux-järjestelmissä. Kyllä, se on mahdollista käyttää eri resolver kirjasto ja niille kirjastoja ei saa panna täytäntöön päätöslauselma sama. En kuitenkaan halua puhua glibc resolver ja miten se on vuorovaikutuksessa /etc/resolv.conf varastossa CentOS 6 järjestelmä ja joka UNIX-ja Linux-ennen.

Tässä on esimerkki tiedostosta /etc/resolv.conf

Ei vain, että, mutta se tekee sen huonosti. Tapauksissa kuvataan kommenttien, väliaikainen häiriö yhteyden sisäiseen DNS-palvelimet päätyi mustalle listalle niitä loputtomiin. Minun lähes 20 vuotta kuin Linux-admin, olen nähnyt lähes jokainen juniori admin keksiä saman idean sen jälkeen, kun heidän ensimmäinen DNS-katkos, “Miksi emme vain seurata, mitä DNS-palvelimet vastata ja sitten sivuuttaa ne, jotka eivät onnistu?” Se kuulostaa hyvältä, mutta koska DNS on kansalaisuudeton protokolla, jonka suunnittelu, määritetään “työ-palvelin” “ei toimi palvelin” on todella vaikeampaa sitten antaa HTTP-pyynnön tila handler. Se on monimutkaista.

Vanhaa toimintaa

Joten, siellä on paljon väärinkäsityksiä siitä, glibc: n resolver kirjasto, joten toivon, squash vähän ja osoite kuinka useimmat nimi päätöslauselmia toimii useimmissa Linux-järjestelmissä. Kyllä, se on mahdollista käyttää eri resolver kirjasto ja niille kirjastoja ei saa panna täytäntöön päätöslauselma sama. En kuitenkaan halua puhua glibc resolver ja miten se on vuorovaikutuksessa /etc/resolv.conf varastossa CentOS 6 järjestelmä ja joka UNIX-ja Linux-ennen.

Tässä on esimerkki tiedostosta /etc/resolv.conf

search edgeofsanity.net
nameserver 192.168.1.1
nameserver 9.9.9.9
nameserver 8.8.8.8

Asiat ensin, /etc/resolv.conf tukee vain kolme nimipalvelimet, ja edelleen palvelimet ovat huomiotta. Olen nähnyt jopa kahdeksan palvelimet resolv.conf on hallinnoi kokenut, asiantunteva ihmiset. Muista, vain kolme ensimmäistä ovat koskaan kyseenalaistanut.

Joten, mitä tapahtuu tämän resolv.conf? No, jos 192.168.1.1 vastaa kyselyihin, se on aina käytettävä ratkaisemaan jokaisen kyselyn. Jos kyselyn kulkee timeout, oletusarvo on 5 sekuntia, ilman vastausta, kysely lähetetään 192.168.1.1 kerran, ennen kuin etenee 9.9.9.9. Nämä laskurit seurataan sisäisesti prosessi käynnissä resolver kirjasto. Nämä eivät ole maailmanlaajuinen laskurit, he ovat paikallisia kunkin prosessin. Tässä nimenomaisessa tapauksessa vika on myös per-kyselyn, eli jokainen DNS-kysely on timeout kahdesti 192.168.1.1 ennen etenee 9.9.9.9.

Miksi? No, aikakatkaisu voisi tapahtua mahdollisesti useita syitä. Timeout on nimipalvelin yksi kysely ei ennustaa timeout tulevaisuudessa samalla palvelimella saman kyselyn. Se on monimutkaista.

Mitä tämä kokoonpano takaa on, että jokainen kysely kestää vähintään 10 sekuntia aikaa ratkaista, jos on 192.168.1.1 alas. Tämä on vähemmän kuin ihanteellinen, jotta voimme parantaa sitä hieman lisäämällä vaihtoehtoja.

search edgeofsanity.net
nameserver 192.168.1.1
nameserver 9.9.9.9
nameserver 8.8.8.8
options timeout 1 attempts 1

Asettamalla timeout 1 sekunti ja yrittää 1, me yritämme 9.9.9.9, jos 192.168.1.1 ei vastaa 1 sekunnin kuluessa. Jälleen, tämä on per-kyselyn, per-prosessi, joten jokainen kyselyn, aina yrittää 192.168.1.1 ennen siirtymistä 9.9.9.9, koska toista perässäni, “timeout yhden kyselyn yksittäinen DNS-palvelin ei voi ennustaa, että jopa saman kyselyn samalle palvelimelle vanhenee, jossain vaiheessa tulevaisuudessa.”

Tämä parantaa epäonnistumisesta tapauksessa 192.168.1.1 yhä käytettävissä, mutta se on edelleen 1+ toinen jokaista DNS-kyselyn, joka on luvattoman hidas tahansa web-alaista palvelua. On toinenkin vaihtoehto, voimme esitellä vähentää vaikutusta DNS-palvelin on käytettävissä, on meidän palvelimille:

search edgeofsanity.net
nameserver 192.168.1.1
nameserver 9.9.9.9
nameserver 8.8.8.8
options timeout 1 attempts 1 rotate

Esittelemme rotate mahdollisuus config tiedoston. Jos olet suorittaa tämän: while true; do getent hosts www.google.com; done; olisit varmaan yllättynyt siitä, JOKAISEEN kysely menossa 192.168.1.1. Ehkä voit arvata, miksi näin on? Että on oikeassa! kiertää – vaihtoehto on per-prosessi, joten aina kun me ajaa getentaloitetaan uusi prosessi, joka alkaa ensimmäisestä name server ensimmäisen kyselyn ja edelleen seuraavaan palvelimeen seuraavan kyselyn. Viat per-kyselyn ovat edelleen käsitellä samalla tavalla.

Jos oli epäonnistuminen 192.168.1.1, että sinulla olisi enemmän kuin 33% DNS-kyselyt otetaan 1+ sekuntia ratkaisemiseksi. Miksi? Jälleen rotate on per-prosessi, niin kauan käynnissä olevat prosessit pyörivät läpi huono-palvelin, joka 3 kyselyt. Kuitenkin, jokainen uusi prosessi alkaa aina alussa-luettelossa.

Uusi Käyttäytyminen

OK, niin mitä on kuvattu GitHub kysymys on systemd-ratkaistu kirjoittaja päättää rikkoa perustavanlaatuinen suunnittelu DNS UNIX-järjestelmissä. Palvelimet ovat ei ohitetaan edellisessä glibc resolver maailmassa. Tämä johtuu siitä,, ja minä sanon sen taas, aikakatkaisu yhden DNS-kyselyn yksittäinen DNS-palvelin ei ole ennustaa aikakatkaisu, että saman kyselyn, että saman palvelimen milloin tahansa tulevaisuudessa. Systemd-ratkaistu käyttäytyminen lisää nyt tämä valtio on kansalaisuudeton protokolla, joka johtaa arvaamaton ja epäjohdonmukainen käyttäytyminen yhdessä alin taso, eniten väärin, ja useimmat kriittiset komponentit oman infrastruktuurin.

On tapa kiertää tämä, jos jokainen DNS-palvelimen luettelo DNS-palvelimet on merkitty olevan ongelmallista, systemd-ratkaistu putoaa takaisin oletuksena käyttäytymistä läpi jokaisen palvelimen luettelossa ja palauttaa niiden tilan. Helpoin tapa varmistaa tämä tapahtuu, on listalla yksi nimipalvelin /etc/resolv.conf-tiedoston asetuksia. Tämä pakottaa oikosulku valtion seuranta logiikkaa.

Sulkeminen

En aio lyödä systemd tai jollekin sen tekijät tai ylläpitäjät. He tekevät parhaansa ratkaista kovia ongelmia. En eri mieltä täysin heidän suuntaan ja oletuksia, mutta ne kirjoittaa koodia ja käsiteltäessä vihainen yhteisöjen, enkä kasa. Kuitenkin, tämä käyttäytyminen on täysin erilainen kuin kaikki muut tilaa, ja se edustaa, mitä pelkään, on naiivius ja välinpitämättömyyttä ymmärtää ongelman tilaa. Jos sinulla hallinnoida Linux-järjestelmät ammattimaisesti, sinun täytyy olla tietoinen, tämä ero ja miten se vaikuttaa oman infrastruktuurin, jos on ongelmia alkupään DNS-palveluntarjoajat.

On täysin mahdollista, että tämä muutos käyttäytymisessä ei ole mitään tai hyvin vähän vaikutusta oman infrastruktuurin. On tärkeää ymmärtää tämä ero, koska DNS on usein vaikuttanut tai vaikuttaa saatavuuden teidän palveluja.

Päivitykset

Ensinnäkin, minulla on jotain vikaa. Jos me rotate käytössä ja 3 nimipalvelimet, noin 50% kyselyt kestää 1+ sekuntia ratkaisemiseksi. Tämä johtuu siitä, että valtio ei ole taikuutta, se on yksinkertainen osoitin, joka on kasvaa joka kerta. Harkitse, query #1 menee 192.168.1.1, se kertaa ulos, osoitin on edennyt 9.9.9.9, ja se onnistuu. Kysely #2 tulee ja että osoitin on edennyt 8.8.8.8, se onnistuu. Kysely #3 tulee, osoitin on edennyt 192.168.1.1 se kertaa ulos ja siirtyy 9.9.9.9. Huuhtele ja toista.

Laurent Bigonville ehdotti poistamalla resolve /etc/nsswitch.conf.

Paul Vixie huomattava, että sovellusten kehittäjien pitäisi harkita getdns niiden sovelluksia, koska se on moderni, fiksu resolver kirjasto.

Leave a Reply

Your email address will not be published. Required fields are marked *