Alhainen DNS-viive on avain nopeaan Internet-selailuun. Sen minimoimiseksi on tärkeää valita huolellisesti DNS-palvelimet ja . Mutta ensimmäinen askel on päästä eroon turhista kyselyistä.
Tästä syystä DNS suunniteltiin alun perin hyvin välimuistiin tallennettavaksi protokollaksi. Vyöhykkeen ylläpitäjät asettavat yksittäisille merkinnöille elinajan (TTL), ja ratkaisejat käyttävät näitä tietoja tallentaessaan merkintöjä muistiin tarpeettoman liikenteen välttämiseksi.
Onko välimuisti tehokasta? Pari vuotta sitten pieni tutkimukseni osoitti, että se ei ollut täydellinen. Katsotaanpa tämän hetkistä tilannetta.
Tietojen keräämiseksi korjasin tallentaaksesi vastauksen TTL-arvon. Se määritellään sen tietueiden vähimmäis-TTL:ksi jokaiselle saapuvalle pyynnölle. Tämä antaa hyvän yleiskuvan todellisen liikenteen TTL-jakaumasta ja ottaa huomioon myös yksittäisten pyyntöjen suosion. Palvelimen korjattu versio toimi useita tunteja.
Tuloksena oleva tietojoukko koostuu 1 583 579 tietueesta (nimi, qtype, TTL, aikaleima). Tässä on yleinen TTL-jakauma (X-akseli on TTL sekunneissa):
Lukuun ottamatta pientä kolhua 86:ssa (enimmäkseen SOA-tietueita varten), on melko selvää, että TTL:t ovat matalalla alueella. Katsotaanpa tarkemmin:
Okei, yli 1 tunnin TTL:t eivät ole tilastollisesti merkitseviä. Keskitytään sitten alueelle 0–3600:
Useimmat TTL:t ovat 0–15 minuuttia:
Suurin osa on 0–5 minuuttia:
Se ei ole kovin hyvä.
Kumulatiivinen jakautuminen tekee ongelmasta vieläkin ilmeisemmän:
Puolella DNS-vastauksista TTL on 1 minuutti tai vähemmän, ja kolmella neljäsosalla TTL on enintään 5 minuuttia.
Mutta odota, se on oikeastaan pahempaa. Loppujen lopuksi tämä on TTL arvovaltaisilta palvelimilta. Asiakasratkaisijat (esim. reitittimet, paikalliset välimuistit) saavat kuitenkin TTL:n ylävirran ratkaisejilta, ja se pienenee joka sekunti.
Joten asiakas voi itse asiassa käyttää jokaista merkintää keskimäärin puoleen alkuperäisestä TTL:stä ennen uuden pyynnön lähettämistä.
Ehkä nämä erittäin alhaiset TTL:t koskevat vain epätavallisia pyyntöjä eivätkä suosittuja verkkosivustoja ja API:ita? Katsotaanpa:
X-akseli on TTL, Y-akseli on kyselyn suosio.
Valitettavasti suosituimmat kyselyt ovat myös huonoimmin välimuistissa.
Lähennä:
Tuomio: se on todella huono. Se oli huono jo ennen, mutta se paheni entisestään. DNS-välimuistista on tullut käytännössä hyödytöntä. Mitä harvemmat ihmiset käyttävät Internet-palveluntarjoajansa DNS-selvittäjää (hyvistä syistä), viiveen lisääntyminen tulee tuntuvammaksi.
DNS-välimuistista on tullut hyödyllistä vain sisällölle, jossa kukaan ei käy.
Huomaa myös, että ohjelmisto saattaa tulkita matalia TTL-arvoja.
Miksi niin?
Miksi DNS-tietueet on asetettu niin alhaiselle TTL:lle?
- Vanhat kuormantasaajat jätettiin oletusasetuksiin.
- On myyttejä siitä, että DNS-kuormituksen tasapainotus riippuu TTL:stä (tämä ei pidä paikkaansa - Netscape Navigatorin ajoista lähtien asiakkaat ovat valinneet satunnaisen IP-osoitteen joukosta RR:itä ja läpinäkyvästi kokeilleet toista, jos he eivät saa yhteyttä).
- Järjestelmänvalvojat haluavat ottaa muutokset käyttöön välittömästi, joten suunnittelu on helpompaa.
- DNS-palvelimen tai kuormituksen tasapainottajan järjestelmänvalvoja näkee tehtävänsä käyttäjien pyytämien määritysten tehokkaana käyttöönottamisena eikä sivustojen ja palveluiden nopeuttamisena.
- Matalat TTL:t antavat sinulle mielenrauhan.
- Ihmiset asettavat aluksi alhaiset TTL-arvot testausta varten ja unohtavat sitten muuttaa niitä.
En sisällyttänyt "failoveria" luetteloon, koska se on yhä vähemmän merkityksellinen. Jos sinun on ohjattava käyttäjät toiseen verkkoon vain näyttääksesi virhesivun, kun kaikki muu on rikki, yli minuutin viive on todennäköisesti hyväksyttävä.
Lisäksi minuutin TTL tarkoittaa, että jos arvovaltaiset DNS-palvelimet estetään yli 1 minuutiksi, kukaan muu ei voi käyttää riippuvaisia palveluita. Ja redundanssi ei auta, jos syy on asetusvirhe tai hakkerointi. Toisaalta kohtuullisilla TTL:illä monet asiakkaat jatkavat edellisen kokoonpanon käyttämistä eivätkä koskaan huomaa mitään.
CDN-palvelut ja kuormantasaajat ovat suurelta osin syyllisiä alhaisiin TTL-arvoihin, varsinkin kun ne yhdistävät CNAME:t matalilla TTL:illä ja tietueet, joilla on yhtä alhainen (mutta riippumaton) TTL:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Aina kun CNAME tai jokin A-tietueista vanhenee, uusi pyyntö on lähetettävä. Molemmilla on 30 sekunnin TTL, mutta se ei ole sama. Todellinen keskimääräinen TTL on 15 sekuntia.
Mutta odota! Se on vielä pahempaa. Jotkut ratkaisijat käyttäytyvät erittäin huonosti tässä tilanteessa, jossa on kaksi alhaista TTL:ää:
$ poraa raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Level3-selvitin toimii luultavasti BIND:llä. Jos jatkat tämän pyynnön lähettämistä, TTL palautetaan aina 1. Käytännössä raw.githubusercontent.com ei ole koskaan välimuistissa.
Tässä on toinen esimerkki tällaisesta tilanteesta erittäin suositulla verkkotunnuksella:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.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.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Vähintään kolme CNAME-tietuetta. Ay. Yhdellä on kunnollinen TTL, mutta se on täysin hyödytön. Muiden CNAME-tunnusten alkuperäinen TTL on 60 sekuntia, mutta verkkotunnuksille akamai.net maksimi TTL on 20 sekuntia, eikä mikään niistä ole samassa vaiheessa.
Entä verkkotunnukset, jotka jatkuvasti kyselevät Apple-laitteita?
$ drill 1-courier.push.apple.com @4.2.2.2 1-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.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Sama ongelma kuin Firefoxissa ja TTL:ssä jää 1 sekuntiin suurimman osan ajasta käytettäessä Level3-selvitintä.
Dropbox?
$ poraa client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN 162.125.67.3 $ poraa client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Äänityksessä safebrowsing.googleapis.com TTL-arvo on 60 sekuntia, kuten Facebook-verkkotunnukset. Ja jälleen, asiakkaan näkökulmasta nämä arvot puolitetaan.
Entä jos asettaisit vähimmäis-TTL:n?
Käyttämällä nimeä, pyyntötyyppiä, TTL:ää ja alun perin tallennettua aikaleimaa kirjoitin komentosarjan, joka simuloi 1,5 miljoonaa välimuistin selvittimen läpi kulkevaa pyyntöä arvioidakseni vanhentuneen välimuistimerkinnän vuoksi lähetettyjen tarpeettomien pyyntöjen määrän.
47,4 % pyynnöistä tehtiin sen jälkeen, kun olemassa oleva tietue oli vanhentunut. Tämä on kohtuuttoman korkea.
Mitä vaikutusta välimuistiin on, jos vähimmäis-TTL on asetettu?
X-akseli on pienimmät TTL-arvot. Tämä ei vaikuta tietueisiin, joiden lähde-TTL on tämän arvon yläpuolella.
Y-akseli on niiden pyyntöjen prosenttiosuus asiakkaalta, jolla on jo välimuistissa oleva merkintä, mutta se on vanhentunut ja tekee uuden pyynnön.
”Ylimääräisten” pyyntöjen osuus pienenee 47 prosentista 36 prosenttiin asettamalla TTL:n vähimmäisarvoksi 5 minuuttia. Asettamalla TTL:n vähimmäismääräksi 15 minuuttia näiden pyyntöjen määrä putoaa 29 prosenttiin. Vähintään 1 tunnin TTL vähentää ne 17 prosenttiin. Merkittävä eroavaisuus!
Entä jos ei muuttaisi mitään palvelinpuolella, vaan asettaisit sen sijaan TTL:n vähimmäistason asiakkaan DNS-välimuistiin (reitittimet, paikalliset ratkaisijat)?
Vaadittujen pyyntöjen määrä putoaa 47 prosentista 34 prosenttiin, kun TTL on vähintään 5 minuuttia, 25 prosenttiin vähintään 15 minuutilla ja 13 prosenttiin vähintään 1 tunnilla. Ehkä 40 minuuttia on optimaalinen.
Tämän pienen muutoksen vaikutus on valtava.
Mitkä ovat seuraukset?
Tietysti palvelu voidaan siirtää uudelle pilvipalveluntarjoajalle, uudelle palvelimelle, uuteen verkkoon, jolloin asiakkailta vaaditaan uusimpien DNS-tietueiden käyttöä. Ja melko pieni TTL auttaa tekemään tällaisen siirtymisen sujuvasti ja huomaamattomasti. Mutta uuteen infrastruktuuriin siirtymisen myötä kukaan ei odota asiakkaiden siirtyvän uusiin DNS-tietueisiin minuutissa, 1 minuutissa tai 5 minuutissa. Minimi TTL:n asettaminen 15 minuuttiin 40 minuutin sijaan ei estä käyttäjiä pääsemästä palveluun.
Tämä kuitenkin vähentää merkittävästi viivettä ja parantaa yksityisyyttä ja luotettavuutta välttämällä tarpeettomia pyyntöjä.
Tietysti RFC:t sanovat, että TTL:ää on noudatettava tiukasti. Mutta tosiasia on, että DNS-järjestelmästä on tullut liian tehoton.
Jos työskentelet arvovaltaisten DNS-palvelimien kanssa, tarkista TTL:si. Tarvitsetko todella noin naurettavan alhaisia arvoja?
Tietysti on hyviä syitä asettaa pieniä TTL:itä DNS-tietueille. Mutta ei 75 % DNS-liikenteestä, joka pysyy käytännössä muuttumattomana.
Ja jos jostain syystä joudut todella käyttämään alhaisia TTL:itä DNS:lle, varmista samalla, että sivustosi välimuisti ei ole käytössä. Samoista syistä.
Jos käytössäsi on paikallinen DNS-välimuisti, esim jonka avulla voit asettaa vähimmäis-TTL:t, käytä tätä toimintoa. Tämä on hyvä. Mitään pahaa ei tapahdu. Aseta minimi-TTL noin 40 minuuttiin (2400 sekuntiin) ja 1 tuntiin. Ihan kohtuullinen valikoima.
Lähde: will.com