Niddereg DNS Latenz ass de Schlëssel fir séier Internet Surfen. Fir et ze minimiséieren, ass et wichteg d'DNS Server suergfälteg ze wielen an anonyme Relais. Awer den éischte Schrëtt ass fir nëtzlos Ufroen lass ze ginn.

Dëst ass firwat DNS ursprénglech als héich cacheable Protokoll entworf gouf. Zone Administrateuren setzen eng Zäit fir ze liewen (TTL) fir eenzel Entréen, a Resolvere benotzen dës Informatioun wann Dir Entréen an der Erënnerung späichert fir onnéideg Traffic ze vermeiden.

Ass Cache effektiv? Virun e puer Joer huet meng kleng Fuerschung gewisen datt et net perfekt war. Loosst eis den aktuellen Zoustand kucken.

Fir Informatiounen ze sammelen hunn ech gepatched Verschlësselte DNS Server fir den TTL Wäert fir d'Äntwert ze späicheren. Et ass definéiert als de Minimum TTL vu senge Rekorder fir all erakommen Ufro. Dëst gëtt e gudden Iwwerbléck iwwer d'TTL Verdeelung vum realen Traffic, a berücksichtegt och d'Popularitéit vun individuellen Ufroen. Déi patched Versioun vum Server huet e puer Stonnen geschafft.

Déi resultéierend Dateset besteet aus 1 records (Numm, qtype, TTL, Zäitstempel). Hei ass d'Gesamt TTL Verdeelung (X-Achs ass TTL a Sekonnen):

Nieft engem klenge Bump bei 86 (meeschtens fir SOA-Records), ass et zimlech kloer datt d'TTLs am nidderegen Beräich sinn. Loosst eis e bësse méi no kucken:

Okay, TTLs méi wéi 1 Stonn sinn net statistesch bedeitend. Dann konzentréiere mir eis op de Beräich 0-3600:

Déi meescht TTLs si vun 0 bis 15 Minutten:

Déi grouss Majoritéit si vun 0 bis 5 Minutten:

Et ass net ganz gutt.

Kumulativ Verdeelung mécht de Problem nach méi kloer:

D'Halschent vun den DNS Äntwerten hunn en TTL vun 1 Minutt oder manner, an Dräi Véierel hunn en TTL vu 5 Minutten oder manner.

Awer waart, et ass tatsächlech méi schlëmm. No allem ass dëst TTL vun autoritäre Serveren. Wéi och ëmmer, Client Resolveren (zB Router, lokal Cache) kréien en TTL vu Upstream Resolveren, an et fällt all Sekonn.

Also de Client kann tatsächlech all Entrée fir am Duerchschnëtt d'Halschent vun der ursprénglecher TTL benotzen ier hien eng nei Ufro schéckt.

Vläicht gëllen dës ganz niddereg TTLs nëmme fir ongewéinlech Ufroen an net populär Websäiten an APIen? Loosst eis kucken:

D'X Achs ass TTL, d'Y Achs ass Ufro Popularitéit.

Leider sinn déi populärste Ufroen och déi schlëmmst fir ze cache.

Loosst eis zoomen:

Uerteel: et ass wierklech schlecht. Virdrun war et scho schlecht, awer et gouf nach méi schlëmm. DNS Caching ass quasi nëtzlos ginn. Well manner Leit hiren ISP säin DNS Resolver benotzen (aus gudde Grënn), gëtt d'Erhéijung vun der latency méi merkbar.

DNS Caching ass nëmme nëtzlech ginn fir Inhalter déi keen besicht.

Notéiert w.e.g. och datt d'Software kann anescht niddereg TTL interpretéieren.

Firwat ass et esou?

Firwat sinn DNS-Records op sou niddereg TTL gesat?

