RFC 9199: overwegingen voor operators van grote autoritatieve servers

Niet alle RFC's zijn hetzelfde

Allereerst wat RFC 9199 niet is: RFC 9199 is geen IETF-consensusdocument of protocolstandaard. Het is een informatief document met als enige oogmerk het documenteren van onze bevindingen. Hoewel de meeste mensen denken dat alle RFC's documenten zijn waarin protocolstandaarden worden beschreven, is dat slechts één van de mogelijkheden. RFC's kunnen tot meerdere categorieën behoren:

• Informational (zoals RFC 9199)

• Standard (zoals RFC 4033, over DNSSEC)

• Best current practices (zoals RFC 9210, over DNS-transport via TCP en operationele vereisten)

• Experimental (zoals RFC 9057, over een nieuw veld in e-mailheaders die de auteur van een e-mail identificeert)

• Historic

Elke categorie heeft een eigen doel. De conceptdocumenten (beter bekend als Internet drafts) kunnen afkomstig zijn van verschillende bronnen, die in de IETF worden aangeduid als streams:

• IETF: waarbij de draft meestal afkomstig van een werkgroep (zoals DNSOP, die protocollen standaardiseert);

• Independent: iedereen kan een Internet draft buiten de IETF-stream indienen;

• IAB: documenten gepubliceerd door de Internet Architecture Board;

• IRTF: documenten gepubliceerd door de Internet Research Task Force.

Van conceptdocument tot RFC

Het pad dat wij aflegden voor RFC 9199 begonnen we met het indienen van onze Internet draft in bij de werkgroep IETF DNSOP (IETF-stream). Dit was in maart 2019. Hoewel de feedback neutraal tot positief was, concludeerde de werkgroep (WG) terecht dat ze geen bijdrage konden leveren aan het verbeteren van het document, aangezien de conclusies voortvloeiden uit een al eerder peerreviewed en gepubliceerd onderzoekswerk. Een IETF WG is een geschikte stream voor het ontwerpen van een nieuw protocol, zoals we dat zelf bijvoorbeeld eerder deden bij RFC 6781 (DNSSEC Operational Practices). Maar we constateerden dat het niet de juiste stream is voor het presenteren van eerder bereikte conclusies.

Daarom besloten we om de stream van onze draft te veranderen van IETF in Independent. Dat bracht een ander evaluatietraject met zich mee, waarin de Independent Submissions Editor reviewers voor het document kiest, net zoals een redacteur van een wetenschappelijk tijdschrift dat doet voor een artikel. Een aanzienlijk verschil dus met de IETF-stream, waarin iedereen binnen de IETF commentaar op een draft kan geven.

Na individuele beoordelingen en meerdere iteraties werd ons document uiteindelijk gepubliceerd als Independent Submission met informatieve status.

Dus, wat is RFC 9199?

RFC 9199 is een samenvatting van 6 op metingen gebaseerde onderzoeken, bedoeld om de conclusies van die onderzoeken toegankelijker te maken voor operators van autoritatieve DNS-servers, zoals operators van ccTLDs. De RFC bestaat uit een kort overzicht van onze punten van overweging (aanbevelingen wat te doen) en verwijst de lezer naar de relevante papers voor de gegevens waarop deze zijn gebaseerd. De toegevoegde waarde van RFC 9199 is dat het onze onderzoeksconclusies samenvat en DNS-operators de kans geeft om onze bevindingen in praktijk te brengen zonder allerlei taaie academische papers door te hoeven spitten.

Overweging #1: zet anycast in voor elke autoritatieve server

In 2015 gebruikten veel autoritatieve DNS-operators, zoals de operators van de rootzone en van .nl (SIDN), een combinatie van unicast en anycast voor hun autoritatieve servers. De adoptie van anycast was nog in ontwikkeling.

We toonden aan dat als je een grote, wereldwijde provider bent, het beste is om op al je autoritatieve servers voor je zones gebruik te maken van anycast. Dit heeft de volgende 2 redenen:

• Anycastservers zijn beter bestand tegen DDoS-aanvallen dan unicastservers.

• Anycastservers reageren veel sneller met een DNS-antwoord dan unicastservers, omdat clients kunnen worden bediend door nabijgelegen servers, in plaats van door één server op een vaste locatie. En resolvers sturen queries naar alle autoritatieve servers – dus daar hebben unicast servers ook effect op.

In 2022 hebben alle rootserver-operators inmiddels IP-anycast geïmplementeerd. Dit geldt ook voor SIDN en de .nl-zone. Tussen 2017 en 2021 nam de adoptie van anycast ook toe onder ccTLD's en andere zones. We kunnen niet voor alle rootoperators spreken, maar dat SIDN voor .nl overstapte op alleen anycast was in elk geval deels naar aanleiding van ons onderzoekswerk.

