Extended DNS Errors vinden toepassing in DNS-software en -diensten
Moderne, gestandaardiseerde functie-call voor gebruikersapplicaties ontbreekt nog
De Extended DNS Errors (EDE) die RFC 8914 introduceerde blijken een belangrijke toevoeging aan het DNS-protocol: in eerste instantie om fouten te detecteren en te diagnosticeren (tooling), maar inmiddels ook als basis onder een geavanceerder protocol om resolvers foutmeldingen naar autoritatieve nameservers te laten sturen (RFC 9567).
Wat nog ontbreekt is een nieuwe of uitgebreide functiecall waarmee (stub) resolvers EDE-foutcodes aan hun aanroepende gebruikersapplicatie kunnen doorgeven.
RFC 8914 definieert een uitgebreide lijst van Extended DNS Errors (EDE). Bij elkaar gaat het om 24 foutcodes/meldingen, waarvan bijna de helft gerelateerd aan DNSSEC. Bovendien kan deze lijst in de toekomst nog verder worden uitgebreid met nieuwe foutcodes. Op dit moment kan dat zonder al te veel plichtplegingen op basis van "First Come, First Served".
Tabel 1: EDE-foutcodes
Code | Code | ||
|---|---|---|---|
0 | Other | 13 | Cached Error |
1 | Unsupported DNSKEY Algorithm | 14 | Not Ready |
2 | Unsupported DS Digest Type | 15 | Blocked |
3 | Stale Answer | 16 | Censored |
4 | Forged Answer | 17 | Filtered |
5 | DNSSEC Indeterminate | 18 | Prohibited |
6 | DNSSEC Bogus | 19 | Stale NXDOMAIN Answer |
7 | Signature Expired | 20 | Not Authoritative |
8 | Signature Not Yet Valid | 21 | Not Supported |
9 | DNSKEY Missing | 22 | No Reachable Authority |
10 | RRSIGs Missing | 23 | Network Error |
11 | No Zone Key Bit Set | 24 | Invalid Data |
12 | NSEC Missing |
Geautomatiseerde foutrapportages
De geformaliseerde foutmeldingen hebben 2 voor de hand liggende toepassingen. De eerste is een mechanisme om geautomatiseerde foutrapportages van resolvers naar autoritatieve nameservers te sturen. Daartoe definieert RFC 9567 een uitbreiding op het bestaande DNS-protocol van queries en -responses. Die uitbreiding geeft nameservers de mogelijkheid om een zogenaamd agentdomein met hun responses mee te geven, waarop resolvers vervolgens problemen kunnen melden in de vorm van een speciale query.
Omdat deze ingang verder niet is afgeschermd middels een vorm van authenticatie, is het idee dat een agent op statistische wijze problemen kan afleiden uit de binnenkomende meldingen.
Daarmee bestaat nu voor het eerst een geautomatiseerde mogelijkheid voor resolvers om problemen bij nameservers te melden bij de operator. We hebben dit mechanisme uitgebreider besproken in een eerder gepubliceerd artikel.
Beperkte ondersteuning
Voor zover ons bekend is Unbound op dit moment de enige resolver die foutmeldingen volgens RFC 9567 naar de nameserver kan terugsturen. Je kunt deze mogelijkheid aanzetten vanaf versie 1.23 (april 2025) door middel van deze optie:
dns-error-reporting: yes
De resolver van BIND named ondersteunt deze mogelijkheid (nog) niet, maar het complementaire gedeelte van RFC 9567 is wel al beschikbaar in de autoritatieve nameserver. Vanaf versie 9.21.3 kun je op deze manier een 'Report-Channel'-agent met de responses laten meesturen:
send-report-channel <agent domain>
En door deze optie aan te zetten voor het (autoritatieve) agent-domein, worden binnenkomende foutmeldingen naar de logs weggeschreven:
log-report-channel yes
Gebruikersapplicaties
De tweede toepassing van de geformaliseerde foutmeldingen is minstens net zo waardevol en is het primaire gebruiksscenario van EDE volgens RFC 8914. Tot nu toe kon een (stub) resolver alleen een simpele fout teruggeven aan de gebruikersapplicatie als de resolutie of validatie van een domeinnaam niet lukte (meestal was dat een SERVFAIL RCODE). Je ziet dat bijvoorbeeld aan de eenvoud van de POSIX-functie getaddrinfo().
De BIND/BSD/glibc-functie 'res_query()' en de oude glibc-functie 'gethostbyname()' [FreeBSD] kunnen al wat meer, maar hun foutcodes blijven beperkt, zijn onderling verschillend, en zijn ook weer anders dan de RCODE response-codes zoals gedefinieerd in RFC 1035 en latere uitbreidingen op het DNS-protocol.
Wil je (als applicatiebouwer) meer – en dat is juist met de toepassing van DNSSEC enorm handig – dan zou je de resolver moeten gebruiken van een van de bekende DNS-pakketten of een DNS-dienst die EDE-codes doorgeeft aan zijn clients, en dan ook in combinatie met een (stub) resolver/library die de EDE-codes vervolgens via de API/call weer kan doorgeven aan de aanroepende applicatie.
Op die manier kan EDE ook gebruikt worden om een reden voor het blokkeren, filteren, censureren en verbieden van DNS-responses aan de eindgebruiker door te geven. Aan een uitbreiding van EDE daartoe wordt inmiddels gewerkt [1, 2, 3].
DNS-software
Om met de bekende DNS-pakketten te beginnen: zoals je hieronder kunt zien, hebben de meeste pakketten de afgelopen jaren EDE geïmplementeerd. Voor alle pakketten geldt dat ze (nog) niet alle codes ondersteunen. De fouten treden immers op allerlei verschillende plaatsen op, wat betekent dat op allerlei locaties verspreid over de software aanvullende programmacode voor foutdetectie en -propagatie moet worden toegevoegd.
Je ziet aan de release notes ook dat na de eerste implementatie vaak meer foutcodes worden toegevoegd in latere versies. Hier vind je bijvoorbeeld het overzicht voor BIND9.
Unbound ondersteunt EDE vanaf versie 1.16 middels de 'ede: yes'- en 'ede-serve-expired: yes'-opties [unbound.conf].
BIND9 ondersteunt EDE vanaf versies 9.18 en 9.20.
Knot DNS ondersteunt EDE vanaf versie 3.1.0.
De PowerDNS Recursor ondersteunt EDE vanaf versies 4.5.0 en 4.9.0 middels de 'extended-resolution-errors'-optie (per default enabled vanaf versie 5.0.0).
De autoritatieve nameserver NSD (een snelle referentie-implementatie ontwikkeld door NLnet Labs, onder andere gebruikt in de root zone) ondersteunt EDE vanaf versie 4.3.6.
DNS-dienstverleners
Net als de bekende DNS-pakketten ondersteunen ook de grote DNS-dienstverleners inmiddels de EDE-foutcodes [Cloudflare 1.1.1.1, Google Public DNS]. En net als bij de DNS-pakketten is die ondersteuning nog niet volledig, maar wordt deze wel gaandeweg uitgebreid [Cloudflare 1.1.1.1].
Een veelbelovende toevoeging
In 2023 onderzocht een groep bij de Université Grenoble-Alpes de implementatie en bruikbaarheid van EDE. Om te beginnen evalueerden de onderzoekers 4 veelgebruikte DNS-pakketten en 3 grote DNS-dienstverleners op een hele batterij domeinnamen die ze zelf van specifieke fouten hadden voorzien. Daaruit bleek dat de resolvers in 94 procent van de gevallen verschillende EDE-meldingen genereerden.
De implementatie van Cloudflare 1.1.1.1 kwam in deze eerste evaluatie het beste uit de bus, dus die dienst werd vervolgens gebruikt om de resolutie van ruim 300 miljoen domeinnamen te testen. Daarvan bleken bijna 18 miljoen namen een EDE-fout te genereren (6 procent), waarvan kapotte delegaties en negatieve DNSSEC-validaties de meest voorkomende waren.
De onderzoekers concludeerden dat EDE een veelbelovende toevoeging is om DNS-fouten te detecteren en te diagnosticeren. De inconsistenties van de geretourneerde foutcodes zaten meestal op detailniveau, maar vereisten dus nog wel aandacht van DNS-software-ontwikkelaars en DNS-dienstverleners. De volledige publicatie vind je op hal.science.
DNS-library's
De EDE-foutcodes zoals die naar de client worden doorgegeven door de (caching) DNS-resolvers, de DNS-diensten en de autoritatieve nameservers komen nu in ieder geval in de logs van de (stub) resolvers terecht. Afhankelijk van het type software zou die informatie via de onderliggende API eigenlijk ook naar de gebruikersapplicatie moeten worden gecommuniceerd. Daarvoor is natuurlijk wel een vereiste dat de applicatieprogrammeur de EDE-meldingen ook terugkrijgt bij de functie-aanroep om een netwerkverbinding tot stand te brengen. Maar zoals we hierboven hebben gezien, is op dit moment (nog) niet het geval.
Zelfs libunbound geeft de EDE-foutcodes niet door (het meest voor de hand liggend zou zijn om daarvoor de 'ub_result' struct die de 'ub_resolve()'- en 'ub_resolve_async()'-functies teruggeven uit te breiden).
De enige library's waarvan we nu weten dat die wel native EDE-foutcodes ondersteunen zijn ldns (vanaf versie 1.8.2, middels de 'ldns_edns_ede_get_code()'- en 'ldns_edns_ede_get_text()'-functies) en Net::DNS (een Perl library). De resolutie-functies van de getdns library (net als Unbound, ldns en Net::DNS ontwikkeld door NLnet Labs) ondersteunen EDE nog niet; hetzelfde geldt dus voor de 'getdns_query' command-line tool en de 'stubby' stub resolver (beide gebaseerd op de getdns library).
De 'dig' tool van BIND kan de EDE-informatie wel al aan zijn gebruiker tonen.
Gebruikersapplicaties
Webbrowsers zijn vanwege de vele resolutie-opdrachten een goede eerste kandidaat om EDE-foutmeldingen aan eindgebruikers te laten zien [feature requests voor Chrome en Vivaldi]. Dat doen zij immers ook al bij TLS-gerelateerde problemen. Over het algemeen gebruiken zij nu omwille van de portabiliteit via de 'getaddrinfo()'-functie de (stub) resolver van het operating system. Maar voor hun DoT/DoH/DoQ-functionaliteit hebben zij ook al eigen adresresolutie-implementaties aan boord.
Kortom, met EDE ligt er een belangrijke basis voor de detectie en diagnose van DNS-problemen. Bovendien worden deze foutmeldingen inmiddels geïmplementeerd in de bekende DNS-pakketten en grote DNS-diensten. Het enige dat op dit moment nog ontbreekt is een moderne, gestandaardiseerde functie-call waarmee (stub) resolvers de EDE-foutcodes ook aan hun aanroepende gebruikersapplicatie kunnen doorgeven.
