Madala DNS-latents on võtmetähtsusega tegur kiire interneti toimimises. Selle minimaalne hoidmine nõuab hoolikat DNS-serverite valimist ja anonüümsed rerouted. Kuid kõigepealt tuleb vabaneda tarbetutest päringutest.

Just seetõttu loodi DNS algselt väga vahemällu salvestatava protokollina. Domeeni administraatorid seadistavad eluea (TTL) üksikutele kirjadele, ja resolvijad kasutavad seda teavet kirjade mälu hoidmiseks, et vältida tarbetut liiklust.

Kas vahemällu salvestamine on efektiivne? Mõni aasta tagasi näitas mu väike uurimus, et see ei ole ideaalne. Vaatame praegust olukorda.

Teabe kogumiseks parandasin ma Encrypted DNS Server TTL väärtuse säilitamiseks vastuse jaoks. See määratletakse kui kirjade minimaalne TTL, iga sisenemise päringu jaoks. See annab hea ülevaate reaalsete liikluse TTL jaotumisest ning arvestab üksikute päringute populaarsust. Parandatud serveri versioon töötas paar tundi.

Saadud andmekogum koosneb 1 583 579 kirjest (nimi, qtype, TTL, ajatempleid). Siin on TTL üldine jaotumine (X-telg on TTL sekundites):

Kui mitte arvestada väikest tõusu 86 400 (peamiselt SOA kirjade jaoks), on üsna ilmne, et TTL-d jäävad madalale tasemele. Vaatame lähemalt:

Noh, TTL, mis on pikem kui 1 tund, ei ole statistiliselt oluline. Seega keskendume vahemikule 0−3600:

Enamik TTL-d on vahemikus 0 kuni 15 minutit:

Valdav enamus on vahemikus 0 kuni 5 minutit:

See ei ole eriti hea.

Kumulatiivne jaotumine muudab probleemi veelgi selgemaks:

Pooles DNS-vastustes on TTL 1 minut või vähem, kolmes neljandikus on see 5 minutit või vähem.

Aga oota, tegelikult on asi veel hullem. See TTL on autoriteetsete serverite poolt. Siiski saavad kliendi resolvijad (nt ruuteri, kohalikud vahemälud) TTL kõrgemalt resolvijalt ning see väheneb iga sekundi järel.

Seega saab klient tegelikult igat kirjet keskmiselt kasutada poole algsest TTL-ist, pärast mida saadab ta uue päringu.

Võib-olla, et need väga madalad TTL-id puudutavad ainult ebatavalisi päringuid, mitte populaarseid veebisaite ja API-sid? Vaadakem:

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

Kahjuks on kõige populaarsemate päringute vahemällu salvestamine kõige halvem.

Läheneme sellele:

Kohtuotsus: kõik on tõesti halvasti. Juba eelnevalt oli halb, kuid nüüd on veel hullem. DNS-i vahemälu on muutunud praktiliselt kasutuks. Kuna üha vähem inimesi kasutab oma pakkuja DNS-resolvrid (mõistetavatel põhjustel), muutub viivitus märgatavamaks.

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

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

Miks nii?

Miks on DNS-i kirjade jaoks seatud nii madal TTL?

• Aegunud koormuse tasakaalustajad on jäänud vaike seadistustega.
• Levitavad müüte, et DNS-i koormuse tasakaalus sõltub TTL-ist (see ei ole tõsi – alates Netscape Navigatori ajast valivad kliendid juhusliku IP-aadressi RR komplektist ja proovivad sujuvalt teist, kui ei õnnestu ühenduda)
• DNS-serveri administraatorid soovivad muudatusi kohe rakendada, seetõttu on see lihtsam planeerida.
• DNS-serveri või koormuse tasakaalustaja administraator peab oma ülesandeks tõhusalt rakendama konfiguratsiooni, mida kasutajad nõuavad, mitte kiirendama veebilehtede ja teenuste tööd.
• Madalamad TTL-id annavad meelerahu.
• Inimesed seadistavad alguses madalad TTL-id katsetamiseks ja unustavad need hiljem muuta.

Ma ei lisanud „juhtimissektoreid“ nimekirja, kuna see muutub üha vähem asjakohaseks. Kui peate suunama kasutajad teise võrku ainult vea lehe kuvamiseks, kui kõik muu on katki, on tõenäoliselt lubatav viivitus üle 1 minuti.

