TTL-waarden voor DNS-records kiezen: hoe doe je dat?

SIDN Labs heeft samen met USC/ISI een meetonderzoek uitgevoerd om inzicht te krijgen in hoe de keuze voor bepaalde TTL-waarden het functioneren van operationele netwerken beïnvloedt. Doel hiervan is operators helpen weloverwogen keuzes te maken ten aanzien van de TTL-waarden voor hun omgeving. Op basis van onze bevindingen namen we contact op met 8 ccTLD-operators die korte TTL-waarden hanteerden. Daarop verhoogde het Uruguayaanse topleveldomein .uy de TTL-waarde voor NS-records, wat leidde tot een aanzienlijk verbeterde latency voor gebruikers. In deze blogpost geven we een kort overzicht van de bevindingen en aanbevelingen in ons onderzoekspaper. Dit presenteren we tijdens de komende ACM Internet Measurement Conference (IMC) 2019 in Amsterdam.

Hoofdpunten:

• Caching wordt indirect bepaald door de TTL's in het DNS, die daarmee dus ook van invloed zijn op de gebruikservaring.

• We hebben de verschillende interacties van TTL's bij het omzetten van domeinnamen geëvalueerd en laten zien hoe TTL's ‘in het wild’ worden gebruikt.

• 8 ccTLD’s kregen te horen dat de TTL-waarden van hun NS-records te laag werden geacht; 3 daarvan hebben hun waarden vervolgens verhoogd.

• Een van hen, het Uruguayaanse .uy, bereikte een aanzienlijke prestatieverbetering door de TTL voor NS-records te veranderen van 5 minuten in 1 dag. Ripe Atlas probes namen vervolgens een afname van de mediane latency waar van 28 naar 8 milliseconden, terwijl in het 75ste percentiel de latency terugliep van 183 naar 21 milliseconden. De echte gebruikers van .uy kunnen dezelfde verbeterde prestatie verwachten en dat geldt ook voor de andere 2 ccTLD’s.

• We laten zien dat zelfs het gebruik van anycast met een korte TTL aan autoritatieve serverzijde de resultaten van langere TTL's niet kan evenaren.

Nieuw domein, welke TTL?

Stel dat je op het punt staat om een nieuwe domeinnaam te registreren voor jezelf of voor je werkgever. Dan moet je een time-to-live (TTL) waarde voor de bijbehorende records kiezen. Figuur 1 hieronder toont het dashboard van een bestaande registrar die we gebruiken voor het beheren van de records van het domein cachetest.net. Zoals je ziet, zijn de TTL-waarden ingesteld op 1 Uur en 1 Dag.

In het DNS kunnen TTL-waarden uiteenlopen van 0 seconden tot 248555 dagen (2^31 -1 seconde). Met zoveel waarden om uit te kiezen valt het niet mee om te weten welke je moet nemen. Vanwege alle interacties in de gedistribueerde DNS-service is het moeilijk te overzien hoe bepaalde TTL-waarden operationele netwerken beïnvloeden.

Wat doen die TTL's eigenlijk?

TTL's bepalen indirect de manier waarop door resolvers wordt gecachet. En caching is de hoeksteen van DNS-prestatie: een antwoord binnen 15 ms is al snel, maar een gecachet antwoord binnen 1 ms is nog veel sneller.

Om een domeinnaam om te zetten, maakt een gebruiker doorgaans verbinding met een DNS-resolver, zoals te zien is in Figuur 2 hieronder. Vervolgens stuurt die resolver de query van de gebruiker door naar de autoritatieve DNS-server, die weer een antwoord op de query terugstuurt, samen met een bijbehorende TTL-waarde. In Figuur 2 is dat een uur (1h). Dat houdt in dat de resolver het verkregen antwoord maximaal 1 uur mag cachen. Als vervolgens andere gebruikers binnen die periode van een uur dezelfde query versturen (de blauwe en groene pijlen), kunnen die queries in plaats van door opnieuw de autoritatieve server te bevragen, worden beantwoord door rechtstreeks de cache van de DNS-resolver te raadplegen, wat gewoonlijk veel sneller is.

In die zin kan caching worden beschouwd als een vorm van kortstondige replicatie aan resolverzijde (we hebben in een eerder onderzoek laten zien hoe caching gebruikers beschermt wanneer autoritatieve servers het doelwit zijn van een DDoS-aanval).

Als er geen consensus bestaat, welke waarden worden dan in het wild gebruikt?

Er mag dan geen consensus zijn over wat de beste TTL-waarden zijn, bij het registreren van domeinnamen zul je toch iets moeten instellen.

