Een lage DNS-latentie is de sleutel tot snel surfen op het internet. Om dit te minimaliseren, is het belangrijk om zorgvuldig DNS-servers en . Maar de eerste stap is het verwijderen van nutteloze zoekopdrachten.
Dit is de reden waarom DNS oorspronkelijk is ontworpen als een zeer cachebaar protocol. Zonebeheerders stellen een time to live (TTL) in voor individuele vermeldingen, en solvers gebruiken deze informatie bij het opslaan van vermeldingen in het geheugen om onnodig verkeer te voorkomen.
Is caching effectief? Een paar jaar geleden bleek uit mijn kleine onderzoek dat het niet perfect was. Laten we eens kijken naar de huidige stand van zaken.
Om informatie te verzamelen heb ik gepatcht om de TTL-waarde voor het antwoord op te slaan. Het wordt gedefinieerd als de minimale TTL van de records voor elk binnenkomend verzoek. Dit geeft een goed overzicht van de TTL-verdeling van echt 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 algemene TTL-verdeling (X-as is TTL in seconden):
Afgezien van een kleine stijging op 86 (meestal voor SOA-records), is het vrij duidelijk dat de TTL's zich in het lage bereik bevinden. Laten we dat eens van dichterbij bekijken:
Oké, TTL's groter dan 1 uur zijn niet statistisch significant. Laten we ons vervolgens concentreren op het bereik 0−3600:
De meeste TTL's variëren van 0 tot 15 minuten:
De overgrote meerderheid is van 0 tot 5 minuten:
Het is niet erg goed.
Cumulatieve verdeling maakt het probleem nog duidelijker:
De helft van de DNS-reacties heeft een TTL van 1 minuut of minder, en driekwart heeft een TTL van 5 minuten of minder.
Maar wacht, het is eigenlijk nog erger. Dit is tenslotte TTL van gezaghebbende servers. Clientresolvers (bijvoorbeeld routers, lokale caches) ontvangen echter een TTL van upstream-resolvers, en deze neemt elke seconde af.
De klant kan dus elke invoer daadwerkelijk gebruiken voor gemiddeld de helft van de oorspronkelijke TTL voordat hij een nieuw verzoek verzendt.
Misschien zijn deze zeer lage TTL's alleen van toepassing op ongebruikelijke verzoeken en niet op populaire websites en API's? Laten we eens kijken:
De X-as is TTL, de Y-as is de populariteit van zoekopdrachten.
Helaas zijn de populairste zoekopdrachten ook de slechtste om te cachen.
Laten we inzoomen:
Oordeel: het is echt slecht. Vroeger was het al erg, maar het werd nog erger. DNS-caching is vrijwel nutteloos geworden. Naarmate minder mensen de DNS-resolver van hun ISP gebruiken (om goede redenen), wordt de toename van de latentie merkbaarder.
DNS-caching is alleen nuttig geworden voor inhoud die niemand bezoekt.
Houd er ook rekening mee dat de software mogelijk interpreteer lage TTL's.
Hoe komt dat?
Waarom zijn DNS-records ingesteld op zo’n lage TTL?
- Oudere load balancers bleven met standaardinstellingen achter.
- Er zijn mythen dat DNS-loadbalancing afhankelijk is van TTL (dit is niet waar - sinds de tijd van Netscape Navigator hebben klanten een willekeurig IP-adres gekozen uit een reeks RR's en op transparante wijze een ander IP-adres geprobeerd als ze geen verbinding konden maken)
- Beheerders willen wijzigingen onmiddellijk toepassen, zodat het gemakkelijker is om te plannen.
- De beheerder van een DNS-server of load balancer ziet het als zijn taak om de configuratie die gebruikers vragen efficiënt in te zetten, en niet om sites en services te versnellen.
- Lage TTL's geven u gemoedsrust.
- Mensen stellen aanvankelijk lage TTL's in om te testen en vergeten deze vervolgens te wijzigen.
Ik heb 'failover' niet in de lijst opgenomen omdat het steeds minder relevant wordt. Als u gebruikers naar een ander netwerk moet omleiden alleen maar om een foutpagina weer te geven terwijl al het andere 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 één minuut worden geblokkeerd, niemand anders toegang heeft tot afhankelijke services. En redundantie helpt niet als de oorzaak een configuratiefout of een hack is. Aan de andere kant zullen veel clients, met redelijke TTL's, de vorige configuratie blijven gebruiken en nooit iets merken.
CDN-services en load balancers zijn grotendeels verantwoordelijk voor lage TTL's, vooral wanneer ze CNAME's combineren met lage TTL's en records met even 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
Telkens wanneer de CNAME of een van de A-records vervalt, moet een nieuw verzoek worden verzonden. Beide hebben een TTL van 30 seconden, maar het is niet hetzelfde. De werkelijke gemiddelde TTL bedraagt 15 seconden.
Maar wacht! Het is nog erger. Sommige solvers gedragen zich in deze situatie zeer slecht, met twee bijbehorende lage 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 UIT EEN 151.101.16.133
De Level3-resolver draait waarschijnlijk op BIND. Als u doorgaat met het verzenden van dit verzoek, wordt er altijd een TTL van 1 geretourneerd. raw.githubusercontent.com wordt nooit in de cache opgeslagen.
Hier is nog een voorbeeld van een dergelijke 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
Minimaal drie CNAME-records. Ja. Men heeft een behoorlijke TTL, maar het is volkomen nutteloos. Andere CNAME's hebben een initiële TTL van 60 seconden, maar dan voor domeinen akamai.net de maximale TTL is 20 seconden en geen daarvan 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 als Firefox en TTL blijven meestal op 1 seconde hangen bij gebruik van de Level3-resolver.
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 Een boor van 162.125.67.3 $ client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 UIT EEN 162.125.64.3
Bij de opname safebrowsing.googleapis.com TTL-waarde is 60 seconden, net als Facebook-domeinen. En nogmaals, vanuit het oogpunt van de klant worden deze waarden gehalveerd.
Hoe zit het met het instellen van een minimale TTL?
Met behulp van de naam, het verzoektype, TTL en de oorspronkelijk opgeslagen tijdstempel heb ik een script geschreven om 1,5 miljoen verzoeken te simuleren die door een caching-resolver gaan, om het volume van onnodige verzoeken te schatten die worden verzonden vanwege een verlopen cache-item.
47,4% van de verzoeken werd gedaan nadat een bestaand record was verlopen. Dit is onredelijk hoog.
Wat zal de impact zijn op caching als de minimale TTL wordt ingesteld?
De X-as zijn de minimale TTL-waarden. Records met bron-TTL's boven deze waarde worden niet beïnvloed.
De Y-as is het percentage verzoeken van een client die al een vermelding in de cache heeft, maar deze is verlopen en een nieuw verzoek indient.
Het aandeel “extra” verzoeken wordt teruggebracht van 47% naar 36% door simpelweg de minimale TTL 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 reduceert deze tot 17%. Significant verschil!
Wat dacht je ervan om niets aan de serverkant te veranderen, maar in plaats daarvan de minimale TTL in client-DNS-caches (routers, lokale resolvers) in te stellen?
Het aantal benodigde verzoeken daalt van 47% naar 34% bij een minimale TTL van 5 minuten, naar 25% bij een minimum van 15 minuten en naar 13% bij een minimum van 1 uur. Misschien is 40 minuten optimaal.
De impact van deze kleine verandering is enorm.
Wat zijn de gevolgen?
Uiteraard kan de dienst worden verplaatst naar een nieuwe cloudprovider, een nieuwe server, een nieuw netwerk, waarbij clients de nieuwste DNS-records moeten gebruiken. En een vrij kleine TTL helpt om zo'n overgang soepel en onmerkbaar te maken. Maar met de transitie naar een nieuwe infrastructuur verwacht niemand dat klanten binnen 1 minuut, 5 minuten of 15 minuten naar nieuwe DNS-records zullen migreren. Als u de minimale TTL instelt op 40 minuten in plaats van 5 minuten, wordt gebruikers er niet van weerhouden toegang te krijgen tot de service.
Dit zal de latentie echter aanzienlijk verminderen en de privacy en betrouwbaarheid verbeteren door onnodige verzoeken te vermijden.
Natuurlijk zeggen de RFC's dat TTL strikt moet worden gevolgd. 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. Heb je echt zulke belachelijk lage waarden nodig?
Natuurlijk zijn er goede redenen om kleine TTL's in te stellen voor DNS-records. Maar niet voor de 75% van het DNS-verkeer die vrijwel onveranderd blijft.
En als u om de een of andere reden echt lage TTL's voor DNS moet gebruiken, zorg er dan tegelijkertijd voor dat caching op uw site niet is ingeschakeld. Om dezelfde redenen.
Als u een lokale DNS-cache gebruikt, zoals waarmee u minimale TTL's kunt instellen, gebruikt u deze functie. Dit is goed. Er zal niets ergs gebeuren. Stel de minimale TTL in op ongeveer 40 minuten (2400 seconden) en 1 uur. Een redelijk redelijk bereik.
Bron: www.habr.com