Madal DNS-latentsus on kiire sirvimise võtmetegur. Selle minimeerimiseks on oluline hoolikalt valida DNS-serverid ja anonüümsed edastusedAga esimene asi, mida pead tegema, on vabaneda kasututest päringutest.

Seepärast loodi DNS algselt ülimalt vahemällu salvestatava protokollina. Tsoonide administraatorid määravad iga kirje jaoks eluea (TTL) ja lahendajad kasutavad seda teavet kirjete mällu salvestamisel, et vältida ebavajalikku liiklust.

Kas vahemällu salvestamine on efektiivne? Paar aastat tagasi näitas minu väike uurimus, et see pole täiuslik. Vaatame praegust seisu.

Teabe kogumiseks paigasin Krüptitud DNS-server vastuse TTL-väärtuse salvestamiseks. See on defineeritud kui iga sissetuleva päringu kirjete minimaalne TTL. See annab hea ülevaate tegeliku liikluse TTL-jaotusest ja võtab arvesse ka üksikute päringute populaarsust. Serveri parandatud versioon töötas mitu tundi.

Saadud andmestik koosneb 1 583 579 kirjest (nimi, kvantitüüp, TTL, ajatempel). Siin on üldine TTL-jaotus (x-telg on TTL sekundites):

Peale väikese tõusu 86 400 juures (peamiselt SOA-kirjete puhul) on TTL-id üsna ilmselged, et need on madalas vahemikus. Vaatame lähemalt:

Olgu, üle tunni kestvad TTL-id on statistiliselt ebaolulised. Keskendume siis vahemikule 1–0:

Enamik TTL-e on vahemikus 0 kuni 15 minutit:

Valdav enamus on 0 kuni 5 minutit:

See pole eriti hea.

Kumulatiivne jaotus muudab probleemi veelgi ilmsemaks:

Pooltel DNS-vastustest on TTL 1 minut või vähem ja kolmel neljandikul on TTL 5 minutit või vähem.

Aga oota, tegelikult on see hullem. See on autoriteetsete serverite TTL. Klientresolverid (nt ruuterid, kohalikud vahemälud) saavad TTL-i aga ülesvoolu resolvereidelt ja see väheneb iga sekundiga.

Seega saab klient enne uue päringu saatmist iga kirjet kasutada keskmiselt poole algsest TTL-ist.

Võib-olla kehtivad need väga madalad TTL-id ainult ebatavaliste päringute, mitte populaarsete veebisaitide ja API-de puhul? Vaatame lähemalt:

X-telg on TTL, Y-telg on päringute populaarsus.

Kahjuks on kõige populaarsemad päringud ka kõige halvemini vahemällu salvestatud.

Suumime sisse:

Kohtuotsus: See on tõesti halb. See oli juba niigi halb ja on läinud hullemaks. DNS-i vahemällu salvestamine on muutunud praktiliselt kasutuks. Kuna vähem inimesi kasutab oma internetiteenuse pakkuja DNS-i lahendajat (mõjuvatel põhjustel), muutub latentsuse suurenemine märgatavamaks.

DNS-i vahemällu salvestamine on muutunud kasulikuks ainult sisu puhul, mida keegi ei külasta.

Samuti pange tähele, et tarkvara võib erinevalt tõlgendada madalaid TTL-e.

Miks nii?

Miks on DNS-kirjetele seatud nii lühike TTL?

• Pärandkoormuse tasakaalustajatele jäetakse vaikesätted.
• On müüte, et DNS-i koormuse tasakaalustamine sõltub TTL-ist (see ei ole tõsi - alates Netscape Navigatorist valivad kliendid RR-komplektist juhusliku IP-aadressi ja proovivad läbipaistvalt teist, kui nad ei saa ühendust luua).
• Administraatorid soovivad muudatusi kohe rakendada, seega on seda lihtsam planeerida.
• DNS-serveri või koormuse tasakaalustaja administraator näeb oma ülesannet kasutajate poolt nõutud konfiguratsiooni tõhusa juurutamisena, mitte saitide ja teenuste töö kiirendamisena.
• Madal TTL annab meelerahu.
• Inimesed määravad testimiseks esialgu madalad TTL-id ja unustavad need siis muuta.

Ma ei lisanud "tõrgeteta üleviimist", kuna see muutub üha vähem asjakohaseks. Kui teil on vaja kasutajad teise võrku suunata ainult selleks, et kuvada vealehte, kui absoluutselt kõik muu on katki, on ilmselt vastuvõetav üle üheminutilise viivituse.

Lisaks tähendab üheminutiline TTL seda, et kui autoriteetsed DNS-serverid on blokeeritud kauem kui üks minut, ei pääse keegi teine ​​​​sõltuvatele teenustele juurde. Ja koondamine ei aita, kui põhjuseks on konfiguratsiooniviga või häkkimine. Teisest küljest, mõistlike TTL-ide korral jätkavad paljud kliendid eelmise konfiguratsiooni kasutamist ja ei märka seda kunagi.

Madalad TTL-id on suuresti CDN-teenuste ja koormuse tasakaalustajate süü, eriti kui nad kombineerivad madala TTL-iga CNAME-e ja sama madala (kuid sõltumatu) TTL-iga kirjeid:

$ 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

