Een moderniseringsslag voor de DNS-delegatie

Hints

De huidige NS-records in de parentzone, met bijbehorende glue-records, zijn feitelijk niet meer dan hints naar de autoritatieve nameservers voor de betreffende childzone. Omdat de parentzone niet autoritatief is voor de childzone, zijn deze records op deze plek ook niet ondertekend. De NS-records in de autoritatieve childzone zijn daar vanzelfsprekend wel ondertekend, maar deze worden in het algemeen niet opnieuw opgevraagd door de resolver (al ligt er wel een voorstel om dat voortaan wel te doen). De DS-records (in de parentzone), die de DNSKEY-records voor de handtekeningen in de childzone authentiseren, zijn wel autoritatief en dus wel ondertekend.

Hoewel de NS-records in de parentzone geacht worden een kopie te zijn van de autoritatieve NS-records in de childzone, geeft dit aanleiding tot fouten en gaat dit in de praktijk ook regelmatig mis. Zolang de resolver nog contact kan krijgen met een autoritatieve nameserver voor de betreffende childzone, blijft alles wel werken. En als de childzone met DNSSEC ondertekend is, weet een validerende resolver ook zeker dat alle aangeleverde DNS-informatie authentiek is.

Met RFC 7477 is wel een mechanisme beschikbaar om het kopiëren van nieuwe records naar de parentzone te automatiseren. Daartoe publiceert de childzone alle informatie voor de nieuwe NS- en glue-records in een set CSYNC-records, die vervolgens door de parentzone overgenomen kunnen worden. Om te voorkomen dat een delegatie door een man-in-the-middle omgeleid kan worden, is de toepassing van DNSSEC hierbij verplicht. Daarmee is het CSYNC-mechanisme complementair aan het CDS/CDNSKEY-mechanisme gedefinieerd in RFC 7344, dat op vergelijkbare wijze gebruikt kan worden om de DNSSEC-koppeling in de parentzone aan te passen.

Voor dit alles is natuurlijk wel noodzakelijk dat de parentzone regelmatig de autoritatieve nameservers voor zijn childzones scant. Op dit moment doen we echter ook bij SIDN nog niets met deze 2 mechanismen.

Autoritatieve delegaties

Beide nieuwe delegatievoorstellen zijn een product van de IETF DNS Delegation-werkgroep (deleg). De belangrijkste problemen die deze werkgroep op wil lossen zijn:

• het specificeren van autoritatieve nameservers die een vorm van cryptografische versleuteling aanbieden;

• de ondersteuning van aliassen naar nameservers (wat het uitbesteden van het draaien van de DNS-servers door een registrar/houder naar een DNS-dienstverlener makkelijker maakt);

• en de synchronisatie tussen child- en parentzone.

Hieronder nemen we het DELEG-mechanisme als uitgangspunt; aan het eind bespreken we het alternatieve '_deleg'-mechanisme.

Het nieuwe DELEG-recordtype maakt om te beginnen de delegatie naar subdomeinen expliciet top-down en autoritatief. Daarmee wordt de oude, zachte delegatiemethode vervangen door een methode die aansluit bij de harde, autoritatieve DS-koppeling van de DNSSEC-hiërarchie. Bovendien biedt het DELEG-recordtype de mogelijkheid om versleutelde verbindingen te specificeren, waarmee ook de vertrouwelijkheid van het DNS-verkeer beschermd wordt.