Om in kaart te brengen welke waarden in het wild het meest worden gebruikt, hebben we 5 databronnen onder de loep genomen:

• Een landencode topleveldomein (ons eigen .nl) met 5,8 miljoen domeinnamen

• 3 toplijsten (Alexa, Majestic en Umbrella)

• De DNS-rootzone

Voor elk domein hebben we NS-, A-, AAAA-, MX- en DNSKEY-records opgevraagd bij de onderliggende autoritatieve servers.

Figuur 3 toont de resultaten voor NS- en A-records voor de domeinen in kwestie (de overige records zijn te vinden in ons onderzoekspaper). We zien het volgende:

• De TTL-waarden laten voor alle lijsten en recordtypen een grote variatie zien, van 1 minuut tot 48 uur.

• De topleveldomeinen in de rootzone (root in Figuur 1) zijn veel conservatiever dan de toplijsten (Alexa, Majestic, Umbrella): voor zowel NS als A zijn de meeste TTL's ten minste 24 uur (vergeet niet: dit zijn TTL's van onderliggende delegeringen).

• Voor alle lijsten geldt dat NS-records over het algemeen langere TTL's hebben dan A-records, maar ook hier bestaat weer geen consensus over de precieze duur.

• Umbrella bevat veel volledig gekwalificeerde domeinnamen, zoals domeinnamen die gebruikt worden door CDN’s, waaronder wp-0f21050000000000.id.cdn.upcbroadband.com. Dat is een van de redenen dat we bij Umbrella lagere TTL's voor A-records zien dan bij de andere lijsten, die bestaan uit tweedeleveldomeinen (zoals example.nl en example.co.uk): CDN's staan erom bekend dat ze korte TTL-waarden hanteren, deels omwille van load balancing.

Verbeterde latency door langere TTL voor .uy