Iga kord, kui CNAME või mõni A-kirje aegub, tuleb saata uus päring. Mõlema TTL on 30 sekundit, kuid need ei ole samad. Tegelik keskmine TTL on 15 sekundit.

Aga oota! Asi läheb hullemaks. Mõned lahendajad käituvad sellises olukorras kahe omavahel seotud madala TTL-iga väga halvasti:

$ drill 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 resolver töötab tõenäoliselt BIND-il. Kui sa seda päringut pidevalt saadad, tagastab see alati TTL-i väärtuseks 1. Põhimõtteliselt, raw.githubusercontent.com pole kunagi vahemällu salvestatud.

Siin on veel üks näide sellest olukorrast väga populaarse domeeniga:

$ 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ähemalt kolm CNAME-kirjet. Ai. Ühel on korralik TTL, aga see on täiesti kasutu. Teiste CNAME-kirjete algne TTL on 60 sekundit, aga domeenide puhul... akamai.net Maksimaalne TTL on 20 sekundit ja ükski neist pole faasis.

Aga domeenid, mis pidevalt Apple'i seadmeid küsitlevad?

$ 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 probleem mis Firefoxil ja TTL jääb Level1 resolveri kasutamisel enamasti 3 sekundi peale kinni.

Dropboxi?

$ drill client.dropbox.com @8.8.8.8 client.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.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3

Salvestuse ajal safebrowsing.googleapis.com TTL-väärtus 60 sekundit, täpselt nagu Facebooki domeenidel. Ja jällegi, kliendi vaatenurgast on need väärtused poole võrra vähenenud.

Kuidas oleks minimaalse TTL-i määramisega?

Kasutades nime, päringu tüüpi, TTL-i ja algselt salvestatud ajatempli, kirjutasin skripti, mis simuleerib 1,5 miljonit päringut, mis läbivad vahemälu lahendajat, et hinnata aegunud vahemälukirje tõttu saadetud lisapäringute arvu.

47,4% päringutest esitati pärast olemasoleva kirje kehtivusaja lõppemist. See on ebamõistlikult kõrge arv.

Milline on minimaalse TTL-i määramise mõju vahemällu salvestamisele?

X-teljel on minimaalsed TTL-väärtused. Sellest väärtusest suurema toor-TTL-iga kirjeid see ei mõjuta.

Y-teljel on näidatud kliendi päringute protsent, millel on juba vahemällu salvestatud kirje, kuid see on aegunud ja teeb uue päringu.

„Lisapäringute“ osakaalu vähendatakse 47%-lt 36%-le, määrates minimaalseks TTL-iks lihtsalt 5 minutit. Minimaalse TTL-i määramine 15 minutile vähendab nende päringute arvu 29%-ni. Minimaalse TTL-i määramine 1 tunniks vähendab neid 17%-ni. Märkimisväärne erinevus!

Kuidas oleks serveri poolel mitte midagi muuta, vaid kliendi DNS-i vahemäludes (ruuterid, kohalikud resolverid) minimaalsed TTL-id määrata?

Nõutavate päringute arv langeb minimaalse TTL-i määramisel 47 minutile 34%-lt 5%-le, minimaalse 25 minuti korral 15%-le ja minimaalse 13 tunni korral 1%-le. Võib-olla on optimaalne 40 minutit.

Selle minimaalse muutuse mõju on tohutu.

Millised on tagajärjed?

Muidugi, saate teenuse migreerida uuele pilveteenuse pakkujale, uuele serverile, uude võrku ja nõuda klientidelt uusimate DNS-kirjete kasutamist. Ja piisavalt lühike TTL aitab muuta selle ülemineku sujuvaks ja tõrgeteta. Kuid uuele infrastruktuurile migreerimisel ei oota keegi, et kliendid migreeruksid uutele DNS-kirjetele 1 minuti, 5 minuti või 15 minuti jooksul. Minimaalse TTL-i määramine 40 minutile 5 minuti asemel ei takista kasutajatel teenusele juurdepääsu.

See aga vähendab oluliselt latentsust ning parandab privaatsust ja usaldusväärsust, vältides ebavajalikke päringuid.

Muidugi, RFC-des öeldakse, et TTL-e tuleks rangelt järgida. Kuid tegelikkus on see, et DNS-süsteem on muutunud liiga ebaefektiivseks.

Kui töötate autoriteetsete DNS-serveritega, kontrollige palun oma TTL-e. Kas teil on tõesti vaja nii naeruväärselt madalaid väärtusi?

Muidugi on DNS-kirjete jaoks lühikeste TTL-ide määramiseks häid põhjuseid. Kuid mitte 75% DNS-liikluse puhul, mis vaevu muutub.

Ja kui mingil põhjusel on vaja DNS-i jaoks madalat TTL-i kasutada, siis veendu ka, et sinu saidil poleks vahemällu salvestamine lubatud. Samadel põhjustel.

Kui teil töötab kohalik DNS-vahemälu, näiteks dnscrypt-puhverserver, mis võimaldab teil määrata minimaalse TTL-i, kasutage seda funktsiooni. See on normaalne. Midagi halba ei juhtu. Määrake minimaalne TTL 40 minuti (2400 sekundi) ja 1 tunni vahele. Mõistlik vahemik.

Allikas: www.habr.com