Registrars moeten hun DNSSEC -configuraties in orde maken
Validatiefouten bemoeilijken verdere invoering
Onlangs vroeg SIDN zijn registrars om extra aandacht voor DNSSEC-configuratiefouten. Nu steeds meer ISP's op hun caching DNS-servers ook valideren, is het van groot belang dat de DNSSEC-instellingen van een domein in orde zijn. Een Domeinnaam die ten onrechte niet goed valideert, levert immers voor een web browser of een mail gateway, en dus voor de eindgebruiker een acuut probleem op.
Vervelend is dat op dit moment ongeveer 50 duizend van de ruim 1,4 miljoen "ondertekende" .nl-domeinen niet goed zijn geconfigureerd; dat is bijna vier procent. Die beschadigde domeinen leveren vooruitstrevende ISP's die nu al valideren te veel werk op. Voor T-Mobile was het reden om hun harde validatie vorige maand om te zetten naar fault-permissive mode — of val-permissive zoals deze modus in Unbound, een veelgebruikte validerende resolver, officieel heet. Dat betekent dat validatiefouten nog wel gedetecteerd worden, maar niet meer tot de blokkade van een domeinnaam leiden.
Oud sleutelmateriaal
Wij zijn meer dan twee jaar geleden begonnen met de validatie van DNSSEC op onze DNS -servers,
vertelt Ewout Meij, security specialist bij T-Mobile. Als een domein niet goed valideerde, moesten wij aan onze klant uitleggen dat het probleem bij een andere registrar zat. De meeste bellers waren klanten of Joomla web-hosters; het is lastig om hen dit duidelijk te maken. Bovendien is er op dit moment geen enkele feedback vanuit de web browser of de mail client om aan te geven of een domeinbeveiliging wel of niet in orde is. Wij zijn destijds met DNSSEC-validatie begonnen vanwege een voorliefde voor technologie, en deze beveiliging zag er goed uit. Gelukkig worden klanten nu alsnog doorverbonden.
Wat er precies moet gebeuren voordat T-Mobile de validatie weer hard aan kan zetten, kan Meij nog niet zeggen. We hebben daar nog geen limiet voor gesteld, maar het zou in ieder geval een orde grootte kleiner moeten zijn, bijvoorbeeld 0,1 procent. SIDN heeft uitgezocht waar de problemen vandaan komen, en dan blijkt dat een significant deel wordt veroorzaakt door domeinverhuizingen.
Daarbij blijft het oude sleutelmateriaal bij SIDN staan, terwijl de nieuwe DNS-operator nog geen DNSSEC ondersteunt. Vandaar de oproep van SIDN aan deze registrars om het vinkje voor het behoud van DNSSEC bij verhuizing in het DomeinRegistratieSysteem (DRS) uit te zetten.
Destijds is er door SIDN en de technische commissie van de VvR (Vereniging van Registrars) voor gekozen om dit vinkje standaard aan te zetten. Op die manier wilde men de ondersteuning van DNSSEC stimuleren. Nu steeds meer ISP's gaan valideren, lijken deze voorlopers echter de dupe te worden van registrars die hun DNSSEC-configuratie niet goed voor elkaar hebben.
Groeipijnen
Desondanks geeft Meij aan er toch vroeg bij te willen zijn. Dat geldt bijvoorbeeld ook voor IPv6. Voor ons zijn dit soort trajecten — inclusief de bijbehorende groeipijnen — ook onderdeel van onze R&D, zeker als we daarbij kunnen samenwerken met SIDN. Inmiddels krijgen we van andere ISP's ook vragen over de implementatie. Dat zijn dan bijvoorbeeld technische afdelingen die vanuit hogere regionen vragen krijgen over DNSSEC. Dan blijken veel technici toch nog huiverig te zijn. Het zou goed zijn als meer grote spelers zouden valideren — al was het alleen maar in val-permissive mode — zodat de problemen helder worden.
Volgens expert administrator Michael van Slingerland zouden de problemen zichzelf oplossen als DNSSEC-validatie meer massa zou krijgen. Dan zorgen alle registrars direct dat ze of dat vinkje omzetten of DNSSEC goed gaan implementeren. En als een goed gevalideerde domeinnaam zichtbaar zou zijn in de browser, dan zou dat een belangrijke incentive zijn om het .nl-domein op orde te kwijgen.
Wegverhuizen
Bij hosting provider Mijndomein, die afgelopen najaar bijna al zijn 340 duizend domeinen ondertekende, is een geautomatiseerd systeem bedacht om te voorkomen dat de DNSSEC-configuraties van domeinen beschadigd raken. Binnenkomende domeinen zijn sowieso geen probleem,
vertelt business unit manager Ewout de Graaf. Die voorzien we zelf van nieuwe DNSSEC-informatie. Maar ook voor wegverhuizende proberen we het goede te doen. Wanneer iemand zijn autorisatiecode bij ons opvraagt, is dat een teken dat die persoon wil wegverhuizen. Uit voorzorg verwijderen wij dan de DNSKEY-informatie. Is het betreffende domein na twee weken nog niet weg, dan genereren we een nieuwe sleutel en zetten we DNSSEC weer aan.
Daarbij kunnen twee dingen mis gaan: Soms zijn er mensen die zo snel wegverhuizen — binnen een of twee minuten na het opvragen van de autorisatiecode — dat onze systemen te laat zijn: het domein is al weg en DNSSEC kan niet meer worden uitgezet. Daarnaast zijn er de mensen die een sleutel opvragen maar pas weken later verhuizen. Ook in dat geval wordt een domein wegverhuisd terwijl er nog sleutelmateriaal aanwezig was. Een test leert echter dat van al die domeinen een groot deel door de nieuwe eigenaar toch netjes wordt ontdaan van de DNSSEC-steutelinformatie. Uiteindelijk gaat het dus maar om een klein percentage waar het toch mis gaat.
Meer partijen
Als voorzitter van de commissie techniek van de VvR was De Graaf ook betrokken bij de gezamenlijke beslissing met SIDN om het vinkje voor behoud van DNSSEC-sleutelmateriaal standaard aan te zetten. Op dat moment had nog niemand een idee in hoeverre met name registrars met een groot portfolio DNSSEC zouden gaan implementeren. Was dat beperkt gebleven, dan was ook het verhuisprobleem beperkt geweest. Maar inmiddels zijn we ingehaald door ons eigen succes: door het omarmen van DNSSEC door grote registrars zijn er nu heel veel domeinen ondertekend en is ook het verhuisprobleem veel groter dan was voorzien. Als dat destijds bekend was geweest, zou deze beslissing wellicht anders zijn uitgevallen. Het is op dit moment ook niet meer mogelijk om dat vinkje alsnog uit te zetten. Je weet immers niet meer welke registrars ondertussen wel en niet zelf het vinkje hebben aan- of uitgezet.
Extra complicerende factor in dit geheel is dat hosting-bedrijven niet noodzakelijk ook het DNS-beheer doen. Dan komen vragen van klanten naar aanleiding van problematische DNS-configuraties op zijn best via het hosting-bedrijf bij de betreffende DNS-operator terecht. Met de invoering van DNSSEC zijn niet alleen de registrars maar nu ook de DNS-operators en de ISP's betrokken bij het goed functioneren van DNS en internet. SIDN is op dit moment de bindende factor tussen de registrars, maar of zij ook deze andere partijen bij elkaar zouden moeten brengen durf ik niet te zeggen. Het gaat uiteindelijk om een goed werkend internet en daar zijn in Nederland meerdere partijen (gedeeltelijk) verantwoordelijk voor.
Consequenties
De problemen die we zien door beschadigde DNSSEC-configuraties zijn heel gevarieerd,
zegt Marco Davids, technisch adviseur bij SIDN. In het ergste geval werken complete diensten niet meer. Zo zagen we het geval van een VoIP-leverancier [Voice over IP; internet-telefonie] voorbij komen, die daardoor in de problemen is geraakt. En dat T-Mobile zich genoodzaakt zag om zijn resolvers in val-permissive mode te zetten, zien wij hier ook als een ernstig gevolg.
Tegelijkertijd put Davids juist hoop uit het feit dat steeds meer ISP's gaan valideren. Op dit moment wordt de pijn nog niet op de juist plek gevoeld als het niet werkt. Nu zijn die goedwillende, validerende ISP's nog de dupe. Als straks veel meer partijen gaan valideren — slechts een kwestie van tijd voor Google Public DNS — dan komen de consequenties voor niet-bereikbare namen daar te liggen waar ze thuishoren, namelijk bij de DNS-operator.
Vervolgstappen
Ondertussen wordt bij SIDN stevig nagedacht over vervolgstappen om de weg vrij te maken voor de verdere invoering van DNSSEC (validatie). We vertrouwden er op dat de registrars voldoende vakmanschap aan de dag zouden leggen wat betreft het gebruik van 'het vinkje',
aldus Davids. Dat was bij de meeste ook het geval, maar we hebben toch moeten constateren dat dat helaas niet geldt voor alle registrars.
Overigens is het vinkje lang niet voor alle DNSSEC-fouten verantwoordelijk. We zien ook verschillende andere oorzaken, en sommige daarvan niet eens DNSSEC-gerelateerd. Zo liepen we ook tegen een bedenkelijke 'rate limiter'-configuratie aan, die onze DNSSEC-metingen vertroebelde. Die fout wordt dus 'en passant' gerepareerd.
Met deze oproep doet SIDN opnieuw een beroep op de verantwoordelijkheid van de registrars. Daarnaast blijft de beheerder van het .nl-domein meedenken over oplossingen: Dankzij de samenwerking met enkele validerende ISP's, die ons data leveren over waargenomen validatiefouten, hebben we nu een systeem ontwikkeld dat registrars waarschuwt voor niet-validerende (bogus) domeinnamen. Dit systeem is onlangs geheel geautomatiseerd en dus veel efficiënter geworden.
Ook Daniel Federer, key account manager bij SIDN, benadrukt de gezamenlijke verantwoordelijkheid. Validatie is de volgende stap om alle ondertekende domeinnamen daadwerkelijk veiliger te maken. Vandaar dat wij intensief samenwerken met ISP's, en actief registrars benaderen om het aantal validatiefouten te verminderen. Tegelijkertijd zijn wij ons ervan bewust dat DNSSEC voor eindgebruikers en domeinnaamhouders geen eenvoudige kost is. Maar als we er gezamenlijk voor zorgen dat er zo min mogelijk fouten ontstaan, dan hebben hebben zowel registrars als ISP's een goed verhaal naar hun klanten.
Bewustwording
Hoewel Nederland met zoveel beveiligde .nl-domeinnamen als een van de eerste tegen deze schaduwzijde van DNSSEC aanloopt, zijn we niet de enige. Zo worstelt Comcast, een grote Amerikaanse ISP, met dezelfde problematiek. Zij hopen op bewustwording door te publiceren over niet-validerende domeinnamen,
vertelt Davids, via hun website en op Twitter. Maar wij denken dat het effectiever is om de registrars van de aangedane domeinnamen rechtstreeks te informeren en te helpen met een oplossing. Daarnaast stimuleren we de ontwikkeling van 'slimme resolvers', die voor fout geconfigureerde domeinnamen op een beheerdersvriendelijke en verantwoorde wijze naar 'permissive mode' kunnen overschakelen. Daar horen we binnenkort zeker meer van.
Davids is dan ook alles behalve pessimistisch. Het is niet voor niets dat ook Google een uitgebreide informatiepagina wijdt aan de bedreigingen van een onbeschermd DNS. Het systeem is te belangrijk en te kwetsbaar om het niet met DNSSEC te beveiligen.