Tijdens het doorzoeken van de rootzone (topleveldomeinen) vonden we 34 topleveldomeinen (TLD's) die voor NS-records TTL-waarden van minder dan 30 minuten hanteerden - veel korter dan de andere TLD's. We namen contact op met 8 van deze 34 landencode TLD's om hen hiervan op de hoogte te stellen. Van 5 van de 7 kregen we antwoord en 3 verhoogden de TTL's van hun NS-records na ons eerste contact:

• De NS-records van het Uruguayaanse .uy gingen van een TTL-waarde van 300 naar 86400 seconden (1 dag).

• Een ccTLD uit Afrika en ccTLD uit het Midden-Oosten verhoogden hun TTL-waarde voor NS-records eveneens van respectievelijk 480 en 30 naar 86400 seconden.

Toevallig hadden we al voor de TTL-wijziging DNS-metingen uitgevoerd op het ccTLD .uy, waarbij er 10.000 Ripe Atlas probes waren ingezet om NS- en A-records op te vragen. We herhaalden die meting na de wijziging om te kijken of de gebruikservaring was veranderd.

Figuur 4 laat zien dat de mediane latency was afgenomen van 28 naar 8 milliseconden en de latency in het 75ste percentiel van 183 naar 21 milliseconden - alleen maar door 1 parameter te wijzigen. Anders gezegd: een mediane gebruiker van .uy zag zijn responstijd met 20 milliseconden afnemen als gevolg van de nieuwe TTL en een gebruiker in het 75ste percentiel bemerkte een verbetering van meer dan 160 milliseconden.

Onze resultaten tonen ook de verbeterde latency op de vantage points van de Atlas-probes uitgesplitst naar geografische regio: in alle regio's nam de prestatie toe. Het is belangrijk om te benadrukken dat het hier gaat om aanzienlijke verbeteringen waarvoor slechts 1 parameter hoefde te worden aangepast en de infrastructuur van .uy volstrekt ongewijzigd bleef.

Dat is geen kleinigheid: DNS-operators zijn voortdurend in de weer om de latency te verbeteren. Zo wordt er vaak ook gebruikgemaakt van IP anycast om meer autoritatieve servers dicht bij resolvers te plaatsen en op die manier een betere prestatie te verkrijgen. Maar zoals we in onze paper (paragraaf 6.2) laten zien, is cachen met langere TTL's zelfs nog sneller dan anycast met kortere TTL's.

Waarom lange en waarom korte TTL's?

Er zijn allerlei redenen waarom netwerkbeheerders kiezen voor lange of juist korte TTL's:

• Lang cachen leidt tot snellere antwoorden: een langere TTL zorgt ervoor dat er langer kan worden gecachet en antwoorden ophalen uit de cache is sneller dan ophalen bij autoritatieve servers, zoals de ervaring met .uy illustreert. We hebben verschillende experimenten opgezet om dit te onderzoeken, die nader worden beschreven in onze paper. De resultaten laten zien dat langer cachen zelfs betere resultaten oplevert dan een groot anycast-netwerk.

• Langer cachen leidt tot minder DNS-verkeer: voor autoritatieve operators is het mogelijk interessant om hogere TTL's in te stellen, omdat caching ervoor zorgt dat ze minder queries krijgen. Dat is met name van belang als het een bemeterde DNS-dienst betreft.

• Langer cachen biedt betere bescherming tegen DDoS-aanvallen op autoritatieve DNS-server: Verschillende prominente websites hebben ernstige hinder ondervonden van DDoS-aanvallen op een DNS-serviceprovider. Recent onderzoek heeft aangetoond dat DNS-caching de effecten van DDoS op het DNS aanzienlijk kan beperken, mits de caches langer duren dan de aanval.

• Korter cachen maakt het gemakkelijker om operationele wijzigingen door te voeren: een eenvoudige manier om van een oude server over te gaan op een nieuwe is door de DNS-records te wijzigen. Omdat het niet mogelijk is om gecachete DNS-records te verwijderen, bepaalt de TTL de tijd die nodig is om volledig te migreren naar een nieuwe server. Lage TTL's betekenen dus dat de overgang sneller verloopt. Als deployments echter langer van tevoren worden ingepland dan de lengte van de TTL, is het mogelijk om de TTL's vlak voor een grote operationele wijziging te verlagen en na afloop weer te verhogen.

• Korter cachen kan helpen wanneer DDoS-aanvallen worden gepareerd via het DNS: sommige DDoS-wasstraten gebruiken het DNS om verkeer tijdens een aanval om te leiden. Omdat DDoS-aanvallen niet van tevoren worden aangekondigd, moet de TTL dus altijd vrij laag zijn, wil er snel op een potentiële aanval kunnen worden gereageerd door het verkeer om te leiden via het DNS.

• Korter cachen helpt bij load balancing via het DNS: veel grote diensten maken gebruik van load balancing via het DNS. Elk inkomend DNS-verzoek is een kans om de belasting aan te passen. Het kan dus wenselijk zijn om gebruik te maken van korte TTL's, zodat er snel kan worden gereageerd op veranderende verkeerssituaties. (Al hanteren veel recursieve resolvers minimum cachetijden van tientallen seconden, waardoor de wendbaarheid beperkt blijft.)

Aanbevelingen

Hoewel onze analyse niet één ideale TTL-waarde suggereert, is er wel duidelijkheid ontstaan over de afwegingen die kunnen worden gemaakt, waardoor we afhankelijk van de situatie de volgende aanbevelingen kunnen doen. TTL-duur: de keuze van een TTL-waarde hangt voor een deel af van externe factoren en daarom is geen enkele aanbeveling geschikt voor alle netwerken of netwerktypen.

• Voor eigenaren van algemene zones adviseren we langere TTL's van minimaal 1, maar het liefst 4, 8 of 24 uur. Ervan uitgaande dat regulier onderhoud van tevoren kan worden ingepland, brengen lange TTL's weinig kosten met zich mee.

• Voor operators van topleveldomeinen en andere registry's: DNS-operators die openbare domeinregistratie toestaan (zoals de meeste ccTLD’s, .com, .net, .org en veel tweedeleveldomeinen) geven hun clients toestemming om de TTL's in hun zonefiles te dupliceren voor hun NS-records (en glue records, als de nameservers voor een domein zich binnen het domein bevinden). In paragraaf 3.3 van onze paper laten we zien dat de meeste resolvers de TTL-waarden uit de onderliggende delegering hanteren en sommige die van de bovenliggende. Daarom adviseren we langere TTL's voor zowel bovenliggende als onderliggende NS-records (minimaal 1 uur, bij voorkeur meer).

• Gebruikers van load balancing of DDoS-preventie via het DNS zijn mogelijk beter af met korte TTL's van een minuut of 5, hoewel 15 minuten veel operators ook al voldoende wendbaarheid kan geven. Kortere TTL's verhogen in deze gevallen de wendbaarheid en zijn een uitzondering op onze eerste aanbeveling om langere TTL's in te stellen.

Giovane Moura is Data Scientist bij SIDN Labs (het researchteam van SIDN, de operator van .nl) en gastonderzoeker bij de TU Delft. Hij houdt zich bezig met meetonderzoek op het gebied van veiligheid en het internet.

Met bijdragen van: John Heidemann, Ricardo Schmidt, Wesley Hardaker