Madala latentsusega DNS on kiire veebitöötluse jaoks oluline tegur. Selle minimeerimiseks on oluline hoolikalt valida DNS-serverid ja anonüümsed releed. Kuid kõigepealt tuleks vabaneda tarbetutest päringutest.

Just sel põhjusel loodi DNS algselt tugevalt vahemälutatavaks protokolliks. Domeenide administraatorid seadistavad eraldi kirgede eluea (TTL), ning resolverid kasutavad seda teavet, et vältida tarbetut liiklust, salvestades kirjed mällu.

Kas vahemälu on efektiivne? Mõni aasta tagasi näitas minu väike uuring, et see ei ole ideaalne. Vaatame praegust olukorda.

Teabe kogumiseks olen ma parandanud Salastatud DNS-server TTL väärtuse salvestamiseks vastuse jaoks. See määratakse kui iga sissetuleva päringu maksimaalne TTL. See annab hea ülevaate tõelise liikluse TTL jaotusest ning arvestab ka individuaalsete päringute populaarsust. Parandatud server töötas mitu tundi.

Tulemuste andmestik koosneb 1 583 579 kirjest (name, qtype, TTL, timestamp). Siin on TTL üldine jaotus (X-telg on TTL sekundites):

Kui jätta kõrvale väike tipp 86 400 juures (peamiselt SOA kirjed), siis on üsna selge, et TTL-d on madalas vahemikus. Vaadakem lähemalt:

Noh, TTL üle 1 tunni pole statistiliselt olulised. Keskendume seega vahemikule 0−3600:

Enamik TTL-e on vahemikus 0 kuni 15 minutit:

Suurem osa on 0 kuni 5 minuti jooksul:

See pole sugugi hea.

Kumulatiivne jaotus teeb probleemi veelgi selgemaks:

Pooltel DNS-vastustest on TTL 1 minut või vähem, ja kolm neljandikku on 5 minutit või vähem.

Aga oota, tegelikult on asi veel hullem. Lõppude lõpuks on need TTL autoriteetsed serverid. Siiski saavad kliendiresolverid (näiteks ruuterid, kohalikud vahemälud) TTL kõrgematelt resolveridelt, ja see väheneb iga sekundi jooksul.

Seega võib klient tegelikult kasutada iga kirjet keskmiselt pool algsest TTL-ist, pärast mida saadab ta uue päringu.

Võib-olla kehtivad need väga madalad TTL-d ainult ebatavaliste päringute kohta, mitte populaarsete veebisaitide ja API-de kohta? Vaadakem seda:

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

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

Läheneme:

Otsus: kõik on tõesti halb. Oli juba varem halb, kuid nüüd on veel hullem. DNS-i vahemälestamine on praktiliselt kasutu. Kuna üha vähem inimesi kasutab oma teenusepakkuja DNS-i lahendajat (mõistlikel põhjustel), muutub viivituse suurenemine silmatorkavamaks.

DNS-i vahemälestamine on kasulik ainult sisu jaoks, mida keegi ei külasta.

Pöörake tähelepanu ka sellele, et tarkvara võib tõlgendada erinevalt madalaid TTL-e.

Miks nii?

Miks on DNS-kirjetele seatud nii madal TTL?

• Vanad koormuse tasakaalustajad jäid vaikeseadetega.
• Käivad müüdid, et DNS-i koormuse tasakaal sõltub TTL-ist (see ei ole nii - alates Netscape Navigatori ajast valivad kliendid juhusliku IP-aadressi RR-hulgast ja katsetavad teist, kui ei saa ühendust)
• Sysadminid soovivad muudatusi koheselt rakendada, sest nii on lihtsam planeerida.
• DNS-serveri või koormuse tasakaalustaja administraatori ülesanne on efektiivselt täita kasutajate nõudmisi seoses konfiguratsiooniga, mitte kiirendada veebisaitide ja teenuste tööd.
• Madala TTL (eluea) väärtuse kasutamine toob rahu ja kindlustunde.
• Inimesed seavad alguses madalad TTL-id testimiseks ja unustavad hiljem neid muuta.

Ma ei lisanud „katkestuste töötlemist” loetellu, kuna see on üha vähem aktuaalne. Kui on vaja suunata kasutajad teise võrku lihtsalt veateate lehe kuvamiseks, kui kõik muu on rikki läinud, siis on tõenäoliselt lubatav viivitus, mis ületab 1 minuti.

K darüber jjutis idol alh va yedol, et kui autoriteetsed DNS-serverid on blokeeritud enam kui 1 minutiks, ei pääse keegi enam juurde sõltuvatele teenustele. Ja üleliigsus ei aita, kui põhjus on konfiguratsiooni viga või rünnak. Teisest küljest, mõistlike TTL-idega jätkab paljude kliendid eelmise konfiguratsiooni kasutamist ega märkagi midagi.

Madala TTL definitsioon on suuresti seotud CDN-teenuste ja koormuse tasakaalustajatega, eriti kui need ühendavad CNAME-d madalate TTL-dega ja kirjed, millel on samuti madalad (kuid iseseisvad) TTL-d:

$ 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 ükski A-kirjest on aegunud, tuleb saata uus päring. Mõlemal on 30-sekundiline TTL, kuid need ei ühti. Tegelik keskmine TTL on 15 sekundit.

Aga oota! Asi on veel hullem. Mõned resolverid käituvad sellises olukorras kahte madala TTL-iga kirjadega 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

Resolver Level3 töötab tõenäoliselt BIND-il. Kui jätkate selle päringu saatmist, tagastatakse alati TTL, mis on võrdne 1. Sisuliselt, raw.githubusercontent.com ei cache'ita kunagi.

Siin on veel üks näide sellisest olukorrast väga populaarsel domeenil:

$ 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. Üks neist on head TTL, kuid see on täiesti kasutu. Ülejäänud CNAME algne TTL on 60 sekundit, kuid domeenide puhul akamai.net maksimaalne TTL on 20 sekundit, ja ükski neist ei ole faasis.

Kuidas on nende domeenidega, mis pidevalt küsivad Apple'i seadmeid?

$ 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 nagu Firefoxil, ja TTL jääb suurema osa ajast 1 sekundi peale kasutades Level3 resolverit.

Dropbox?

$ 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

Kande safebrowsing.googleapis.com TTL väärtus on 60 sekundit, nagu Facebooki domeenide puhul. Ja taas, kliendi seisukohalt, need väärtused vähenevad poole võrra.

Kuidas oleks minimaalne TTL seadistamine?

Kasutades nime, päringu tüüpi, TTL-i ja algselt salvestatud ajatemplit, kirjutasin skripti, et simuleerida 1,5 miljoni päringu läbitulekut läbi vahemällu salvestava resolvri, et hinnata liialdavate päringute mahtu, mis saadetakse aegunud vahemälu kande tõttu.

47,4% päringutest tehti pärast olemasoleva kande aegumist. See on põhjendamatu kõrge.

Milline mõju on vahemällu salvestamisele, kui kehtestada minimaalne TTL?

X-telg näitab minimaalsete TTL väärtuste arvu. Kanded, mille algne TTL on sellest väärtusest kõrgem, ei ole mõjutatud.

Y-telg näitab protsenti klientidest, kellel on juba vahemällus salvestatud kandi aegumine ja kes teevad uue päringu.

„Liialdavate” päringute osakaal langeb 47% -lt 36%-le, kui kehtestada minimaalne TTL 5 minutiks. Minimaalne TTL 15 minutiks vähendab nende päringute arvu 29%-le. 1 tunni minimaalne TTL vähendab nende arvu 17%-le. Oluline erinevus!

Kuidas oleks, kui mitte midagi serveri poolel muuta, vaid hoopis seada minimaalne TTL kliendi DNS-vahemäludes (ruuteri, kohalike resolv rugged)?

Nõutavate päringute arv väheneb 47%-lt 34%-le, kui seate minimaalne TTL 5 minutiks, 25%-le, kui minimaalne on 15 minutit, ja 13%-le, kui minimaalne on 1 tund. Optimaalne väärtus võiks olla 40 minutit.

Selle minimaalsete muutuste mõju on tohutu.

Millised on tagajärjed?

Muidugi saab teenuse üle viia uuele pilvepakkujale, uuele serverile, uuele võrgule, nõudes klientidelt uute DNS-kirjete kasutamist. Ja piisavalt madal TTL aitab sujuvalt ja märkamatult seda üleminekut teostada. Kuid kui kolida uuele infrastruktuurile, ei oota keegi, et kliendid ülemineksid uutele DNS-kirjetele 1 minuti, 5 minuti või 15 minuti jooksul. Minimaalse eluaja seadmine 40 minutiks 5 minuti asemel ei takista kasutajatel teenusele juurde pääsemast.

Siiski võimaldab see oluliselt vähendada viivitust ja parandada privaatsust ning usaldusväärsust, vältides mittevajalikke päringuid.

Muidugi ütlevad RFC-d, et TTL-i tuleks järgida rangelt. Kuid reaalsus on see, et DNS-süsteem on muutunud liiga ebatõhusaks.

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

Muidugi, on tõsiseid põhjuseid seada DNS-kirjadele madalad TTL-d. Kuid mitte 75% DNS-i liiklusest, mis praktiliselt ei muutu.

Ja kui mingil põhjusel peate tõeliselt kasutama madalaid TTL-e DNS-is, veenduge, et teie saidil ei oleks vahemälu sisse lülitatud. Samadel põhjustel.

Kui teil töötab kohalik DNS-vahemälu, nagu dnscrypt-proxy, mis võimaldab seada minimaalseid TTL-e, kasutage seda funktsiooni. See on täiesti okei. Midagi halba ei juhtu. Seadke minimaalne TTL umbes 40 minuti (2400 sekundi) ja 1 tunni vahel. Täiesti mõistlik vahemik.

Allikas: habr.com