Domain Name System (DNS) latenssi on keskeinen osa ottaa hyvä online-kokemus. Ja minimoida DNS latenssi, huolellisesti poiminta DNS-palvelimet ja anonymisointi releet on tärkeä rooli.
mutta paras tapa minimoida viivettä on välttää turhien kyselyiden lähettämistä aluksi. Siksi DNS suunniteltiin alusta asti vahvasti koodattavaksi protokollaksi. Yksittäisillä tietueilla on TTL (time-to-live), jonka vyöhykkeen ylläpitäjät ovat alun perin asettaneet, ja resolverit käyttävät näitä tietoja säilyttääkseen nämä tietueet muistissa välttääkseen tarpeetonta liikennettä.
Onko välimuistin tallentaminen tehokasta? Pari vuotta sitten tekemäni pikatutkimus osoitti, että parantamisen varaa on. Tänään haluan tarkastella uudelleen nykytilannetta.
tätä varten paikkasin salatun DNS-palvelimen tallentamaan vastauksen alkuperäisen TTL: n, joka on määritelty sen tietueiden vähimmäismääräksi, jokaiselle saapuvalle kyselylle. Tämä antaa hyvän yleiskuvan reaalimaailman liikenteen TTL-jakaumasta, mutta selittää myös yksittäisten kyselyiden suosion.
tuo paikattu versio jäi pyörimään pariksi tunniksi. Tuloksena oleva tietojoukko koostuu 1 583 579 (nimi, qtype, TTL, aikaleima) tupleista. Tässä on TTL: n kokonaisjakauma (X – akseli on TTL sekunteina):
sen lisäksi, että TTL on mitättömän pieni 86 400 (lähinnä SOA: n levyillä), on melko selvää, että TTL: t ovat alhaisia. Zoomataan:
kunnossa, yli 1 tunnin TTL: t ovat tilastollisesti merkityksettömiä. Keskitytään 0-3 600: n vaihteluväliin:
ja jossa useimmat TTL: t istuvat 0-15 minuuttia:
valtaosa on välillä 0-5 minuuttia:
Tämä ei ole suuri. Kumulatiivinen jakauma voi tehdä asiasta entistä selvemmän:
puolella Internetistä on 1 minuutin TTL tai vähemmän ja kolmella neljäsosalla 5 minuutin TTL tai vähemmän.
mutta hetkinen, tämä on itse asiassa pahempi. Nämä ovat arvovaltaisten palvelimien määrittelemiä TTL: iä. Asiakkaan resolvereista (esimerkiksi reitittimistä, paikallisista välimuisteista) haetut TTL: t saavat kuitenkin TTL: n, jonka ylävirran resolverit säätävät joka sekunti. Niinpä keskimäärin todellinen kesto, jonka asiakas voi käyttää välimuistissa olevaa merkintää ennen uuden kyselyn tekemistä, on puolet alkuperäisestä TTL: stä.
ehkä nämä hyvin alhaiset TTLs: t vaikuttavat vain harvinaisiin kyselyihin eivätkä suosittuihin verkkosivustoihin ja sovellusliittymiin. Katsotaanpa:
valitettavasti Suosituimmat kyselyt ovat myös turhimpia välimuistiin. Zoomataan.:
tuomio: se on todella huono, tai pikemminkin se oli jo huono, ja se on pahentunut. DNS-välimuistista on tullut lähes hyödytön. Kun vähemmän ihmisiä käyttää ISP: n DNS resolver (hyvästä syystä), lisääntynyt latenssi on havaittavissa. DNS-välimuistista on tullut hyötyä vain sisällölle, jossa kukaan ei käy. Huomaa myös, että ohjelmistot voivat tulkita alhaisia TTL: iä eri tavalla.
miksi?
miksi DNS-tietueet on asetettu niin alhaisilla TTLs: llä?
- Legacy load balancereille jää oletusasetukset.
- urbaanilegenda, jonka mukaan DNS-pohjainen kuormitustasapaino riippuu TTLs: stä (se ei).
- ylläpitäjät haluavat, että heidän muutoksiaan sovelletaan välittömästi, koska se saattaa vaatia vähemmän suunnittelutyötä.
- DNS-tai load-balancer-ylläpitäjänä velvollisuutenasi on ottaa tehokkaasti käyttöön ihmisten pyytämät asetukset, ei tehdä verkkosivustoista ja palveluista nopeita.
- matalat TTL: t antavat mielenrauhan.
en ole sisällyttämässä ”for failoveria” tuohon luetteloon, koska tämä on käynyt yhä vähemmän merkitykselliseksi. Jos tarkoituksena on ohjata käyttäjät eri verkkoon vain näyttää epäonnistua valas sivu, kun aivan kaikki muu on tulessa, ottaa yli minuutin viive on luultavasti hyväksyttävää.
cdns ja kuormitusbalancers ovat suurelta osin syyllisiä, varsinkin kun ne yhdistävät CNAME-tietueet lyhyisiin TTLs-tietueisiin, joilla on myös lyhyet (mutta riippumattomat) TTLs:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
uusi kysely on lähetettävä aina, kun CN-nimi tai jokin a-tietueista vanhenee. Molemmilla on 30 sekunnin TTL, mutta ne eivät ole vaiheessa. Todellinen keskimääräinen TTL on 15 sekuntia.
mutta odota! Tämä on pahempaa. Jotkut resolverit käyttäytyvät aika huonosti tällaisessa low-TTL-CNAME + low-TTL-records-tilanteessa:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Tämä on Level3: n resolveri, joka taitaa olla käynnissä BIND. Jos jatkat kyselyn lähettämistä, palautettu TTL on aina 1. Periaatteessa raw.githubusercontent.com sitä ei koskaan tallenneta välimuistiin.
Tässä toinen esimerkki low-TTL-CNAME+low-TTL-records-tilanteesta, jossa esiintyy erittäin suosittu nimi:
$ drill detectportal.firefox.com @1.1.1.1detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net.detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net.detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net.a1089.dscd.akamai.net. 10 IN A 104.123.50.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
peräti kolme CN-tietuetta. Auts. Yhdellä on kunnon TTL, mutta se on täysin hyödytön. Muiden Cnimien alkuperäinen TTL on 60 sekuntia; akamai.net nimillä on maksimissaan 20 sekunnin TTL, eikä mikään niistä ole vaiheessa.
miten olisi sellainen, jota Apple-laitteesi jatkuvasti kyselevät?
$ drill 1-courier.push.apple.com @4.2.2.21-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net.1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net.gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
sama konfiguraatio kuin Firefoxilla ja TTL on suurimman osan ajasta kiinni 1 käytettäessä Level3: n resolveria.
entä Dropbox?
$ drill client.dropbox.com @8.8.8.8client.dropbox.com. 7 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 59 IN A 162.125.67.3$ drill client.dropbox.com @4.2.2.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com sen TTL on 60 sekuntia. Facebook-nimillä on 60 sekunnin TTL. Ja jälleen kerran asiakkaan näkökulmasta nämä arvot pitäisi puolittaa.
miten olisi TTL: n vähimmäismäärän asettaminen?
käyttäen alun perin tallennettua nimeä, kyselytyyppiä, TTL: ää ja aikaleimaa kirjoitin skriptin, joka simuloi 1,5+ miljoonaa kyselyä välimuistiratkaisijan läpi arvioidakseni kuinka monta kyselyä lähetettiin vanhentuneen välimuistimerkinnän vuoksi. 47,4% kyselyistä tehtiin sen jälkeen, kun olemassa oleva, välimuistissa oleva merkintä oli vanhentunut. Tämä on kohtuuttoman paljon.
mikä olisi vaikutus välimuistiin tallentamiseen, jos TTL-vähimmäismäärä asetettaisiin?
x-akseli on asetettu pienin TTL. Tiedot, joiden alkuperäinen TTL oli tätä arvoa korkeampi, eivät vaikuttaneet. Y-akseli on prosenttiosuus kyselyistä, jotka on tehnyt asiakas, jolla on jo välimuistissa, mutta uusi kysely tehtiin ja välimuistissa oleva merkintä oli vanhentunut.
kyselyiden määrä putoaa 47%: sta 36%: iin vain asettamalla TTL: n vähimmäismääräksi 5 minuuttia. Asettamalla vähintään TTL 15 minuuttia tekee määrä tarvittavat kyselyt pudota 29%. Vähintään TTL 1 tunti tekee sen pudota 17%. Se on merkittävä ero!
entäpä jos ei muutettaisi mitään palvelinpuolelta, vaan asiakkaan DNS-välimuistit (reitittimet, paikalliset resolverit ja välimuistit…) asetettaisiin sen sijaan vähintään TTL?
vaadittujen kyselyjen määrä laskee 47%: sta 34%: iin asettamalla TTL: n vähimmäismääräksi 5 minuuttia, 25%: iin 15 minuutin minimillä ja 13%: iin 1 tunnin minimillä. 40 minuuttia ehkä makea paikka. Tuon vähäisen muutoksen vaikutus on valtava.
mitkä ovat seuraukset?
tietysti palvelu voi siirtyä uuteen pilvipalveluntarjoajaan, uuteen palvelimeen, uuteen verkkoon, jolloin asiakkaiden on käytettävä ajantasaisia DNS-tietueita. Kohtuullisen alhainen TTLs auttaa tekemään siirtymästä kitkattoman. Kuitenkin, kukaan siirtymässä uuteen infrastruktuuriin aikoo odottaa asiakkaiden käyttää uusia DNS tietueita sisällä 1 minuutti, 5 minuuttia tai 15 minuuttia.
vähintään 40 minuutin TTL: n asettaminen 5 minuutin sijaan ei estä käyttäjiä käyttämästä palvelua. Se kuitenkin vähentää merkittävästi latenssia ja parantaa yksityisyyttä (enemmän kyselyjä = enemmän seurantamahdollisuuksia) ja luotettavuutta välttämällä tarpeettomia kyselyjä.
RFC: n mukaan TTL: ää tulee tietenkin noudattaa tiukasti. Todellisuus on kuitenkin se, että DNS: stä on tullut tehoton.
Jos käytät arvovaltaisia DNS-palvelimia, tarkista uudelleen TTLs. Pitääkö näiden olla naurettavan alhaisia?
Lue: miten valitaan DNS TTL-arvot
toki on päteviä syitä käyttää matalia DNS-TTL-arvoja. Mutta ei niin, että 75 prosenttia Internetistä tarjoaisi sisältöä, joka on enimmäkseen muuttumatonta, mutta turhaa välimuistiin. Ja jos jostain syystä, sinun todella täytyy käyttää alhainen DNS TTLs, myös varmista, että välimuisti ei toimi sivustossasi joko. Samoista syistä.
Jos käytät paikallista DNS-välimuistia, kuten DNSCrypt-välityspalvelinta, joka mahdollistaa TTL-vähimmäismäärän asettamisen, käytä kyseistä ominaisuutta. Tämä on okei. Mitään pahaa ei tapahdu. Aseta tämä pienin TTL jotain välillä 40 minuuttia (2400 sekuntia) ja 1 tunti; tämä on täysin kohtuullinen alue.
mukautettu alkuperäisestä postista, joka ilmestyi 00f.net