Lage DNS-latentie is een belangrijke factor voor snel browsen. Om deze te minimaliseren, is het belangrijk om DNS-servers zorgvuldig te selecteren en Maar het eerste wat je moet doen is je ontdoen van nutteloze zoekopdrachten.
Daarom is DNS oorspronkelijk ontworpen als een zeer cachebaar protocol. Zonebeheerders stellen een time to live (TTL) in voor individuele records, en resolvers gebruiken deze informatie bij het opslaan van records in het geheugen om onnodig verkeer te voorkomen.
Is caching effectief? Een paar jaar geleden toonde mijn kleine onderzoek aan dat het niet perfect is. Laten we eens kijken naar de huidige stand van zaken.
Om informatie te verzamelen heb ik gepatcht om de TTL-waarde voor de respons op te slaan. Deze wordt gedefinieerd als de minimale TTL van de records voor elk binnenkomend verzoek. Dit geeft een goed overzicht van de TTL-verdeling van het werkelijke verkeer en houdt ook rekening met de populariteit van individuele verzoeken. De gepatchte versie van de server werkte enkele uren.
De resulterende dataset bestaat uit 1 records (naam, qtype, TTL, tijdstempel). Hier is de totale TTL-verdeling (x-as is TTL in seconden):
Afgezien van een kleine stijging naar 86 (voornamelijk voor SOA-records), is het vrij duidelijk dat de TTL's laag zijn. Laten we eens wat beter kijken:
Oké, TTL's van meer dan een uur zijn statistisch gezien niet significant. Laten we ons dan concentreren op het bereik van 1-0:
De meeste TTL's liggen tussen 0 en 15 minuten:
De overgrote meerderheid bedraagt 0 tot 5 minuten:
Dat is niet zo goed.
De cumulatieve verdeling maakt het probleem nog duidelijker:
De helft van de DNS-reacties heeft een TTL van 1 minuut of korter, en driekwart heeft een TTL van 5 minuten of korter.
Maar wacht, het is eigenlijk nog erger. Dit is de TTL van de gezaghebbende servers. Clientresolvers (bijv. routers, lokale caches) ontvangen echter de TTL van upstreamresolvers en deze neemt elke seconde af.
Hierdoor kan de client elk record gemiddeld maar de helft van de oorspronkelijke TTL gebruiken voordat hij een nieuw verzoek verstuurt.
Misschien gelden deze zeer lage TTL's alleen voor ongebruikelijke verzoeken en niet voor populaire websites en API's? Laten we eens kijken:
De X-as is de TTL, de Y-as is de populariteit van de zoekopdracht.
Helaas worden de populairste zoekopdrachten ook het slechtst gecached.
Laten we inzoomen:
Oordeel: Het is echt slecht. Het was al slecht, en het is alleen maar erger geworden. DNS-caching is vrijwel nutteloos geworden. Omdat steeds minder mensen de DNS-resolver van hun internetprovider gebruiken (en dat is niet voor niets), wordt de toename in latentie steeds merkbaarder.
DNS-caching is alleen nuttig geworden voor content die niemand bezoekt.
Houd er ook rekening mee dat de software mogelijk lage TTL’s interpreteren.
Hoe komt dat?
Waarom worden DNS-records ingesteld op zo'n kleine TTL?
- Voor oudere load balancers blijven de standaardinstellingen behouden.
- Er zijn mythes dat DNS-load balancing afhankelijk is van TTL (dit is niet waar - sinds Netscape Navigator kiezen clients een willekeurig IP-adres uit de RR-set en proberen ze transparant een ander als ze geen verbinding kunnen maken).
- Beheerders willen wijzigingen direct doorvoeren, zodat er gemakkelijker gepland kan worden.
- De beheerder van een DNS-server of load balancer ziet het als zijn taak om de door gebruikers aangevraagde configuratie zo efficiënt mogelijk te implementeren, niet om de werking van sites en services te versnellen.
- Een lage TTL zorgt voor gemoedsrust.
- Mensen stellen aanvankelijk lage TTL's in voor het testen en vergeten deze vervolgens te wijzigen.
Ik heb "failover" niet opgenomen omdat het steeds minder relevant wordt. Als je gebruikers naar een ander netwerk moet omleiden om een foutpagina weer te geven terwijl alles anders kapot is, is een vertraging van meer dan 1 minuut waarschijnlijk acceptabel.
Bovendien betekent een TTL van één minuut dat als gezaghebbende DNS-servers langer dan een minuut geblokkeerd zijn, niemand anders toegang heeft tot de afhankelijke services. Redundantie helpt ook niet als de oorzaak een configuratiefout of een hack is. Aan de andere kant zullen veel clients bij redelijke TTL's de vorige configuratie blijven gebruiken zonder het te merken.
Lage TTL's zijn grotendeels te wijten aan CDN-services en load balancers, vooral wanneer ze CNAME's combineren met lage TTL's en records met eveneens lage (maar onafhankelijke) 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
Elke keer dat de CNAME of een van de A-records verloopt, moet er een nieuwe aanvraag worden verzonden. Beide hebben een TTL van 30 seconden, maar ze zijn niet hetzelfde. De werkelijke gemiddelde TTL is 15 seconden.
Maar wacht! Het wordt erger. Sommige resolvers gedragen zich in deze situatie erg slecht met twee gekoppelde lage TTL's:
$ 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
De Level3-resolver draait waarschijnlijk op BIND. Als u deze query blijft versturen, retourneert deze altijd een TTL van 1. In wezen: raw.githubusercontent.com nooit gecached.
Hier is nog een voorbeeld van deze situatie met een zeer populair 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
Minstens drie CNAME-records. Au. Eén heeft een behoorlijke TTL, maar is volkomen nutteloos. De andere CNAME's hebben een initiële TTL van 60 seconden, maar voor domeinen akamai.net De maximale TTL bedraagt 20 seconden en geen van beide is in fase.
Hoe zit het met domeinen die voortdurend Apple-apparaten ondervragen?
$ 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
Hetzelfde probleem is het geval bij Firefox. TTL blijft meestal hangen op 1 seconde wanneer de Level3-resolver wordt gebruikt.
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
Bij de opname safebrowsing.googleapis.com TTL-waarde van 60 seconden, net als Facebook-domeinen. En wederom, vanuit het perspectief van de klant, zijn deze waarden gehalveerd.
Wat dacht je van het instellen van een minimale TTL?
Met behulp van de naam, het aanvraagtype, de TTL en het oorspronkelijk opgeslagen tijdstempel heb ik een script geschreven om 1,5 miljoen verzoeken te simuleren die via een cache-resolver worden verzonden. Zo kon ik schatten hoeveel extra verzoeken er werden verzonden vanwege een verlopen cache-invoer.
47,4% van de verzoeken werd gedaan nadat het bestaande record was verlopen. Dit is onredelijk hoog.
Wat zijn de gevolgen voor de caching als er een minimale TTL wordt ingesteld?
De X-as geeft de minimale TTL-waarden weer. Records met ruwe TTL's boven deze waarde worden niet beïnvloed.
De Y-as is het percentage verzoeken van een client die al een gecachte vermelding heeft, maar deze is verlopen en een nieuw verzoek indient.
Het aandeel "extra" verzoeken wordt teruggebracht van 47% naar 36% door de minimale TTL simpelweg in te stellen op 5 minuten. Door de minimale TTL in te stellen op 15 minuten, daalt het aantal van deze verzoeken naar 29%. Een minimale TTL van 1 uur verlaagt dit naar 17%. Een significant verschil!
Wat dacht je ervan om niets aan de serverkant te veranderen, maar in plaats daarvan minimale TTL's in te stellen in client-DNS-caches (routers, lokale resolvers)?
Het aantal benodigde verzoeken daalt van 47% naar 34% bij een minimale TTL van 5 minuten, naar 25% bij een minimale TTL van 15 minuten en naar 13% bij een minimale TTL van 1 uur. 40 minuten is wellicht optimaal.
De impact van deze minimale verandering is enorm.
Wat zijn de gevolgen?
Natuurlijk kunt u een service migreren naar een nieuwe cloudprovider, een nieuwe server, een nieuw netwerk en klanten verplichten de nieuwste DNS-records te gebruiken. Een voldoende lage TTL zorgt voor een soepele en naadloze overgang. Maar wanneer u migreert naar een nieuwe infrastructuur, verwacht niemand dat klanten binnen 1 minuut, 5 minuten of 15 minuten naar de nieuwe DNS-records migreren. Het instellen van de minimale TTL op 40 minuten in plaats van 5 minuten voorkomt niet dat gebruikers toegang hebben tot de service.
Dit zal echter de latentie aanzienlijk verminderen en de privacy en betrouwbaarheid verbeteren, omdat onnodige verzoeken worden vermeden.
Natuurlijk, de RFC's stellen dat TTL's strikt gehandhaafd moeten worden. Maar de realiteit is dat het DNS-systeem te inefficiënt is geworden.
Als u met gezaghebbende DNS-servers werkt, controleer dan uw TTL's. Heeft u echt zulke belachelijk lage waarden nodig?
Natuurlijk zijn er goede redenen om lage TTL's in te stellen voor DNS-records. Maar niet voor de 75% van het DNS-verkeer dat nauwelijks verandert.
En als je om de een of andere reden echt lage TTL's voor DNS nodig hebt, zorg er dan ook voor dat je site geen caching heeft ingeschakeld. Om dezelfde redenen.
Als u een lokale DNS-cache hebt draaien, zoals , waarmee u de minimale TTL kunt instellen, gebruik deze functie. Dit is normaal. Er zal niets misgaan. Stel de minimale TTL in op ergens tussen de 40 minuten (2400 seconden) en 1 uur. Een redelijk bereik.
Bron: www.habr.com