Overweging #2: routering is belangrijker dan het aantal anycastlocaties

Bij het vergelijken van anycast DNS-providers is een veelgebruikte maatstaf het aantal anycastlocaties waarover een provider wereldwijd beschikt. Typische anycastnetwerken variëren van minder dan 10 locaties tot meer dan 150 (L-Root, bijvoorbeeld).

Intuïtief lijkt het misschien logisch dat meer locaties beter is en altijd tot kortere responstijden zullen leiden. Dat is echter niet per se waar. Het goed plannen van routes kan van groter belang zijn dan het totale aantal locaties.

We hebben laten zien dat een anycastnetwerk met 8 locaties clients een responsetijd kan leveren die vergelijkbaar is met die van de K-Root en L-Root, die op het moment van ons onderzoek over respectievelijk 33 en 144 locaties beschikten. Routeringsoptimalisatie kan dus belangrijker zijn dan het aantal wereldwijde locaties, afhankelijk van de clientpopulatie en queryspreiding. Daarnaast hebben we laten zien dat gebrekkige routering kan leiden tot anycastpolarisatie, waardoor grote clients een anycastservice zien als unicast (ze bereiken maar één locatie).

Daarom adviseren we DNS-operators om de responsetijd van hun clients te monitoren, wat ook kan worden gedaan met passieve TCP-query's.

Overweging #3: Breng anycast catchments in kaart om het ontwerp te verbeteren

Stel dat je een operationeel anycastnetwerk hebt en dit wilt uitbreiden door nieuwe locaties toe te voegen. Afhankelijk van je peering/transit-providers en clientpopulatie kunnen er door één enkele locatie toe te voegen enorme verschuivingen in het verkeer optreden en zien voorheen drukke locaties ineens misschien nog maar heel weinig verkeer.

Het is heel lastig om dit soort verschuivingen in het verkeer te voorspellen. Om onaangename verrassingen te voorkomen, kunnen operators meten welk effect een voorgestelde wijziging op een aangrenzend netwerk zal hebben. Hiervoor moet de operator een testprefix aankondigen op elke locatie in hun productienetwerk. Aan de hand van dit prefix kan vervolgens met behulp van een door ons ontwikkelde tool met de naam Verfploeter worden vastgesteld op welke locaties de IPv4-clientpopulatie zal uitkomen. Verfploeter verstuurt ICMP-echo-requests (pingpakketten) naar een IPv4-hitlist en de antwoorden gaan naar afzonderlijke anycastlocaties. De spreiding van de antwoorden die op een bepaalde locatie worden ontvangen, is het 'catchment' van die locatie.

De impact van een routewijziging kan worden gemeten door herhaaldelijk Verfploeter te draaien. Een beperking van Verfploeter is dat het vooralsnog geen IPv6 ondersteunt, omdat de gebruikte IPv4-hitlijsten worden gegenereerd door middel van frequente grootschalige ICMP-echoscans, wat niet met IPv6 kan.

Overweging #4: Hanteer bij overbelasting 2 strategieën

DDoS-aanvallen vormen nog steeds een aanzienlijke bedreiging voor DNS-operators. Hoe kunnen DNS-engineers hun ‘geanycastte’ autoritatieve DNS-server wapenen tegen een DDoS-aanval?

We hebben empirisch vastgesteld dat er 2 hoofdstrategieën zijn die tegen een DDoS-aanval kunnen worden ingezet.

