Domain Name System (DNS) latency is een belangrijk onderdeel voor het hebben van een goede online ervaring. En om DNS-latency te minimaliseren, speelt zorgvuldig kiezen van DNS-servers en anonimisatierelais een belangrijke rol.
maar de beste manier om latency te minimaliseren is om te voorkomen dat nutteloze query ‘ s worden verzonden om mee te beginnen. Daarom is de DNS ontworpen, vanaf dag één, om een zwaar cacheable protocol te zijn. Individuele records hebben een time-to-live (TTL), oorspronkelijk ingesteld door zonebeheerders, en resolvers gebruiken deze informatie om deze records in het geheugen te bewaren om onnodig verkeer te voorkomen.
is caching efficiënt? Een snelle studie die ik een paar jaar geleden maakte, toonde aan dat er ruimte was voor verbetering. Vandaag wil ik de huidige stand van zaken opnieuw bekijken.
hiervoor heb ik een versleutelde DNS-Server gepatcht om de originele TTL van een antwoord op te slaan, gedefinieerd als de minimale TTL van de records, voor elke inkomende query. Dit geeft ons een goed overzicht van de TTL-distributie van real-world traffic, maar zorgt ook voor de populariteit van individuele zoekopdrachten.
die gepatchte versie moest nog een paar uur draaien. De resulterende dataset bestaat uit 1.583.579 (naam, qtype, TTL, tijdstempel) tupels. Hier is de totale TTL-verdeling (de x – as is de TTL in seconden):
naast een verwaarloosbare hobbel op 86.400 (voornamelijk voor SOA records), is het vrij duidelijk dat TTLs in het lage bereik liggen. Laten we inzoomen:
goed, TTL ‘ s boven 1 uur zijn statistisch onbelangrijk. Laten we ons concentreren op het bereik 0-3,600:
en waar de meeste TTL ‘ s tussen 0 en 15 minuten zitten:
De overgrote meerderheid ligt tussen 0 en 5 minuten:
Dit is niet geweldig. De cumulatieve verdeling kan de kwestie nog duidelijker maken:
De helft van het Internet heeft een TTL van 1 minuut of minder, en driekwart heeft een TTL van 5 minuten of minder.
maar wacht, Dit is eigenlijk erger. Dit zijn TTLs zoals gedefinieerd door gezaghebbende servers. Echter, TTLs opgehaald van client resolvers (bijvoorbeeld, routers, lokale caches) krijgen een TTL die upstream resolvers decrement elke seconde. Dus, gemiddeld, de werkelijke duur van een client kan een gecached item gebruiken voordat een nieuwe query is de helft van de oorspronkelijke TTL.
misschien hebben deze zeer lage TTL ’s alleen invloed op ongewone query’ s, en niet op populaire websites en API ‘ s. Laten we eens kijken:
helaas zijn de meest populaire query ‘ s ook het meest zinloos om te cachen. Laten we inzoomen.:
oordeel: het is echt slecht, of liever gezegd het was al slecht, en het is erger geworden. DNS caching is bijna nutteloos geworden. Met minder mensen die de DNS-resolver van hun ISP gebruiken (om goede redenen), wordt de verhoogde latency meer merkbaar. DNS-caching is alleen nuttig geworden voor inhoud die niemand bezoekt. Merk ook op dat software lage TTLs anders kan interpreteren.
waarom?
Waarom worden DNS-records ingesteld met zulke lage TTLs?
- oudere load balancers worden achtergelaten met de standaardinstellingen.
- de stedelijke legende dat op DNS gebaseerde taakverdeling afhankelijk is van TTLs (dat is niet zo).
- beheerders willen dat hun wijzigingen onmiddellijk worden toegepast, omdat dit minder planningswerk kan vereisen.
- als DNS-of load-balancer-beheerder is het uw taak om de configuratie die mensen vragen efficiënt te implementeren, niet om websites en services snel te maken.
- lage TTLs geven gemoedsrust.
Ik neem ‘for failover’ niet op in die lijst, omdat dit steeds minder relevant is geworden. Als de bedoeling is om gebruikers om te leiden naar een ander netwerk alleen maar om een fail walvis pagina weer te geven wanneer absoluut al het andere in brand staat, met meer dan een minuut vertraging is waarschijnlijk aanvaardbaar.
CDN ‘ s en load-balancers zijn grotendeels verantwoordelijk, vooral wanneer ze CNAME records combineren met korte TTLS met records die ook korte (maar onafhankelijke) TTLs hebben:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
een nieuwe query moet worden verzonden wanneer de CNAME of een van de A records verlopen. Ze hebben beide een 30 seconden TTL maar zijn niet in fase. De werkelijke gemiddelde TTL zal 15 seconden zijn.
maar wacht! Dit is erger. Sommige resolvers gedragen zich vrij slecht in zo ‘ n low-TTL-CNAME+low-TTL-records situatie:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Dit is Level3 ‘ s resolver, die, denk ik, BIND draait. Als je die query blijft verzenden, zal de geretourneerde TTL altijd 1 zijn. In wezen, raw.githubusercontent.com zal nooit gecached worden.
Hier is een ander voorbeeld van een low-TTL-CNAME+low-TTL-records situatie, met een zeer populaire naam:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
niet minder dan drie CNAME records. Au. Een van hen heeft een fatsoenlijke TTL, maar het is totaal nutteloos. Andere CNAMEs hebben een originele ttl van 60 seconden; de akamai.net namen hebben een maximum TTL van 20 seconden en niets daarvan is in fase.
wat dacht je van een die uw Apple-apparaten constant pollen?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
dezelfde configuratie als Firefox en de TTL zit meestal vast aan 1 bij het gebruik van Level3 ‘ s resolver.
hoe zit het met Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com heeft een TTL van 60 seconden. Facebook namen hebben een 60-seconden TTL. En, nogmaals, vanuit het perspectief van de klant, moeten deze waarden worden gehalveerd.
hoe zit het met het instellen van een minimum TTL?
met behulp van de naam, query type, TTL en tijdstempel in eerste instantie opgeslagen, schreef ik een script dat de 1,5+ miljoen query ’s simuleert gaan door een caching resolver om te schatten hoeveel query’ s werden verzonden als gevolg van een verlopen cache item. 47,4% van de queries werden gedaan nadat een bestaande, in de cache opgeslagen vermelding was verlopen. Dit is onredelijk hoog.
Wat zou de impact op caching zijn als er een minimum TTL was ingesteld?
De X-as is de minimale TTL die is ingesteld. Records waarvan de oorspronkelijke TTL hoger was dan deze waarde werden niet beïnvloed. De Y-as is het percentage query ‘ s gemaakt door een client die al een in de cache opgeslagen item had, maar een nieuwe query werd gemaakt en de in de cache opgeslagen item was verlopen.
het aantal queries daalt van 47% naar 36% alleen al door het instellen van een minimum TTL van 5 minuten. Het instellen van een minimum TTL van 15 minuten zorgt ervoor dat het aantal vereiste query ‘ s daalt tot 29%. Een minimum TTL van 1 uur maakt het dalen tot 17%. Dat is een significant verschil!
hoe zit het met het niet veranderen van iets server-side, maar het hebben van client DNS caches (routers, lokale resolvers en caches…) instellen van een minimum TTL plaats?
het aantal vereiste queries daalt van 47% naar 34% door een TTL van minimaal 5 minuten in te stellen, naar 25% met een minimum van 15 minuten en naar 13% met een minimum van 1 uur. 40 minuten misschien een goede plek. De impact van die minimale verandering is enorm.
Wat zijn de implicaties?
natuurlijk kan een service overschakelen naar een nieuwe cloudprovider, een nieuwe server, een nieuw netwerk, waarbij clients up-to-date DNS-records moeten gebruiken. En het hebben van redelijk lage TTLs helpt om de overgang wrijving-vrij te maken. Echter, niemand die naar een nieuwe infrastructuur gaat verwachten dat klanten de nieuwe DNS-records te gebruiken binnen 1 minuut, 5 minuten of 15 minuten.
Het instellen van een minimum TTL van 40 minuten in plaats van 5 minuten zal gebruikers niet beletten toegang te krijgen tot de service. Echter, het zal drastisch verminderen latency, en het verbeteren van de privacy (meer query ’s = meer tracking mogelijkheden) en betrouwbaarheid door het vermijden van onnodige query’ s.
natuurlijk zeggen RFC ’s dat TTL’ s strikt moeten worden nageleefd. Maar de realiteit is dat de DNS inefficiënt is geworden.
Als u gezaghebbende DNS-servers gebruikt, moet u uw TTLs opnieuw bezoeken. Moet dit echt belachelijk laag zijn?
Lees: hoe DNS TTL-waarden te kiezen
Sure, there are valid reasons to use low DNS TTLs. Maar niet voor 75% van het Internet om inhoud die is meestal onveranderlijk, maar zinloos om te cachen. En als je, om welke reden dan ook, echt lage DNS TTLs moet gebruiken, zorg er dan ook voor dat cache ook niet werkt op je website. Om dezelfde redenen.
Als u een lokale DNS-cache gebruikt, zoals dnscrypt-proxy, waarmee minimale TTLs kan worden ingesteld, gebruik dan deze functie. Dit is oké. Er zal niets ergs gebeuren. Stel dat Minimum TTL in op iets tussen 40 minuten (2400 seconden) en 1 uur; Dit is een perfect redelijk bereik.
aangepast van het oorspronkelijke bericht dat verscheen op 00f.net