A bassa latenza DNS hè chjave per a navigazione veloce in Internet. Per minimizzà, hè impurtante selezziunà currettamente i servitori DNS è . Ma u primu passu hè di caccià e dumande inutili.
Hè per quessa chì u DNS hè statu inizialmente cuncepitu cum'è un protokollu altamente cacheable. L'amministratori di a zona stabiliscenu un tempu per vive (TTL) per entrate individuali, è i resolutori utilizanu sta informazione quandu almacenanu entrate in memoria per evità u trafficu innecessariu.
A caching hè efficace? Un paru d'anni fà, a mo piccula ricerca hà dimustratu chì ùn era micca perfettu. Fighjemu un ochju à u statu attuale di l'affari.
Per cullà l'infurmazioni aghju patched per salvà u valore TTL per a risposta. Hè definitu cum'è u TTL minimu di i so registri per ogni dumanda entrante. Questu dà una bona visione generale di a distribuzione TTL di u trafficu reale, è ancu cunsiderà a popularità di e richieste individuali. A versione patched di u servitore hà travagliatu per parechje ore.
U settore di dati risultatu hè custituitu da 1 records (nome, qtype, TTL, timestamp). Eccu a distribuzione generale TTL (l'asse X hè TTL in seconde):
A parti di un bump minore à 86 (soprattuttu per i registri SOA), hè abbastanza chjaru chì i TTL sò in a gamma bassa. Fighjemu un ochju più vicinu:
Va bè, i TTL più grande di 1 ora ùn sò micca statisticamente significativi. Allora fighjemu nantu à a gamma 0−3600:
A maiò parte di i TTL sò da 0 à 15 minuti:
A maiò parte sò da 0 à 5 minuti:
Ùn hè micca assai bonu.
A distribuzione cumulativa rende u prublema ancu più evidenti:
A mità di e risposte DNS anu un TTL di 1 minutu o menu, è trè quarti anu un TTL di 5 minuti o menu.
Ma aspetta, hè veramente peghju. Dopu tuttu, questu hè TTL da i servitori autoritarii. Tuttavia, i resolutori di i clienti (per esempiu, routers, cache lucali) ricevenu un TTL da i resolutori upstream, è diminuisce ogni seconda.
Allora u cliente pò veramente aduprà ogni entrata per, in media, a mità di u TTL originale prima di mandà una nova dumanda.
Forse questi TTL assai bassi s'applicanu solu à richieste inusual è micca siti web populari è API? Fighjemu un ochju:
L'assi X hè TTL, l'assi Y hè a popularità di a dumanda.
Sfortunatamente, e dumande più populari sò ancu i peggiori per cache.
Facemu un zoom in:
Verdict: hè veramente male. Era digià male prima, ma hè ancu peggiu. A cache DNS hè diventata praticamente inutile. Siccomu menu persone utilizanu u resolutore DNS di u so ISP (per boni motivi), l'aumentu di a latenza diventa più notu.
A caching DNS hè diventata utile solu per u cuntenutu chì nimu visita.
Per piacè nutate ancu chì u software pò interpretà i TTL bassi.
Perchè hè cusì?
Perchè i registri DNS sò stabiliti à un TTL cusì bassu?
- I equilibratori di carica legacy sò stati lasciati cù paràmetri predeterminati.
- Ci sò miti chì u bilanciamentu di a carica DNS dipende da TTL (questu ùn hè micca veru - dapoi i tempi di Netscape Navigator, i clienti anu sceltu un indirizzu IP aleatoriu da un inseme di RR è pruvatu in modu trasparente un altru se ùn ponu micca cunnette)
- L'amministratori volenu applicà i cambiamenti immediatamente, cusì hè più faciule di pianificà.
- L'amministratore di un servitore DNS o equilibratore di carica vede u so compitu cum'è implementà in modu efficiente a cunfigurazione chì l'utilizatori dumandanu, è micca accelerà siti è servizii.
- I TTL bassi vi danu tranquillità.
- A ghjente hà inizialmente stabilitu TTL bassi per a prova è poi scurdate di cambià.
Ùn aghju micca inclusu "failover" in a lista perchè diventa sempre menu pertinenti. Sè avete bisognu di reindirizzà l'utilizatori à una altra rete solu per vede una pagina d'errore quandu assolutamente tuttu u restu hè rottu, un ritardu di più di 1 minutu hè probabilmente accettabile.
Inoltre, un TTL di un minutu significa chì, se i servitori DNS autoritarii sò bluccati per più di 1 minutu, nimu ùn puderà accede à i servizii dipendenti. È a redundanza ùn aiuterà micca se a causa hè un errore di cunfigurazione o un pirate. Per d 'altra banda, cù TTL ragiunate, assai clienti cuntinueghjanu à aduprà a cunfigurazione precedente è ùn anu mai nunda.
I servizii CDN è i bilanciatori di carica sò largamente culpèvule per i TTL bassi, soprattuttu quandu combinanu CNAME cù TTL bassi è registri cù TTL ugualmente bassi (ma indipendenti):
$ 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
Ogni volta chì u CNAME o qualcunu di i registri A scade, una nova dumanda deve esse mandata. Tutti dui anu un TTL di 30 seconde, ma ùn hè micca listessu. U TTL mediu attuale serà di 15 seconde.
Ma aspetta ! Hè ancu peghju. Certi resolutori si cumportanu assai male in questa situazione cù dui TTL bassi assuciati:
$ 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
U risolutore di Livellu 3 probabilmente corre nantu à BIND. Se continuate à mandà sta dumanda, un TTL di 1 serà sempre tornatu. raw.githubusercontent.com ùn hè mai in cache.
Eccu un altru esempiu di una tale situazione cù un duminiu assai populari:
$ 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
Almenu trè record CNAME. Ai. Unu hà un TTL decentu, ma hè cumplettamente inutile. L'altri CNAME anu un TTL iniziale di 60 seconde, ma per i domini akamai.net u TTL massimu hè 20 seconde è nimu d'elli sò in fase.
E duminii chì sondanu constantemente i dispositi Apple?
$ 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
U stessu prublema cum'è Firefox è TTL seranu appiccicati à 1 secondu a maiò parte di u tempu quandu si usa u resolutore Level3.
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
À l'arregistramentu safebrowsing.googleapis.com U valore TTL hè 60 seconde, cum'è domini Facebook. È, di novu, da u puntu di vista di u cliente, sti valori sò dimezzati.
Chì ne dite di stabilisce un TTL minimu?
Utilizendu u nome, u tipu di dumanda, TTL, è u marcatu di tempu inizialmente almacenatu, aghju scrittu un script per simulà 1,5 milioni di richieste chì passanu per un resolutore di cache per stimà u voluminu di richieste innecessarii mandate per una entrata di cache scaduta.
47,4% di e dumande sò state fatte dopu chì un record esistente era scadutu. Questu hè irragionevolmente altu.
Chì serà l'impattu nantu à u caching se u TTL minimu hè stabilitu?
L'assi X hè i valori minimi TTL. I registri cù TTL di fonte sopra à stu valore ùn sò micca affettati.
L'assi Y hè u percentualità di richieste da un cliente chì hà digià una entrata in cache, ma hè scaduta è face una nova dumanda.
A parte di e dumande "extra" hè ridutta da u 47% à u 36% solu per stabilisce u TTL minimu à 5 minuti. Fixendu u minimu TTL à 15 minuti, u numeru di sti dumande scende à 29%. Un TTL minimu di 1 ora li riduce à 17%. Differenza significativa!
Cume di ùn cambià nunda in u latu di u servitore, ma invece di stabilisce u TTL minimu in i cache DNS di u cliente (routers, resolutori lucali)?
U numeru di richieste richieste scende da u 47% à u 34% cù un TTL minimu di 5 minuti, à u 25% cù un minimu di 15 minuti, è à u 13% cù un minimu di 1 ora. Forsi 40 minuti hè ottimali.
L'impattu di stu picculu cambiamentu hè enormu.
Chì sò e cunsequenze ?
Di sicuru, u serviziu pò esse spustatu à un novu fornitore di nuvola, un novu servitore, una nova rete, chì impone à i clienti di utilizà l'ultimi records DNS. È un TTL abbastanza chjucu aiuta à fà una transizione cusì liscia è imperceptible. Ma cù a transizione à a nova infrastruttura, nimu ùn aspetta chì i clienti migrànu à novi registri DNS in 1 minutu, 5 minuti o 15 minuti. Stabilisce u TTL minimu à 40 minuti invece di 5 minuti ùn impedisce micca l'utilizatori di accede à u serviziu.
Tuttavia, questu riducerà significativamente a latenza è migliurà a privacy è l'affidabilità evitendu richieste inutili.
Di sicuru, i RFC dicenu chì TTL deve esse strettamente seguitu. Ma a realità hè chì u sistema DNS hè diventatu troppu inefficiente.
Sè vo travagliate cù servitori DNS autoritarii, verificate i vostri TTL. Avete veramente bisognu di tali valori ridiculamente bassi?
Di sicuru, ci sò boni ragiuni per stabilisce i picculi TTL per i registri DNS. Ma micca per u 75% di u trafficu DNS chì ferma praticamente invariatu.
E se per una certa ragione avete bisognu di utilizà TTL bassu per DNS, à u stessu tempu assicuratevi chì u vostru situ ùn hà micca attivatu a cache. Per i stessi motivi.
Sì avete una cache DNS locale in esecuzione, cum'è chì permette di stabilisce TTL minimi, aduprate sta funzione. Questu hè bè. Ùn succede nunda di male. Pone u TTL minimu à circa 40 minuti (2400 seconde) è 1 ora. Una gamma abbastanza raghjone.
Source: www.habr.com