Operators kunnen hun routes intrekken, hun AS-route naar alle of een aantal van hun buren langer maken (pre-prepending), het verkeer verleggen door andere kunstgrepen uit te voeren (zoals met de hulp van BGP-community's de verspreiding van de routeaankondiging indammen) of hun upstream-netwerkproviders vertellen dat ze filtering (mogelijk met FlowSpec) of het DDoS Open Threat Signaling (DOTS) protocol moeten toepassen (RFC 8811, RFC 9132, RFC 8783). Dit soort technieken verleggen zowel legitiem als aanvalsverkeer naar andere anycastlocaties (met meer capaciteit) of blokkeren het verkeer volledig.

Als alternatief kunnen operators locaties laten fungeren als degraded absorbers door ze te blijven gebruiken, ook al weten ze dat inkomende legitieme verzoeken niet kunnen beantwoorden omdat wachtrijen overlopen. Zo zorgen ze er echter ook voor dat het aanvalsverkeer naar het catchment eveneens wordt geabsorbeerd, waardoor de overige anycastlocaties mogelijke minder aanvalsverkeer ontvangen.

Overweging #5: Overweeg waar mogelijk langere TTL-waarden

Caching is de hoeksteen van goede DNS-prestaties en betrouwbaarheid. Als een nieuwe DNS-query binnen 50 ms wordt beantwoord, is dat misschien snel, maar een responstijd van minder dan 1 ms voor een item in de cache is nog veel sneller. We hebben aangetoond dat caching gebruikers bovendien beschermt tegen korte onderbrekingen en zelfs tegen significante DDoS-aanvallen.

Op DNS-resolvers hebben de operators van autoritatieve DNS-servers rechtstreeks controle over de caching (vergelijkbaar met het kortetermijngeheugen). Dit komt doordat elk DNS-record een time-to-live (TTL)-veld heeft, dat aangeeft hoelang een record in de cache van de resolver moet blijven.

We adviseren operators om TTL's van ten minste 4 uur (mogelijk meer) aan te houden voor hun records, omdat dit een snellere respons oplevert. Hierbij moet een uitzondering worden gemaakt voor load balancers en sommige op op DNS-gebaseerde DDoS-oplossingen die korte TTL's vereisen (hoewel voor veel operators 15 minuten al voldoende flexibiliteit kan bieden).

Overweging #6: Houd rekening met het verschil in parent en child TTL-waarden

In het DNS is sprake van een zekere mate van dubbele informatieverstrekking, zowel op parent als child autoritatieve servers. De NS-records van het domein example.com kunnen bijvoorbeeld worden opgehaald van de bovenliggende autoritatieve servers van .com:

dig ns example.com @e.gtld-servers.net ;; AUTHORITY SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net.

Maar ze kunnen ook worden opgehaald van de onderliggende autoritatieve servers:

dig NS example.com @a.iana-servers.net. ; ANSWER SECTION: example.com. 86400 IN NS a.iana-servers.net. example.com. 86400 IN NS b.iana-servers.net.

Kijk naar de TTL-velden: de bovenliggende server rapporteert een TTL van 172.800 seconden, terwijl de onderliggende server een TTL van 86.400 seconden rapporteert. Welke moet de resolver vertrouwen?

We constateerden dat 90 procent van de resolvers vertrouwt op het autoritatieve antwoord van de onderliggende server. Belangrijk is dat uit ons onderzoek is gebleken dat autoritatieve operators niet alleen kunnen vertrouwen op hun gepubliceerde TTL-waarden – de waarden van de bovenliggende server worden in het wild eveneens gebruikt voor het timen van cache-items. Operators die van plan zijn om hun infrastructuur te wijzigen, moeten er rekening mee houden dat een oudere infrastructuur gedurende ten minste de langste van de 2 TTL's actief en operationeel moet blijven.

Onderzoekers en RFC's

Over het algemeen is onze ervaring met het RFC-proces heel positief. Hoewel het lang duurde om de RFC-status te bereiken (3 jaar en 4 maanden van eerste conceptdocument tot RFC-publicatie), hebben we een doelgroep (operators) kunnen bereiken die nooit van onze bevindingen gehoord zou hebben als deze beperkt waren gebleven tot de academische wereld.

Onze bevindingen delen met een breder publiek is in ieders voordeel: de beheerders profiteren van informatie die ze in de praktijk kunnen gebruiken en wij hebben in de verschillende fasen van het proces kunnen profiteren van hun feedback en commentaar. We zijn hen dankbaar voor hun geduld en hulp tijdens het proces.

Gezamenlijke inspanning

RFC 9199 is een samenvatting van de voornaamste conclusies van 6 onderzoekspapers die in een tijdsbestek van 6 jaar werden geschreven. De auteurs van de desbetreffende papers en de hieronder vermelde personen hebben substantieel bijgedragen aan de inhoud en moeten dan ook worden gezien als medeauteurs. Dit document zou niet mogelijk zijn geweest zonder hun werk:

• Ricardo de O. Schmidt

• Wouter B. de Vries

• Moritz Müller

• Lan Wei

• Cristian Hesselman

• Jan Harm Kuipers

• Pieter-Tjerk de Boer

• Aiko Pras

Met dank aan

Dit werk werd gedeeltelijk gefinancierd via het PAADDoS-project (www.paaddos.nl). PAADDoS wordt gesteund door de US DHS via contractnummer HSHQDC-17-R-B0004-TTA.02-0006-I in de VS, door de Nederlandse Organisatie voor Wetenschappelijk Onderzoek NWO via contractnummer 4019020199 in Nederland.