Het ontwerp van het DELEG-recordtype is gebaseerd op het formaat van het bestaande Service Binding (SVCB)-recordtype (gedefinieerd in de RFC's 9460 en 9461). Een delegatie met behulp van een DELEG-record (naast de bestaande NS- en glue-records) ziet er bijvoorbeeld zo uit:

; nieuw DELEG-record (autoritatief) met hints:
example.nl. IN DELEG 1 ns1.example.nl.
( ipv4hint=198.51.100.3 ipv6hint=2001:db8::fffe:3 )
; bestaande NS- en glue-records (niet autoritatief):
example.nl. IN NS ns1.example.nl.
ns1.example.nl. IN A 198.51.100.3
ns1.example.nl. IN AAAA 2001:db8::fffe:3

Hiermee wordt de traditionele delegatie vervangen door een nieuw autoritatief DELEG-record dat niet alleen de informatie in de NS- en glue-records samenpakt, maar ook een aantal nieuwe mogelijkheden toevoegt. Zo kun je een poortnummer aan de nameserver toevoegen (e.g. 'port=53') en aangeven dat een versleuteld transportmechanisme moet worden gebruikt (e.g. 'alpn=dot').

Indirecties

Belangrijk voor serviceproviders is de mogelijkheid om indirecties te specificeren. In bovenstaand voorbeeld geeft de '1' aan dat het DELEG-record in ServiceMode gebruikt wordt: de data verwijst direct naar een set nameservers.

Maar het DELEG-record kan ook in AliasMode gebruikt worden, waarbij wordt verwezen naar een SVCB-record voor de nameservers en het transportmechanisme. Dat ziet er bijvoorbeeld zo uit:

example.nl. IN DELEG 0 dnsconfig2.example.net
dnsconfig2.example.net IN SVCB 1 .
( ipv4hint=198.51.100.3 ipv6hint=2001:db8::fffe:3 )

Maar een SVCB-record kan (in AliasMode) ook weer naar een volgend SVCB-record (of CNAME-record) verwijzen. Zo kun je meerdere indirecties over verschillende domeinen aanbrengen (maximaal 4 diep). Serviceproviders en DNS-operators kunnen deze mogelijkheid gebruiken om delegaties voor meerdere subdomeinen te delen en op een centrale locatie te hosten en te administreren.

DNSSEC-ondertekening

De toepassing van DNSSEC bij gebruik van DELEG is niet verplicht maar wel sterk aangeraden (waarmee een substitutie-aanval voorkomen wordt). Is het DELEG-record niet ondertekend, dan mag je deze alleen gebruiken als het record over een versleutelde verbinding (DoT/DoH/DoQ) is opgehaald.

In het DNSKEY-record van een parentzone die wél ondertekend is, wordt de (nieuwe) DELEG-vlag gezet als de zone ook een DELEG-record bevat. Dat is een signaal aan validerende resolvers dat de betreffende zone DELEG ondersteunt, en een bescherming tegen downgrade-aanvallen (door een man-in-the-middle die de DELEG-records met bijbehorende handtekening verwijdert).

Vervanging oude delegatiemethode

De bedoeling van deze innovatie is dat de NS- en glue-records in de parentzones uiteindelijk allemaal worden vervangen door de nieuwe DELEG- en SVCB-records. Maar dat kan pas als alle DNS-resolvers DELEG begrijpen. Een resolver die DELEG ondersteunt kan expliciet om de DELEG-records (en niet de NS- en glue-records) vragen door de nieuwe DE-vlag in zijn query te zetten. Doet een resolver dat niet, dan retourneert de server simpelweg alles wat hij aan DELEG-, NS- en glue-records voor de betreffende naam in huis heeft.

De belangrijkste meerwaarde van DELEG is dat deze indirecties toevoegt en CNAME-aliases toestaat (NS-records mogen alleen naar een echte hostnaam verwijzen). Daarmee kunnen serviceproviders en DNS-operators wijzigingen maken in bulk en zonder dat daarvoor aanpassingen in de parentzone hoeven worden gedaan.

Voor de daadwerkelijke invoering van het DELEG-mechanisme zullen zowel de nameservers als de resolvers van ondersteuning van het nieuwe recordtype moeten worden voorzien [1]. Daarnaast vraagt de toevoeging van het DELEG-record om een uitbreiding in de dashboards en provisioningprotocollen als EPP en RPP [1]. Wat de transitie te zijner tijd makkelijker maakt, is dat het oude en nieuwe mechanisme in de tussentijd wel naast elkaar gebruikt kunnen worden.

De verwachting is dat er nog vele jaren na de introductie van DELEG recursieve resolvers zullen zijn die het nieuwe delegatiemechanisme niet ondersteunen. Dat betekent dat autoritatieve nameservers die hun zones van DELEG-records hebben voorzien, daarnaast ook de oude NS- en glue-records zullen blijven aanbieden.

Alternatief voorstel

Naast het hierboven besproken voorstel voor een nieuw DELEG-recordtype ligt er van dezelfde deleg-werkgroep nog een alternatief voorstel: incrementele delegatie. Dit mechanisme biedt dezelfde mogelijkheden als het DELEG-mechanisme, maar kiest omwille van de invoering voor een implementatie die zo min mogelijk aanpassingen van het bestaande DNS-systeem vraagt.

In plaats van het DELEG-record maakt dit alternatief gebruik van het bestaande SVCB-record voor DNS (gedefinieerd in RFC 9461), dat dan als dienst onder het nieuwe '_deleg'-label geplaatst wordt, e.g. 'example._deleg.nl.'. Voor het gebruik hiervan is alleen specifieke ondersteuning aan resolverzijde nodig. Bovendien is de toepassing van DNSSEC niet verplicht.

Het '_deleg'-label met het SVCB-record kan nu al zonder aanpassingen in de zonefile van de parent opgenomen worden. De ondersteuning van een nieuw recordtype en een nieuwe vlag is allemaal niet nodig (sectie 7.3). Wel geven de auteurs van het alternatieve voorstel verschillende optimalisatiemogelijkheden die met de invoering nog aan server-zijde gedaan kunnen worden.

De ontwikkelaars van NLnet Labs hebben incrementele delegatie afgelopen zomer als proof-of-concept in de Unbound-resolver geïmplementeerd.

De belangrijkste bezwaren van het DELEG-kamp tegen het 'incrementele delegatie'-mechanisme (appendix C) zijn dat het niet lekker aansluit bij het ontwerp van DNS en dat het meer netwerkverkeer vereist.

Omschakeling

Kortom: hoewel de functionaliteit voor een moderne DNS-delegatie er inmiddels ligt, loopt de discussie over de precieze implementatie nog. En is men het eenmaal eens, dan zal het naar verwachting nog vele jaren duren voordat iedereen daadwerkelijk omgeschakeld is.