Stop niet met DNSSEC-validatie bij problematische domeinnamen

De afgelopen jaren zijn er meerdere aanbieders van (gratis) DNS-diensten bijgekomen. Naast de klassieke aanbieders Google Public DNS en OpenDNS kun je nu bijvoorbeeld ook 1.1.1.1 en Quad9 gebruiken. Dat maakt het als eindgebruiker verleidelijk om tussen deze diensten te gaan shoppen op het moment dat je problemen hebt. Een domein met fouten in zijn DNSSEC-configuratie is immers niet benaderbaar via een validerende resolver, maar wel via een resolver die deze beveiliging niet toepast. Hoewel je met het wisselen van DNS-dienst je acute probleem hebt opgelost, ben je hiermee een belangrijke bescherming kwijt. Bovendien zijn er betere methoden om met problematische domeinen om te gaan.

Validatiefouten treden op als er dingen mis zijn in de DNSSEC-configuratie van een domein. Het kan dan bijvoorbeeld gaan om een mismatch tussen de publieke sleutel gepubliceerd als onderdeel van de zone enerzijds en het sleutelmateriaal geregistreerd bij het bovenliggende domein anderzijds (bijvoorbeeld als er iets mis gaat bij verhuizing naar een andere registrar), of om het gebruik van een digitale handtekening waarvan de geldigheidsduur is verlopen (bijvoorbeeld omdat er iets is omgevallen op de autoritatieve server voor dat domein). Probleem daarbij is dat de beheerders van een validerende resolver worden aangesproken door gebruikers die een specifiek domein niet kunnen bereiken, terwijl die beheerders daar zelf niets aan kunnen doen. Het probleem zit in het algemeen immers bij de eigenaar van het betreffende domein.

Vals alarm?

Wil je als gebruiker snel door, dan is het verleidelijk om je resolver om te schakelen naar een DNS-dienst die geen validatie doet. Google, 1.1.1.1 en Quad9 doen allemaal wel validatie, maar die laatste biedt bijvoorbeeld ook alternatieve adressen die geen enkele filtering of validatie toepassen. OpenDNS (Cisco Umbrella) en iets minder bekende publieke diensten als Comodo en Yandex.DNS doen helemaal geen validatie voor hun gebruikers. Hoewel zo'n wissel van DNS-dienst de makkelijkste oplossing is, wordt deze aanpak toch ten zeerste afgeraden. Als eerste moet je heel zeker weten dat de blokkade van het domein dat je wilt bezoeken inderdaad een vals alarm betreft. Ten tweede raak je zonder validatie de bescherming van DNSSEC kwijt voor alle domeinen die je bezoekt.

Configuratieproblemen

Een jaar of zeven geleden was het aantal domeinen met configuratieproblemen in de .nl zone te hoog. Dat weerhield acccess providers ervan om validatie voor hun gebruikers aan te zetten. Wij hebben toen diverse maatregelen genomen, waarna het aantal validatiefouten snel ging dalen. Inmiddels is het aantal DNSSEC-ondertekende .nl-domeinen met problemen verwaarloosbaar klein. Volgens de laatste statistieken zitten we op dit moment onder de 0,1 procent, en dan gaat het ook nog eens om domeinen die weinig gebruikt worden of alleen kortstondig een probleem hebben. Validatiefouten vormen dan ook geen enkele belemmering meer voor het valideren door netwerkbeheerders en access providers.

Negative Trust Anchors

Heb je desondanks toch een validatieprobleem bij het benaderen van een domeinnaam die je niet kunt missen – een enkele keer gaat er ook bij veelbezochte internetdiensten iets mis – dan kun je hiervoor een zogenaamd Negative Trust Anchor (NTA) instellen. Dat is niet anders dan een specifieke (tijdelijke of permanente) uitzondering zolang het betreffende domein niet in orde is gemaakt (houdt daarbij ook rekening met de TTL van de DNS-records). Alle overige domeinnamen blijven gewoon gevalideerd worden. Zo'n NTA specificeer je in je eigen resolver-configuratie als je zelf valideert (bijvoorbeeld met Unbound), en anders moet je je netwerkaanbieder vragen om dat voor je te doen in zijn resolver-infrastructuur. Op onze DNSSEC-pagina hebben we de configuratie van diverse validerende resolvers in verschillende hands-on artikelen uitgebreid beschreven, zowel voor bedrijfsmatige als persoonlijke toepassing. Daar vind je ook informatie over het instellen van NTA's. Om uit te vogelen waar precies het probleem zit kun je DNSViz en de Verisign DNSSEC Debugger gebruiken.