Geen van grootste internetdiensten beveiligd met DNSSEC
Doorbraak nodig om daadwerkelijk gebruik omhoog te brengen
De afgelopen 2 jaar hebben we uitgebreide kritieken op DNSSEC voorbij zien komen vanuit de DNS-wereld zelf. De belangrijkste punten zijn de complexiteit van het protocol, de slechte adoptie ervan door de markt en de veroudering van het ontwerp. De oorzaken van de beperkte adoptie moeten gezocht moeten worden in de onzichtbaarheid van DNSSEC op applicatieniveau en ontwerpkeuzen van destijds die inmiddels achterhaald zijn.
In dit artikel bespreken we de belangrijkste kritiekpunten en laten we zien dat DNSSEC probleemloos ingezet kan worden in grootschalige kritische toepassingen. Er worden nog steeds vereenvoudigingen doorgevoerd en innovaties ontwikkeld waaruit blijkt dat DNSSEC zich ondanks zijn leeftijd weldegelijk aanpast aan de eisen van de huidige tijd.
DNSSEC blijkt niet alleen belangrijk voor de beveiliging van het bestaande DNS-systeem, maar legt ook een fundament voor nieuwe en toekomstige beveiligingstechnologieën. Tegelijkertijd is er wel een doorbraak nodig om de grootste internetdienstenaanbieders naar DNSSEC over te laten schakelen. Nu gebruiken zij deze beveiligingstechnologie geen van allen op hun hoofddomein.
De afgelopen 2 jaar hebben we belangrijke kritieken op DNSSEC voorbij zien komen vanuit de DNS-wereld zelf. Het meest uitgesproken is Geoff Huston, Chief Scientist bij APNIC, die meerdere artikelen publiceerde waarin hij zich nogal negatief uitlaat over dit beveiligingsmechanisme. Hij noemt het op zijn slechtst een halfbakken, geforceerde toevoeging aan het DNS-systeem, en een slecht geadopteerde innovatie [wat iets anders is dan een slechte innovatie] die niet wil verdwijnen en niet opgevolgd wordt door iets beters en moderners. Met een adoptie die ook na meerdere decennia niet goed op gang gekomen is, zouden de problemen van destijds opnieuw geformuleerd moeten worden, net als de oplossing voor die problemen. Dat laatste geldt volgens hem overigens ook voor IPv6.
Hoewel Huston in zijn blog post zelf al aangeeft dat hij chargeert om zijn punt te maken, zijn wij het op veel onderdelen niet met hem eens. Hieronder gaan we in op de belangrijkste kritiekpunten: de complexiteit van het protocol, de slechte adoptie ervan door de markt en de veroudering van het ontwerp.
Een complex protocol?
Om met de complexiteit van het DNSSEC-protocol te beginnen: DNSSEC maakt het moderne DNS-systeem inderdaad een stuk ingewikkelder dan het voorheen was. Waar het traditionele DNS-systeem vooral een administratieve aangelegenheid was, voegt DNSSEC aan de bestaande infrastructuur een hele nieuwe laag toe, met daarin een beveiligingsmechanisme gebaseerd op public-keycryptografie.
Public-keycryptografie is tegenwoordig echter standaard onderdeel van een heleboel internettoepassingen – denk aan TLS, RPKI, SSH, S/MIME, OpenPGP en blockchains – waarmee de concepten van deze beveiligingstechnologie in de ICT-wereld breed bekend zijn.
Niet fundamenteel ingewikkelder
Specifieke aandachtspunten voor DNSSEC zijn delegaties, waar verschillende lagen van de gedistribueerde DNS-infrastructuur met elkaar verbonden moeten worden middels DS-records, en de ondertekening van DNS-antwoorden voor niet bestaande namen (een authenticated denial of existence), waarvoor NSEC(3) bedacht is. Maar zo heeft elke niet-triviale toepassing van public-keycryptografie zijn eigen aandachtspunten.
Alles bij elkaar is het DNSSEC-protocol niet fundamenteel ingewikkelder dan bijvoorbeeld een blockchainprotocol. Wij zouden bovengenoemde kritiek dan ook liever omdraaien: het oude DNS-protocol was veel te eenvoudig voor het hedendaagse internet.
DNSSEC in de .nl-zone
De .nl-zone laat ook zien dat DNSSEC probleemloos ingezet kan worden: op dit moment is 62 procent van de domeinnamen onder .nl ondertekend en is bijna 60 procent van het binnenkomende DNS-verkeer afkomstig van validerende resolvers.
Uitzondering
Hoewel het leeuwendeel van alle topleveldomeinen DNSSEC ondersteunt, is Nederland samen met een aantal andere landen helaas een van de uitzonderingen waar de adoptie van DNSSEC zo hoog is. Zo is onder .com, veruit het grootste topleveldomein, maar ongeveer 5 procent van de domeinnamen ondertekend.
Figuur 3: In 2024 was circa 5% van de .com-domeinnamen ondertekend met DNSSEC.
"1 procent daadwerkelijk gebruik"
Huston kwam in 2023 uit op een daadwerkelijk gebruik van DNSSEC (validerende resolvers die ondertekende domeinnamen bevroegen) dat wereldwijd slechts rond de 1 procent zat. Volgens APNIC heeft 35 procent van de wereldwijde internetgebruikers validatie aan staan. En bij Cloudflare is maar 3 procent van het binnenkomende verkeer bestemd voor een DNSSEC-ondertekend domein. Huston vermenigvuldigt deze 2 statistieken met elkaar om op die 1 procent uit te komen.
Figuur 4: Het aandeel validerende resolvers wereldwijd. [bron: APNIC]
Figuur 5: Het aandeel binnenkomende DNS-queries bij Cloudflare voor ondertekende domeinnamen. [bron: APNIC]
Overhead en afbreukrisico
De oorzaak van deze bedroevend lage uitkomst is dat geen van de meest bezochte second-leveldomeinen met DNSSEC beveiligd is. Een opsomming daarvan bevat google.com, youtube.com, facebook.com, instagram.com, x.com, whatsapp.com, wikipedia.org, yahoo.com, reddit.com, amazon.com chatgpt.com, tiktok.com, netflix.com, linkedin.com en microsoft.com.
Kennelijk wegen voor al deze organisaties de netwerkoverhead, en de impact en het afbreukrisico van een DNSSEC-storing, zwaarder dan de meerwaarde van de DNSSEC-beveiliging.
"Economische oorzaken en achterhaalde ontwerpkeuzen"
Volgens Huston is de oorzaak van de gebrekkige adoptie van DNSSEC vooral economisch van aard: DNSSEC is een beveiliging op infrastructuurniveau. Om van DNSSEC een succes te maken, zouden de opbrengsten volgens hem op applicatieniveau moeten liggen. Nu zijn de uitkomsten en de waarde van de DNSSEC-beveiliging daar niet zichtbaar: De toegang tot een ondertekende domeinnaam die niet valideert wordt door de resolver zonder verdere plichtplegingen of toelichting geblokkeerd. Evenzo: een applicatie die wel met succes een verbinding tot stand brengt, heeft geen idee of er überhaupt DNSSEC-validatie heeft plaatsgevonden. Omdat een applicatie niets weet van een al dan niet uitgevoerde DNSSEC-validatie, kan deze nu niet anders dan zijn eigen authenticatiemaatregelen nemen (ongeacht of de DNSSEC-beveiliging wel of niet aanwezig is).
In een reactie op de blog van Huston stelt Edward Lewis, destijds betrokken bij de ontwikkeling van DNSSEC, dat het niet alleen economische overwegingen zijn die adoptie in de weg staan. Volgens hem zijn toen ook ontwerpkeuzen gemaakt die inmiddels achterhaald zijn.
Zo is destijds al aangetekend dat de bescherming van de mapping van een domeinnaam naar een IP-adres maar een gedeelte van de puzzel is. DNSSEC garandeert immers wel de authenticiteit en de integriteit van de DNS-data, maar beschermt deze niet tegen afluisteren (de vertrouwelijkheid). En zonder RPKI is de routering naar de juiste host ook niet gegarandeerd.
Ontwerpkeuzen
Een andere ontwerpkeuze is dat alle records in een zone vooraf ondertekend worden. Serversystemen waren destijds nog niet veilig genoeg om cryptografische sleutels op te bewaren, en op deze manier kon je de private sleutels offline houden.
Wat daarbij is opgeofferd is de mogelijkheid om DNS-records dynamisch (on-the-fly) te ondertekenen. Dat zou niet alleen het updaten van zones maar ook het genereren van negatieve responses, en het ondertekenen van wildcard-records en CNAME/DNAME-verwijzingen, makkelijker en efficiënter maken. Bovendien heb je dan het ingewikkelde (en deels achterhaalde) NSEC(3)-mechanisme niet meer nodig. Maar daarvoor zouden wel alle autoritatieve nameservers voor een zone onder dezelfde eigenaar moeten vallen of anderszins toegang tot de private sleutel(s) moeten hebben.
Een laatste bezwaar is dat de bescherming van de DNSSEC-vertrouwensketen in het algemeen niet tot op het systeem van de eindgebruiker doorloopt (de onbeschermde "Last Mile" bij gebruik van een stub resolver). Nu moeten de meeste eindgebruikers erop vertrouwen dat de AD-vlag door de caching DNS-server die ze gebruiken juist is gezet en onderweg niet is gecompromitteerd. Versleuteling van het DNS-verkeer lost dit probleem en dat van de ontbrekende vertrouwelijkheid gedeeltelijk op, maar idealiter zou elke client zelf de DNSSEC-validatie uit moeten voeren.
Automatisering
Automatisering van het DNSSEC-beheer is dé truc om complexiteit, fouten en risico's gerelateerd aan handwerk terug te dringen. Voor de PowerDNS-software is dat zelfs de belangrijkste onderscheidende waarde ten opzichte van andere autoritatieve nameservers.
De herondertekening en het sleutelbeheer zijn al jaren overal volledig geautomatiseerd. Maar inmiddels zijn er ook mechanismen beschikbaar die de uitwisseling van cryptografische records tussen de verschillende lagen van een eenmaal opgezette chain-of-trust te kunnen automatiseren.
Waar voorheen vaak handmatige actie vereist was, kan de update van de DS-records nu ook volledig geautomatiseerd uitgevoerd worden (middels CDNSKEY- en/of CDS-records). Daarmee is de opsplitsing van het cryptografische sleutelpaar in een cascade van KSK- en ZSK-sleutelparen niet langer nodig. Dit mechanisme is destijds bedacht om de uitwisseling van sleutelmateriaal tussen child-zone en parent-zone te beperken. Voor de update van het DS-record in de bovenliggende zone ben je over het algemeen immers afhankelijk van een andere beheerder. PowerDNS maakt standaard al gebruik van een enkelvoudig CSK-sleutelpaar (met een lange geldigheidsduur).
Dit CDNSKEY/CDS-mechanisme is complementair aan het mechanisme beschreven in RFC 5011. Dat kunnen validerende resolvers gebruiken om zonder tussenkomst van een beheerder over te schakelen naar een nieuw trust anchor. Zo kunnen resolvers de volledige rollover van het root KSK-sleutelpaar, waarvan het actuele trust anchor op elke validerende resolver aanwezig moet zijn, automatisch volgen. Na de (eerste) root-KSK rollover in 2017/2018 wordt RFC 5011 door vrijwel alle validerende resolvers ondersteund.
Van bottom-up naar top-down
De vereenvoudiging van NSEC(3) en de KSK/ZSK-cascade, en de automatisering van de uitwisseling van cryptografische records tussen de verschillende lagen in de DNS-hiërarchie, zijn forse stappen in het terugdringen van de complexiteit, inefficiënties en risico's verbonden aan DNSSEC. Fundamenteler is dat bij het ontwerp van DNSSEC destijds gedacht werd dat de invoering bottom-up zou plaatsvinden. Individuele isles-of-trust, in eerste instantie samengebracht onder het trust anchor van de DLV-dienst, zouden in de loop der tijd naar de reguliere DNS-namespace verplaatst worden naarmate de topleveldomeinen en uiteindelijk de rootzone ondertekend zouden worden.
De adoptie van DNSSEC verloopt echter top-down: de root werd in 2010 ondertekend en inmiddels ondersteunt meer dan 90 procent van de top-level domeinen DNSSEC. De rest van de DNS-hiërarchie komt daar (wereldwijd gezien) langzaamaan achteraan gehobbeld. Dat is waarom zowel Huston als Lewis veel belang hechten aan de ontwikkeling van een hele nieuwe delegatiemethode voor DNS.
Een nieuw DELEG-recordtype
Het nieuwe DELEG-recordtype [1] – op dit moment nog volop in ontwikkeling – moet het huidige, ruim 40 jaar oude delegatiemechanisme van DNS moderniseren. Om te beginnen vervangt het de NS- en glue-records in de parentzone. Daarnaast kan het naar een versleutelde DNS-dienst gebaseerd op DoT, DoH of DoQ verwijzen en een alternatief poortnummer specificeren. Tenslotte kan een DELEG-record ook het startpunt zijn van een reeks SVCB/CNAME-verwijzingen, waarmee het mogelijk wordt om delegaties voor meerdere subdomeinen te delen en op een centrale locatie te hosten. Zo kunnen serviceproviders en DNS-operators wijzigingen maken in bulk en zonder dat daarvoor aanpassingen in de parentzone hoeven worden gedaan. Dat maakt het uitbesteden van het draaien van de DNS-servers door een registrar/houder naar een DNS-dienstverlener makkelijker.
Het nieuwe DELEG-recordtype moet de delegatie naar subdomeinen expliciet top-down en autoritatief maken. Daarmee wordt de oude, zachte delegatiemethode vervangen door een methode die aansluit bij de harde, autoritatieve DS-koppeling van de DNSSEC-hiërarchie.
Andere voordelen zijn dat met de ondertekening van de delegatie een substitutie-aanval wordt voorkomen en dat met de mogelijkheid om een versleuteld transport te specificeren het 'Last Mile'-probleem van de stub resolver wordt aangepakt. Het gebruik van een TCP-verbinding maakt bovendien een nieuwe innovatie mogelijk: resolvers zouden de cachende DNS-server kunnen vragen om gelijk de complete keten van DNS(SEC)-records benodigd voor validatie mee te sturen (vergelijk de CHAIN-queries in RFC 7901).
Nieuwe beveiligingstoepassingen
Naast het directe belang dat DNSSEC heeft voor de beveiliging van het DNS-systeem, zijn bovenop de DNSSEC-infrastructuur allerlei nieuwe beveiligingstoepassingen te bouwen. De belangrijkste toepassing op DNSSEC is nu de beveiliging van mail middels SPF, DKIM, DMARC en DANE, zij het dat alleen voor die laatste de toepassing van DNSSEC een harde verplichting is. En op vergelijkbare wijze als DANE/TLSA dat doet voor TLS-certificaten, bouwen SSHFP en OPENPGPKEY voort op de DNSSEC-infrastructuur om de publieke sleutels voor respectievelijk SSH en OpenPGP cryptografisch te verankeren. Sterker nog, OPENPGPKEY (DANE voor OpenPGP) lost het sleuteldistributie- en sleutelauthenticatie-probleem van OpenPGP op, iets wat altijd als een sta-in-de-weg voor de adoptie van OpenPGP werd gezien.
Een andere kandidaat voor DNSSEC-beveiliging is de uitgifte van een Domain-Validated TLS-certificaat, dat nu – in weerwil van de naam – geen DNSSEC-beveiliging vereist. Om een dergelijk certificaat te krijgen, hoef je op dit moment alleen eenmalig te laten zien dat je controle hebt over een domein (per mail of via het web). Het risico dat een aanvaller deze relatief simpele domein-verificatie omzeilt en zo in het bezit van een geldig TLS-certificaat komt, is ook expliciet benoemd in RFC 5452.
Hetzelfde geldt voor het CAA-record, dat het gebruik van een specifieke CA voorschrijft bij het ondertekenen van een TLS-certificaat. RFC 8659 raadt de toepassing van DNSSEC hierbij wel sterk aan, maar stelt dit niet verplicht.
Grote dienstverleners moeten om
Deze voorbeelden laten zien dat DNSSEC niet alleen belangrijk is voor de beveiliging van het bestaande DNS-systeem, maar dat het ook een fundament legt voor nieuwe en toekomstige beveiligingstechnologieën. Daarboven beschreven we diverse vereenvoudigingen en innovaties waaruit blijkt dat DNSSEC zich ondanks zijn leeftijd weldegelijk aanpast aan de eisen van de huidige tijd.
Maar voor de daadwerkelijke doorbraak in het gebruik van DNSSEC is inderdaad nodig dat de grote dienstverleners hun beleid veranderen. Tot nu toe bleven hun inspanningen beperkt tot het opzetten van een nieuwe DNSSEC-beveiligde MX-ingang door Google (mx1/2/3/4.smtp.goog) en Microsoft (mx.microsoft). Wij sluiten ons dan ook van harte aan bij het pleidooi van Lewis voor een inventarisatie van de redenen waarom al die operators DNSSEC niet aan willen zetten op hun hoofddomeinen.