• Legacy Lastbalancer goufe mat Standardastellunge verlooss.
• Et gi Mythen datt DNS Belaaschtungsbalancéierung vun TTL hänkt (dëst ass net wouer - zënter den Deeg vum Netscape Navigator hunn d'Clienten eng zoufälleg IP Adress aus enger Rei vu RRs gewielt an transparent probéiert eng aner wa se net kënne verbannen)
• D'Administrateure wëllen d'Ännerungen direkt applizéieren, sou datt et méi einfach ass ze plangen.
• Den Administrateur vun engem DNS-Server oder Lastbalancer gesäit seng Aufgab als effizient d'Konfiguratioun z'installéieren déi d'Benotzer ufroen, an net d'Siten a Servicer ze beschleunegen.
• Niddereg TTLs ginn Iech Fridden vum Geescht.
• D'Leit setzen am Ufank niddereg TTLs fir Testen a vergiessen se dann z'änneren.

Ech hunn "Failover" net an der Lëscht gesat, well et ëmmer manner relevant gëtt. Wann Dir d'Benotzer an en anert Netzwierk muss viruleeden just fir eng Fehlersäit ze weisen wann absolut alles anescht gebrach ass, ass eng Verzögerung vu méi wéi 1 Minutt wahrscheinlech akzeptabel.

Zousätzlech heescht eng TTL vun enger Minutt datt wann autoritär DNS-Server fir méi wéi 1 Minutt blockéiert sinn, keen aneren fäeg ass op ofhängeg Servicer ze kommen. An Redundanz hëlleft net wann d'Ursaach e Konfiguratiounsfehler oder en Hack ass. Op der anerer Säit, mat raisonnabel TTLs, wäerte vill Cliente weider déi viregt Konfiguratioun benotzen an ni eppes bemierken.

CDN Servicer a Lastbalancer si gréisstendeels Schold fir niddereg TTLs, besonnesch wa se CNAMEs mat nidderegen TTLs a Rekorder mat gläich nidderegen (awer onofhängegen) TTLs kombinéieren:

$ 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

Wann ëmmer de CNAME oder eng vun den A-Records oflafen, muss eng nei Ufro geschéckt ginn. Béid hunn eng 30 Sekonnen TTL, awer et ass net d'selwecht. Déi aktuell duerchschnëttlech TTL wäert 15 Sekonnen sinn.

Mee waart! Et ass nach méi schlëmm. E puer Resolvere behuelen sech ganz schlecht an dëser Situatioun mat zwee assoziéierten nidderegen TTLs:

$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 AN CNAME github.map.fastly.net. github.map.fastly.net. 1 AN A 151.101.16.133

Den Level3 Resolver leeft wahrscheinlech op BIND. Wann Dir weider dës Ufro schéckt, gëtt e TTL vun 1 wesentlech zréckginn. raw.githubusercontent.com ass ni cache.

Hei ass en anert Beispill vun esou enger Situatioun mat engem ganz populäre Domain:

$ 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

Op d'mannst dräi CNAME records. Aj. Een huet eng uerdentlech TTL, mee et ass komplett nëtzlos. Aner CNAMEs hunn eng initial TTL pa 60 Sekonnen, mee fir Domainen akamai.net déi maximal TTL ass 20 Sekonnen a keng vun hinnen ass an der Phas.

Wat iwwer Domainen déi dauernd Apple Apparater pollen?

$ 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

Selwechte Problem wéi Firefox an TTL wäerte bei 1 Sekonn meeschtens hänke bleiwen wann Dir Level3 Resolver benotzt.

Dropbox?

$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 AN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 AN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 AN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 AN A 162.125.64.3

Op der Opnahm safebrowsing.googleapis.com TTL Wäert ass 60 Sekonnen, wéi Facebook Domainen. An, erëm, aus der Siicht vum Client, sinn dës Wäerter halbéiert.

Wéi wier et mat engem Minimum TTL ze setzen?

Mam Numm, Ufrotyp, TTL, an ursprénglech gespäichert Zäitstempel, hunn ech e Skript geschriwwen fir 1,5 Milliounen Ufroen ze simuléieren, déi duerch e Caching-Resolver passéieren, fir de Volume vun onnéideg Ufroe ze schätzen, déi wéinst engem ofgelaften Cache-Entrée geschéckt ginn.

47,4% vun Ufroe goufen no engem existente Rekord ofgelaf. Dëst ass onraisonnabel héich.

Wat wäert den Impakt op Caching sinn wann de Minimum TTL gesat gëtt?

D'X Achs ass de Minimum TTL Wäerter. Records mat Quell TTLs iwwer dëse Wäert sinn net betraff.

D'Y-Achs ass de Prozentsaz vun Ufroe vun engem Client, dee schonn e Cache-Entrée huet, awer et ass ofgelaf a mécht eng nei Ufro.

Den Undeel vun "extra" Ufroe gëtt vu 47% op 36% reduzéiert andeems se einfach de Minimum TTL op 5 Minutten setzen. Andeems Dir de Minimum TTL op 15 Minutten setzt, fällt d'Zuel vun dësen Ufroen op 29%. E Minimum TTL vun 1 Stonn reduzéiert se op 17%. Bedeitend Ënnerscheed!

Wéi wier et mat näischt op der Server Säit z'änneren, mee amplaz de Minimum TTL an Client DNS Cache (Router, lokal Resolver) ze setzen?

D'Zuel vun den néideg Ufroe fällt vu 47% op 34% mat engem Minimum TTL vu 5 Minutten, op 25% mat engem Minimum vu 15 Minutten, an op 13% mat engem Minimum vun 1 Stonn. Vläicht ass 40 Minutten optimal.

Den Impakt vun dëser klenger Ännerung ass enorm.

Wat sinn d'Konsequenzen?

Natierlech kann de Service op en neie Cloud-Provider, neie Server, neien Netzwierk geplënnert ginn, wat Clienten erfuerdert déi lescht DNS-Records ze benotzen. An e relativ klengen TTL hëlleft esou en Iwwergang glat an onmerkbar ze maachen. Awer mam Iwwergank op eng nei Infrastruktur erwaart keen datt Cliente bannent 1 Minute, 5 Minuten oder 15 Minuten op nei DNS records migréieren. De Minimum TTL op 40 Minutten amplaz vu 5 Minutten ze setzen verhënnert d'Benotzer net op de Service ze kommen.

Wéi och ëmmer, dëst wäert d'Latenz wesentlech reduzéieren an d'Privatsphär an d'Zouverlässegkeet verbesseren andeems onnéideg Ufroe vermeit.

Natierlech soen d'RFCen datt TTL strikt gefollegt muss ginn. Awer d'Realitéit ass datt den DNS System ze ineffizient ginn ass.

Wann Dir mat autoritären DNS Server schafft, kontrolléiert w.e.g. Är TTLs. Braucht Dir wierklech esou lächerlech niddereg Wäerter?

Natierlech ginn et gutt Grënn fir kleng TTLs fir DNS records ze setzen. Awer net fir déi 75% vum DNS Traffic dee praktesch onverännert bleift.

A wann Dir aus iergendengem Grond wierklech niddereg TTLs fir DNS benotze musst, gitt gläichzäiteg sécher datt Äre Site net Cache aktivéiert huet. Fir déi selwecht Grënn.

Wann Dir e lokalen DNS-Cache leeft, wéi z dnscrypt-Proxydéi erlaabt Iech Minimum TTLs ze setzen, benotzen dës Funktioun. Dëst ass gutt. Näischt Schlecht wäert geschéien. Setzt de Minimum TTL op ongeféier 40 Minutten (2400 Sekonnen) an 1 Stonn. Ganz raisonnabel Gamme.

Source: will.com