Lae DNS-vertraging is die sleutel tot vinnige internetblaai. Om dit te minimaliseer, is dit belangrik om DNS-bedieners versigtig te kies en . Maar die eerste stap is om van nuttelose navrae ontslae te raak.
Dit is hoekom DNS oorspronklik ontwerp is as 'n hoogs kasbare protokol. Sone-administrateurs stel 'n tyd om te lewe (TTL) vir individuele inskrywings, en oplossers gebruik hierdie inligting wanneer inskrywings in die geheue stoor om onnodige verkeer te vermy.
Is caching effektief? 'n Paar jaar gelede het my klein navorsing getoon dat dit nie perfek was nie. Kom ons kyk na die huidige stand van sake.
Om inligting in te samel het ek gelap om die TTL-waarde vir die reaksie te stoor. Dit word gedefinieer as die minimum TTL van sy rekords vir elke inkomende versoek. Dit gee 'n goeie oorsig van die TTL-verspreiding van werklike verkeer, en neem ook die gewildheid van individuele versoeke in ag. Die reggemaakte weergawe van die bediener het 'n paar uur gewerk.
Die resulterende datastel bestaan uit 1 583 579 rekords (naam, qtype, TTL, tydstempel). Hier is die algehele TTL-verspreiding (X-as is TTL in sekondes):
Afgesien van 'n geringe stamp by 86 (meestal vir SOA-rekords), is dit redelik duidelik dat die TTL's in die lae reeks is. Kom ons kyk van naderby:
Goed, TTL'e langer as 1 uur is nie statisties betekenisvol nie. Kom ons fokus dan op die reeks 0−3600:
Die meeste TTL'e is van 0 tot 15 minute:
Die oorgrote meerderheid is van 0 tot 5 minute:
Dit is nie baie goed nie.
Kumulatiewe verspreiding maak die probleem nog duideliker:
Die helfte van die DNS-antwoorde het 'n TTL van 1 minuut of minder, en driekwart het 'n TTL van 5 minute of minder.
Maar wag, dit is eintlik erger. Dit is immers TTL van gesaghebbende bedieners. Kliënt-resoleerders (bv. routers, plaaslike kas) ontvang egter 'n TTL vanaf stroomop-resoleerders, en dit neem elke sekonde af.
Die kliënt kan dus eintlik elke inskrywing vir gemiddeld die helfte van die oorspronklike TTL gebruik voordat 'n nuwe versoek gestuur word.
Miskien is hierdie baie lae TTL's slegs van toepassing op ongewone versoeke en nie gewilde webwerwe en API's nie? Kom ons kyk:
Die X-as is TTL, die Y-as is navraaggewildheid.
Ongelukkig is die gewildste navrae ook die ergste om te kas.
Kom ons zoem in:
Uitspraak: dit is regtig erg. Dit was voorheen al erg, maar dit het nog erger geword. DNS-kas het feitlik nutteloos geword. Aangesien minder mense hul ISP se DNS-oplosser gebruik (om goeie redes), word die toename in latensie meer opvallend.
DNS-kas het slegs nuttig geword vir inhoud wat niemand besoek nie.
Neem asseblief ook kennis dat die sagteware kan interpreteer lae TTL's.
Hoekom so?
Waarom is DNS-rekords op so 'n lae TTL gestel?
- Verouderde lasbalanseerders is met verstekinstellings gelaat.
- Daar is mites dat DNS-lasbalansering van TTL afhang (dit is nie waar nie - sedert die dae van Netscape Navigator het kliënte 'n ewekansige IP-adres uit 'n stel RR'e gekies en deursigtig 'n ander probeer as hulle nie kan koppel nie)
- Administrateurs wil veranderinge onmiddellik toepas, so dit is makliker om te beplan.
- Die administrateur van 'n DNS-bediener of lasbalanseerder beskou sy taak as om die konfigurasie wat gebruikers versoek doeltreffend te ontplooi, en nie om werwe en dienste te bespoedig nie.
- Lae TTL's gee jou gemoedsrus.
- Mense stel aanvanklik lae TTL's vir toetsing en vergeet dan om dit te verander.
Ek het nie "failover" by die lys ingesluit nie, want dit raak al hoe minder relevant. As jy gebruikers na 'n ander netwerk moet herlei net om 'n foutbladsy te vertoon wanneer absoluut alles anders gebreek is, is 'n vertraging van meer as 1 minuut waarskynlik aanvaarbaar.
Boonop beteken 'n een-minuut TTL dat as gesaghebbende DNS-bedieners vir meer as 1 minuut geblokkeer word, niemand anders toegang tot afhanklike dienste sal hê nie. En oortolligheid sal nie help as die oorsaak 'n konfigurasiefout of 'n hack is nie. Aan die ander kant, met redelike TTL's, sal baie kliënte voortgaan om die vorige konfigurasie te gebruik en nooit iets agterkom nie.
CDN-dienste en lasbalanseerders is grootliks te blameer vir lae TTL's, veral wanneer hulle CNAME's kombineer met lae TTL's en rekords met ewe lae (maar onafhanklike) TTL's:
$ 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
Wanneer die CNAME of enige van die A-rekords verval, moet 'n nuwe versoek gestuur word. Albei het 'n 30 sekonde TTL, maar dit is nie dieselfde nie. Die werklike gemiddelde TTL sal 15 sekondes wees.
Maar wag! Dit is nog erger. Sommige oplossers tree baie sleg op in hierdie situasie met twee gepaardgaande lae TTL's:
$ boor 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
Die Level3 resolver loop waarskynlik op BIND. As jy aanhou om hierdie versoek te stuur, sal 'n TTL van 1 altyd teruggestuur word. In wese, raw.githubusercontent.com word nooit gekas nie.
Hier is nog 'n voorbeeld van so 'n situasie met 'n baie gewilde domein:
$ 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
Ten minste drie CNAME-rekords. Ai. Mens het 'n ordentlike TTL, maar dit is heeltemal nutteloos. Ander CNAME's het 'n aanvanklike TTL van 60 sekondes, maar vir domeine akamai.net die maksimum TTL is 20 sekondes en nie een van hulle is in fase nie.
Wat van domeine wat voortdurend Apple-toestelle ondersoek?
$ 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
Dieselfde probleem as Firefox en TTL sal die meeste van die tyd op 1 sekonde vassit wanneer jy Level3 resolver gebruik.
Dropbox?
$ boor client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN 'N 162.125.67.3 $ boor 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
By die opname safebrowsing.googleapis.com TTL-waarde is 60 sekondes, soos Facebook-domeine. En weereens, vanuit die kliënt se oogpunt, word hierdie waardes gehalveer.
Hoe gaan dit met die opstel van 'n minimum TTL?
Deur die naam, versoektipe, TTL en oorspronklik gestoorde tydstempel te gebruik, het ek 'n skrip geskryf om 1,5 miljoen versoeke te simuleer wat deur 'n kasoplosser gaan om die volume onnodige versoeke te skat wat gestuur is as gevolg van 'n verstrykte kasinskrywing.
47,4% van versoeke is gemaak nadat 'n bestaande rekord verval het. Dit is onredelik hoog.
Wat sal die impak op cache wees as die minimum TTL gestel word?
Die X-as is die minimum TTL-waardes. Rekords met bron-TTL'e bo hierdie waarde word nie geraak nie.
Die Y-as is die persentasie versoeke van 'n kliënt wat reeds 'n kasinskrywing het, maar dit het verval en 'n nuwe versoek rig.
Die aandeel van “ekstra” versoeke word van 47% tot 36% verminder deur bloot die minimum TTL op 5 minute te stel. Deur die minimum TTL op 15 minute te stel, daal die aantal van hierdie versoeke tot 29%. 'n Minimum TTL van 1 uur verminder hulle tot 17%. Beduidende verskil!
Hoe gaan dit met om niks aan die bedienerkant te verander nie, maar eerder die minimum TTL in kliënt DNS-kas (routers, plaaslike oplossers) in te stel?
Die aantal versoeke wat vereis word, daal van 47% tot 34% met 'n minimum TTL van 5 minute, tot 25% met 'n minimum van 15 minute, en tot 13% met 'n minimum van 1 uur. Miskien is 40 minute optimaal.
Die impak van hierdie klein verandering is enorm.
Wat is die gevolge?
Natuurlik kan die diens na 'n nuwe wolkverskaffer, nuwe bediener, nuwe netwerk geskuif word, wat vereis dat kliënte die nuutste DNS-rekords moet gebruik. En 'n redelik klein TTL help om so 'n oorgang glad en onmerkbaar te maak. Maar met die oorgang na nuwe infrastruktuur, verwag niemand dat kliënte binne 1 minuut, 5 minute of 15 minute na nuwe DNS-rekords sal migreer nie. Deur die minimum TTL op 40 minute in plaas van 5 minute te stel, sal gebruikers nie verhoed om toegang tot die diens te kry nie.
Dit sal egter latensie aansienlik verminder en privaatheid en betroubaarheid verbeter deur onnodige versoeke te vermy.
Natuurlik sê die RFC's dat TTL streng gevolg moet word. Maar die realiteit is dat die DNS-stelsel te ondoeltreffend geword het.
As jy met gesaghebbende DNS-bedieners werk, gaan asseblief jou TTL's na. Het jy regtig sulke belaglik lae waardes nodig?
Natuurlik is daar goeie redes om klein TTL's vir DNS-rekords op te stel. Maar nie vir die 75% van DNS-verkeer wat feitlik onveranderd bly nie.
En as jy om een of ander rede werklik lae TTL's vir DNS moet gebruik, maak terselfdertyd seker dat jou werf nie caching geaktiveer het nie. Om dieselfde redes.
As jy 'n plaaslike DNS-kas loop, soos wat jou toelaat om minimum TTL's te stel, gebruik hierdie funksie. Dit is goed. Niks sleg sal gebeur nie. Stel die minimum TTL op ongeveer 40 minute (2400 sekondes) en 1 uur. Nogal 'n redelike reeks.
Bron: will.com