Een lage DNS-latentie is een cruciale factor voor een snelle internetverbinding. Om deze te minimaliseren, is het belangrijk om zorgvuldig DNS-servers te selecteren en . Maar eerst moeten nutteloze aanvragen worden geƫlimineerd.
Daarom werd DNS oorspronkelijk ontworpen als een sterk cachebaar protocol. Domeinbeheerders stellen de tijdsduur (TTL) in voor afzonderlijke records, en resolvers gebruiken deze informatie bij het opslaan van records in het geheugen om onnodig verkeer te vermijden.
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.
Voor het verzamelen van informatie heb ik gepatched om de waarde van de TTL voor het antwoord op te slaan. Het wordt gedefinieerd als de minimale TTL van zijn records voor elke binnenkomende aanvraag. Dit geeft een goed overzicht van de verdeling van de TTL van het echte verkeer, terwijl het ook de populariteit van afzonderlijke aanvragen in aanmerking neemt. De gepatchte versie van de server draaide enkele uren.
De resulterende dataset bestaat uit 1.583.579 records (naam, qtype, TTL, timestamp). Hier is de algemene verdeling van de TTL (de X-as is TTL in seconden):
Behalve een kleine piek op 86.400 (voornamelijk voor SOA-records), is het vrij duidelijk dat de TTL in een laag bereik blijft. Laten we eens dichterbij kijken:
Goed, TTL's van meer dan 1 uur zijn statistisch onbeduidend. Laten we ons dan concentreren op het bereik van 0-3600:
De meeste TTL's liggen tussen 0 en 15 minuten:
De overgrote meerderheid ligt tussen 0 en 5 minuten:
Dat is niet erg goed.
De cumulatieve verdeling maakt het probleem nog duidelijker:
In de helft van de DNS-antwoorden is de TTL 1 minuut of minder, en driekwart heeft 5 minuten of minder.
Maar wacht eens, het is eigenlijk nog erger. Dit is immers de TTL van autoritatieve servers. Klantresolvers (zoals routers, lokale caches) ontvangen echter TTL van bovenliggende resolvers, en deze neemt elke seconde af.
Hierdoor kan de klant feitelijk elke record gemiddeld de helft van de oorspronkelijke TTL gebruiken, waarna hij een nieuwe aanvraag indient.
Misschien betreft deze zeer lage TTL alleen ongebruikelijke aanvragen en niet populaire websites en API's? Laten we het bekijken:
De X-as is de TTL, de Y-as is de populariteit van de aanvragen.
Helaas worden de meest populaire aanvragen ook het slechtst gecached.
Laten we inzoomen:
Vonnis: het is echt slecht. Het was al slecht, maar het is nog slechter geworden. DNS-caching is praktisch nutteloos geworden. Omdat steeds minder mensen de DNS-resolver van hun provider gebruiken (om begrijpelijke redenen), wordt de vertraging steeds duidelijker.
DNS-caching is alleen nuttig voor content die niemand bezoekt.
Houd er ook rekening mee dat software omlaag TTL kan interpreteren.
Waarom is dat?
Waarom wordt er zo'n lage TTL voor DNS-records ingesteld?
- Verouderde load balancers zijn achtergebleven met de standaardinstellingen.
- Er gaan geruchten dat DNS-loadbalancing afhankelijk is van TTL (dat is niet zo - sinds de tijd van Netscape Navigator kiezen clients willekeurig een IP-adres uit de RR-set en proberen transparant een ander als ze geen verbinding kunnen maken).
- Beheerders willen wijzigingen onmiddellijk toepassen, omdat het dan eenvoudiger plannen is.
- De DNS-serverbeheerder of load balancer ziet zijn taak als het efficiƫnt implementeren van de configuratie die gebruikers aanvragen, en niet als het versnellen van websites en diensten.
- Lage TTL's bieden gemoedsrust.
- Mensen stellen aanvankelijk lage TTL's in voor testing en vergeten ze daarna aan te passen.
Ik heb "failover" niet opgenomen in de lijst, aangezien dit steeds minder relevant is. Als je gebruikers naar een ander netwerk moet omleiden alleen om een foutpagina weer te geven wanneer alles compleet is gebroken, is een vertraging van meer dan 1 minuut misschien acceptabel.
Bovendien betekent een minuut TTL dat als de autoritatieve DNS-servers meer dan 1 minuut geblokkeerd zijn, niemand meer toegang krijgt tot afhankelijk diensten. Redundantie helpt niet als het probleem een configuratiefout of hacking is. Aan de andere kant, met redelijke TTL's zullen veel clients de vorige configuratie blijven gebruiken en nooit iets opmerken.
Lage TTL's zijn grotendeels de schuld van CDN-diensten en load balancers, vooral wanneer ze CNAME met kleine TTL's combineren en records met dezelfde 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 een CNAME of een van de A-records verloopt, moet er een nieuw verzoek worden gestuurd. Beiden hebben een TTL van 30 seconden, maar deze komen niet overeen. De werkelijke gemiddelde TTL zal 15 seconden zijn.
Maar wacht! Het is nog erger. Sommige resolvers gedragen zich heel slecht in deze situatie met twee gerelateerde 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 werkt waarschijnlijk op BIND. Als je deze aanvraag blijft doen, zal de TTL altijd 1 zijn. In wezen, raw.githubusercontent.com wordt nooit gecached.
Hier is nog een voorbeeld van een dergelijke situatie met een zeer populaire 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. Ai. EĆ©n heeft een fatsoenlijke TTL, maar dat is helemaal nutteloos. Bij de andere CNAME is de oorspronkelijke TTL 60 seconden, maar voor de domeinen akamai.net is de maximale TTL 20 seconden, en geen van deze is in fase.
Wat te zeggen van domeinen die voortdurend apparaten van Apple vragen?
$ 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 bij Firefox, en de TTL blijft het grootste deel van de tijd op 1 seconde hangen bij gebruik van de Level3-resolver.
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
Met de record safebrowsing.googleapis.com heeft een TTL-waarde van 60 seconden, net als de domeinen van Facebook. En opnieuw, vanuit het perspectief van de klant, worden deze waarden gehalveerd.
Wat te zeggen van het instellen van een minimale TTL?
Met behulp van de naam, het type verzoek, de TTL en de oorspronkelijk opgeslagen tijdstempel heb ik een script geschreven om 1,5 miljoen verzoeken te simuleren die door een cacher-resolver gaan, om het aantal overbodige verzoeken te beoordelen dat wordt verzonden vanwege een verlopen cache-record.
47,4% van de verzoeken werd gedaan nadat de bestaande record was verlopen. Dit is onterecht hoog.
Wat zal de impact op caching zijn als een minimale TTL is ingesteld?
De X-as zijn de minimale TTL-waarden. Records met een oorspronkelijke TTL hoger dan deze waarde worden niet beĆÆnvloed.
De Y-as geeft het percentage aanvragen weer van een cliƫnt die al een gecacheerde record heeft, maar waarvan de vervaldatum is verstreken en die een nieuwe aanvraag doet.
Het aandeel 'overbodige' aanvragen daalt van 47% naar 36% door simpelweg de minimale TTL op 5 minuten in te stellen. Bij een minimale TTL van 15 minuten daalt het aantal aanvragen tot 29%. Een minimale TTL van 1 uur verlaagt dit tot 17%. Een aanzienlijk verschil!
Wat als we niets aan de serverkant veranderen, maar in plaats daarvan de minimale TTL instellen in de DNS-caches van de cliƫnten (routers, lokale resolvers)?
Het aantal vereiste aanvragen daalt van 47% naar 34% bij een minimale TTL van 5 minuten, tot 25% met een minimum van 15 minuten en tot 13% met een minimum van 1 uur. Misschien is de optimale waarde 40 minuten.
De impact van deze minimale wijziging is enorm.
Wat zijn de gevolgen?
Natuurlijk kan de service worden overgezet naar een nieuwe cloudprovider, een nieuwe server, een nieuw netwerk, waarbij klanten worden gevraagd om de laatste DNS-records te gebruiken. En een voldoende lage TTL helpt om een dergelijke overzetting soepel en onopgemerkt te maken. Maar bij de overstap naar een nieuwe infrastructuur verwacht niemand dat klanten binnen 1 minuut, 5 minuten of 15 minuten op de nieuwe DNS-records overstappen. Het instellen van een minimale levensduur van 40 minuten in plaats van 5 minuten zal gebruikers niet beletten om toegang te krijgen tot de service.
Maar dit zal de vertraging aanzienlijk verminderen en de privacy en betrouwbaarheid verhogen door onnodige aanvragen te vermijden.
Natuurlijk zeggen de RFC's dat je je strikt aan de TTL moet houden. Maar de realiteit is dat het DNS-systeem te inefficiƫnt is geworden.
Als je werkt met autoritatieve DNS-servers, controleer dan je TTL's. Heb je werkelijk zulke belachelijk lage waarden nodig?
Er zijn natuurlijk goede redenen om lage TTL-waarden voor DNS-records in te stellen. Maar niet voor 75% van het DNS-verkeer, dat praktisch niet verandert.
En als je om de een of andere reden echt lage TTL-waarden voor DNS moet gebruiken, zorg er dan ook voor dat caching op je website niet is ingeschakeld. Om dezelfde redenen.
Als je een lokale DNS-cache hebt, zoals , wat het mogelijk maakt om minimale TTL's in te stellen, gebruik deze functie. Dat is prima. Er zal niets verkeerd gaan. Stel een minimale TTL in van ongeveer 40 minuten (2400 seconden) tot 1 uur. Een heel redelijke range.
Bron: habr.com