Lisaks tähendab minuti TTL, et kui autoriteetsed DNS-serverid on blokeeritud rohkem kui 1 minut, ei saa keegi enam juurde pääseda sõltuvatele teenustele. Ja üleolekus ei aita, kui põhjuseks on konfiguratsiooni tõrge või häkkimine. Teiselt poolt, mõistlike TTL-idega jätkab palju kliente eelmise konfiguratsiooni kasutamist ega märka kunagi midagi.

Madala TTL-i eest on suures osas süüdistada CDN-teenuseid ja koormuse tasakaalustajaid, eriti kui nad kombineerivad CNAME jooksva madala TTL-iga ja rekorditega, millel on samuti madalad (kuid sõltumatud) TTL-id:

$ 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 ükskõik milline A-kirje aegub, tuleb saata uus päring. Mõlema TTL on 30 sekundit, kuid need ei ühti. Tegelik keskmine TTL on 15 sekundit.

Aga oodake! Kõik on isegi hullem. Mõned resolverid käituvad sellistes olukordades, kus on kaks 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öötleb ilmselt BIND-i. Kui te 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 selline olukord 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. Oi. Ühel on korralik TTL, kuid see on täiesti kasutu. Teistes CNAME-des on algne TTL 60 sekundit, kuid domeenide akamai.net maksimaalne TTL on 20 sekundit ja ükski neist ei ole faasis.

Kuidas on domeenidega, mis pidevalt küsivad Apple'i seadmete kaudu?

$ 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 enamiku ajast 1 sekundi peale, kui kasutatakse 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

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

Kuidas oleks minimaalse TTL-i seadistamisega?

Kasutades nime, päringutüüpi, TTL-i ja algselt salvestatud ajatemplit, kirjutasin skripti, et simuleerida 1,5 miljoni päringu läbimist läbi vahemäluresolveri, et hinnata liigsete päringute hulka, mis saadetakse aegunud vahemälukirje tõttu.

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

Milline oleks mõju vahemälule, kui minimaalse TTL-i seaksime?

X-akse on TTL-i minimaalne väärtus. Kirjed, mille algne TTL on sellest väärtusest kõrgem, ei mõjuta.

Y-akse näitab protsenti kliendi päringutest, kellel on juba vahemällu salvestatud kirje, kuid selle kehtivusaeg on lõppenud ning ta teeb uue päringu.

Liigne päringute osakaal väheneb 47% -lt 36% -le, kui seada minimaalne TTL 5 minutile. Kui minimaalne TTL on 15 minutit, väheneb see osakaal 29% -le. Minimaalne TTL 1 tunni kohta vähendab selle 17% -ni. Oluline erinevus!

Kuidas oleks, kui te ei muudaks serveri poolt midagi, vaid seataksite minimaalset TTL-i kliendi DNS-vahemälus (ruutereid, kohalikke resolvereid)?

Nõutavate päringute arv väheneb 47% -lt 34% -le, kui seada minimaalne TTL 5 minutile, 25% -ni minimaalsega 15 minutit ja 13% -ni minimaalsega 1 tund. Võib-olla on optimaalne väärtus 40 minutit.

Selle minimaalse muudatuse mõju on tohutu.

Millised on tagajärjed?

Muidugi, teenuse saab üle viia uuele pilvepakkujale, uuele serverile, uuele võrgu, nõudes klientidelt viimaste DNS-kirjete kasutamist. Ja piisavalt madal TTL aitab sujuvalt ja märkamatult seda üleminekut teostada. Kuid uusi DNS-kirjeid ei oodata, et kliendid aktsepteeriksid 1 minuti, 5 minuti või 15 minuti jooksul. Minimaalse eluea seadmine 40 minutile ei takista kasutajatel teenusele juurdepääsu.

Kuid see võimaldab oluliselt vähendada viivitust ja suurendada privaatsust ning usaldusväärsust, vältides tarbetuid päringuid.

Muidugi ütleb RFC, et TTL-i tuleb rangelt järgida. Kuid reaalsus on see, et DNS-süsteem on muutunud liiga ebaefektiivseks.

Kui teie töötab autoritatiivsete DNS-serveritega, palun kontrollige oma TTL-e. Kas teil tõesti on vaja nii absurdelt madalaid väärtusi?

Muidugi on olemas ka põhjusi, miks seada madalaid TTL-e DNS-kirjadele. Kuid mitte 75% DNS-i liiklusest, mis praktiliselt ei muutu.

Ja kui mingitel põhjustel peate tõeliselt kasutama madalaid TTL-e DNS-ile, veenduge samas, et teie saidil pole aktiivne vahemälumine. Sama põhjusel.

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

Allikas: habr.com