“DNS-protocol moet minder complex, software-implementaties moeten beter”
Problematiek inherent aan veelgebruikt protocol dat nog steeds in ontwikkeling is
De DNS-standaard is groot, ingewikkeld en verbrokkeld. Bovendien is het protocol doorlopend in ontwikkeling en breidt het nog steeds uit. Beste voorbeeld is DNSSEC, dat het traditionele DNS-systeem veranderde van een administratief systeem in een gedistribueerde cryptografische infrastructuur, waar inmiddels weer nieuwe beveiligingsprotocollen bovenop worden gebouwd. Een wildgroei aan functies met bijbehorende RFC's maken DNS complex, maakt dat steeds minder mensen het protocol doorgronden, en vermindert de kwaliteit en veiligheid van implementaties. Inmiddels staat deze problematiek bekend als de 'DNS Camel'.
Vanuit de DNS-gemeenschap worden wel stappen ondernomen om deze kameel te temmen. Zo hebben de softwareontwikkelaars 2 DNS Flag Days georganiseerd om collectief workarounds voor incorrect gedrag van anderen uit hun opensource-DNS-software te verwijderen. En de eerder dit jaar gepubliceerde RFC 9364 zet alle eerder gepubliceerde DNSSEC-gerelateerde RFC's en hun onderlinge verbanden op een rijtje. Tegelijkertijd benadrukt de auteur van die RFC dat deze problematiek inherent is aan een veelgebruikt protocol als DNS dat nog steeds in ontwikkeling is.
‘The DNS Camel’
5 jaar geleden al waarschuwde Bert Hubert, medeoprichter en destijds nog hoofdontwikkelaar van PowerDNS, op de ‘IETF 101’-conferentie voor de uit de hand gelopen complexiteit van het DNS-protocol. Volgens hem konden we niet langer doorgaan met het almaar uitbreiden van DNS zonder dat we uiteindelijk in onoverkomelijke problemen zouden komen.
Het probleem dat Hubert aankaartte staat inmiddels bekend als ‘The DNS Camel’ (een verwijzing naar het Engelse gezegde ‘the straw that broke the camel's back’). Volgens hem waren er destijds al 185 RFC's relevant voor de implementatie van DNS, alles bij elkaar goed voor 2.781 pagina's aan tekst. En sindsdien zijn er alleen maar meer RFC's en meer pagina's bij gekomen.
Wildgroei
Consequenties van de wildgroei aan DNS-functies met bijbehorende RFC's zijn de toenemende complexiteit (onder andere vanwege interferenties tussen de verschillende functies), steeds minder mensen die het protocol doorgronden, en de afnemende kwaliteit en veiligheid van implementaties. Belangrijke oproep van Hubert was om verdere uitbreidingen van het DNS-protocol te beperken, om de standaarden te consolideren en om meer onderling te coördineren.
RFC 9364
De publicatie van RFC 9364 eerder dit jaar is een kleine stap voorwaarts. De primaire doelstelling van deze RFC is om alle eerder gepubliceerde DNSSEC-gerelateerde RFC's en hun onderlinge verbanden op een rijtje te zetten. Daarnaast is deze RFC ook gepubliceerd als Best Current Practice (BCP) 237, waarmee de toepassing van DNSSEC nu ook officieel de huidige standaard is.
De kern van het document geeft een uiterst leesbaar overzicht van de RFC's die DNSSEC definiëren, uitbreiden en updaten. RFC 9364 doet zelf geen enkele aanpassing op de eerder gepubliceerde RFC's en bespreekt die RFC's verder ook niet inhoudelijk. Dit document moet primair fungeren als centrale ingang voor DNSSEC.
“Logische stap”
“Het werd in de loop der tijd steeds moeilijker om naar DNSSEC te refereren,” vertelt Paul Hoffman, Distinguished Technologist bij ICANN en auteur van RFC 9364. “In het begin kon je nog zeggen ‘RFC's 4033, 4034 en 4035’, maar zelfs dat was al onhandig. Naarmate DNSSEC vaker werd toegepast, kregen deze RFC's substantiële updates, waarmee de referentie naar deze 3 RFC's ook niet meer accuraat was. Een korte RFC met daarin de laatste informatie over wat DNSSEC inhoudt was dan ook een logische stap.”
Hetzelfde geldt voor de publicatie van deze RFC als BCP. “Bijna iedereen in de DNS-gemeenschap vindt dat DNSSEC de beste oplossing is voor de authenticatie van DNS-gegevens. Dat maakte het makkelijk om hier tegelijkertijd een BCP van te maken.”
Softwareontwikkelaars
De ontwikkelaars van open-source DNS-software hebben eerder al zelf het initiatief genomen tot 2 'DNS Flag Days' [1] (in 2019 en 2020). Daarbij hebben ze met hun DNS-servers (en in samenwerking met de grote operators) een belangrijke convergentie- en consolidatieslag gemaakt. “De Flag Days zijn geen reactie op de DNS Camel, maar een reactie op incorrecte of onvolledige implementaties van bestaande standaarden,” aldus Benno Overeinder, Managing Director bij NLnet Labs. “De opensource-ontwikkelaars moesten extra inspanningen leveren om incorrecte nameserversoftware te ondersteunen. Ondanks een verschillend uitgangspunt is het beoogde resultaat wel hetzelfde: vermindering van de complexiteit van de DNS-software.”
Hoewel Overeinder met Hubert eens is dat nieuwe functionaliteit de complexiteit van implementaties vergroot, heeft dat volgens hem vooralsnog geen negatieve gevolgen gehad voor de kwaliteit van de DNS-software die NLnet Labs produceert. Wel is het belangrijk om de ontwikkelingen rondom het DNS-standaardisatieproces goed in de gaten te houden: meer complexiteit resulteert immers in een groter risico op fouten die de veiligheid en stabiliteit van de software kunnen aantasten.
Fouten snel gerepareerd
“De ontwikkelaars van opensource-DNS-software zijn eigenlijk al voor Hubert's presentatie van de DNS Camel steeds meer gaan samenwerken," vult ontwikkelaar en onderzoeker Willem Toorop aan. “In eerste instantie misschien door de IETF Hackathons, maar zeker door het Slack-kanaal van CZ.NIC, een rol die nu is overgenomen door de Mattermost-server van DNS-OARC.”
“De impact van RFC 9364 is nog moeilijk te beoordelen,” zegt Overeinder. “Voor ontwikkelaars is het een ‘canonical’ document met daarin de RFC's die geïmplementeerd moeten worden voor de ondersteuning van DNSSEC. De hoop is natuurlijk dat bestaande implementaties in kwaliteit zullen verbeteren. De opensource-implementaties voldoen al aan alle standaarden. Voor proprietary-software is dat moeilijker te bewijzen. Maar incorrect gedrag wordt meestal snel opgemerkt en besproken op open fora als de DNS-AORC mailinglijst. Dat levert ook genoeg druk op om evidente fouten snel gerepareerd te krijgen.”
Tegengeluid
Hoffman benadrukt dat hij (als onderdeel van een minderheid) grote moeite heeft met de DNS Camel. “De naam 'Camel' laat zien dat DNS-mensen te veel met zichzelf bezig zijn. Andere belangrijke internetstandaarden, zoals TCP, bevatten ook een groot aantal uitbreidingen en updates, maar die zijn niet voorzien van een denigrerend label. DNS staat centraal in een almaar evoluerend internet; we moeten dus niet negatief doen over het feit dat DNS moet mee-evolueren. Er is de afgelopen jaren wat dat betreft ook bijna niets veranderd: DNS is nog steeds een uitdijend protocol.”
Daarnaast is Hoffman van mening dat de DNS Flag Days net zo veel schade aanrichten als zij oplossen. “De eerste Flag Days hadden een veel sterkere rechtvaardiging dan wat tegenwoordig wordt voorgesteld. Flag Days leveren zichtbare verbeteringen op, maar ook niet of nauwelijks zichtbare frictie aan de randen. We kunnen de opbrengsten en de schade niet meten. En zelfs als we dat konden, dan is de belangenafweging daarvan niet meer dan een waardeoordeel.”
“Persoonlijk denk ik dat er geen nieuwe Flag Days meer zouden moeten komen, omdat we de beste verbeteringen al hebben doorgevoerd. Maar de problemen die de softwareontwikkelaars proberen op te lossen zijn concrete operationele zaken die het DNS-protocol verstarren. Vandaar dat ik beter kan verwijzen ik naar de DNS-operators, want zij zijn degenen die het meest te maken hebben met de problemen die de Flag Days aanpakken.”
Een volgende Flag Day
“Op dit moment zijn er geen concrete plannen voor een volgende DNS Flag Day,” zegt Toorop. "Als er iets in aanmerking zou komen, dan is het waarschijnlijk om niet langer workarounds te implementeren voor autoritatieve servers die incorrecte NSEC-records genereren. Dat levert problemen op met 'QNAME Minimization' (RFC 7816) en met 'Aggressief Cache-gebruik' (RFC 8198). Maar op dit moment worden deze technologieën nog door te weinig resolvers gebruikt om een daadwerkelijk pijnpunt te worden. Overigens zou het goed zijn als operators deze opties wel zouden aanzetten: het levert hogere prestaties op, betere privacy, en bescherming tegen bepaalde aanvallen (zoals 'Pseudo Random Subdomain'-aanvallen).
“Aan het DNS-protocol wordt inderdaad nog steeds actief gewerkt en gesleuteld,” vertelt Marco Davids, onderzoeker bij SIDN Labs. “Zowel het ontwikkelen als het in de lucht houden van een modern DNS-systeem is steeds ingewikkelder geworden.” Hij is het ook eens met Hubert dat DNS-uitbreidingen die los van elkaar werden uitgedacht en later met elkaar blijken te conflicteren, het leven van softwareontwikkelaars inmiddels flink bemoeilijken. “Je ziet dat ook terug aan de ondersteuning van nieuwe features in nameservers en resolvers. Een relatief nieuwe mogelijkheid als DNS-over-HTTPS (DoH) wordt bijvoorbeeld wel ondersteund door de resolvers van Big Tech – Quad9, Cloudflare en Google Public DNS – maar kleinschaliger omgevingen zoals die bij ISP's draaien kunnen dit niet zo makkelijk meer bijbenen.”
Het bundelen van meerdere RFC's in een overkoepelend document zoals RFC 9364 dat doet, juicht Davids toe. “Dat maakt het voor softwarebouwers en ‘implementers’ allemaal wat toegankelijker. Maar ook een DNS Flag Day, waarbij softwarebouwers een bepaalde verbetering samen coördineren en deze gemeenschappelijk en gelijktijdig uitrollen, is voor specifieke problemen zeker waardevol.”