In Nederland lopen we wereldwijd voorop als het aankomt op het aantal met DNSSEC beveiligde .nl-domeinnamen. Ruim 30% van alle bijna 5,5 miljoen domeinnamen is gesigneerd, alles bij elkaar bijna 1,7 miljoen domeinnamen. Wanneer er een bepaald percentage aan fouten in DNSSEC-beveiliging sluipt, gaat het bij dit soort aantallen al gauw om enkele honderden domeinnamen. Teveel, vonden we bij SIDN Labs.
DNSSEC is niet vergevingsgezind
DNSSEC gaat om veiligheid en, zoals deze week ook te zien is aan de beveiliging rondom de Nuclear Security Summit 2014, gaat het bij beveiliging zelden om halve maatregelen. Wanneer een DNS-antwoord met DNSSEC niet klopt, bijvoorbeeld als gevolg van een klein foutje, kan een validerende resolver niet anders dan dit antwoord afkeuren. De gevolgen zijn dan, dat het voor de gebruiker ‘niet werkt’. En een tussenweg is er feitelijk niet. Een bepaald percentage .nl-domeinnamen blijkt inderdaad niet goed gesigneerd. Soms betreft het vrij triviale oorzaken, die eigenlijk niet voor zouden mogen komen. Maar geregeld gaat het ook om de wat meer exotische ‘cornercases’, diep verstopt in de krochten van NSEC en NSEC3.
Slecht voor DNSSEC-adoptie
Fouten, ook al gaat het om een klein percentage, leiden bij zulke grote aantallen gesigneerde .nl-domeinnamen tot problemen. Klanten van een grote mobiele provider, die validatie al sinds jaar en dag aan had staan, begonnen bijvoorbeeld te klagen. Voor de provider zijn dat lastige situaties; het probleem wordt veroorzaakt aan de signerende kant, maar de hinder wordt ervaren aan de validerende kant. Dat is aan een gemiddelde klant lastig uit te leggen (“mijn buurman is klant bij de concurrent en bij hem werkt deze website wel!”) De betreffende mobiele provider zag zich genoodzaakt om validatie tijdelijk uit te zetten (dit was overigens nog voordat Google Public DNS ook ging valideren). Het werd duidelijk; fouten aan de signing-kant, hoe weinig ook, zijn niet goed voor de adoptie van DNSSEC aan de validerende kant. Het percentage fouten moest dus omlaag.
Samenwerking met validerende ISP’s
Samen met enkele ISP’s die al aan validatie doen, hebben we de ‘DNSSEC-validatiemonitor’ ingericht. Feitelijk werkt die heel simpel:
Via de deelnemende ISP’s worden we dagelijks op de hoogte gesteld van waargenomen DNSSEC-validatiefouten in .nl-domeinnamen. Zelf voegen we aan dat lijstje nog alle Alexa top-5000 domeinnamen toe. Het geheel controleren we zelf nog een keer extra, voordat we er rapporten over samenstellen. De rapporten sturen we naar de registrars waar de incorrect gesigneerde domeinnaam is geregistreerd, met het verzoek de problemen op te lossen. En via persoonlijk contact proberen we tot oplossingen te komen bij registrars met aanzienlijke aantallen fouten of notoire DNSSEC-problemen. Een groot voordeel van de samenwerking met ISP’s, is dat we informatie krijgen uit de praktijk. We zien bijvoorbeeld queries op third-level (of dieper) waarvan een simpele test op second-level geen fouten zou hebben gegeven, maar die toch niet helemaal goed bleken te zijn gesigneerd. Bijvoorbeeld SRV-queries zoals: _tsdns._tcp.example.nl en dergelijke.
Oorzaken van de fouten
We hebben ook gekeken naar de soorten fouten die worden gemaakt.
In deze blogpost ga ik hier niet detail op in, dat voert te ver (misschien een volgende keer), maar een probleem dat in het begin vooral speelde, was het beruchte ‘behouden DNSKEY’-vinkje. Kort gezegd komt het erop neer dat bij een verhuizing of overname, waarbij de domeinnaam van gesigneerd naar ongesigneerd gaat, het DS-record niet altijd (automatisch) uit de .nl-zone wordt verwijderd. Een veelgemaakte fout. Maar de bovenstaande tabel laat zien dat er ook tal van andere fouten worden gemaakt, soms vanwege operationele fouten, soms als gevolg van softwarebugs. Daar waar gewenst helpen we bij het troubleshooten hiervan.
Hoeveelheid DNSSEC-fouten met de helft gedaald
Steekproeven wijzen uit dat het percentage foutief gesigneerde .nl-domeinnamen geleidelijk daalt en inmiddels met meer dan de helft is afgenomen:
En ook het aantal registrars waaraan we dagelijks rapporteren, is vergelijkbaar afgenomen:
Al met al een veelbelovend resultaat waar we tevreden over kunnen zijn. De afbeeldingen komen uit een presentatie die collega Cristian Hesselman van SIDN Labs geeft op de 49e ICANN-meeting, die deze week plaatsvindt.
