DNSSEC -trigger brengt DNSSEC naar de eindgebruiker
DNSSEC beveiligt de hele keten van DNS -informatie. In de huidige versies van Windows en (Mac) OS X is deze standaard echter nog niet volledig geïmplementeerd. Dnssec-trigger is een intelligente tool waarmee de vertrouwensketen tot helemaal op de client kan worden uitgebreid. Daartoe wordt naast de bestaande resolver een alternatieve resolver geïnstalleerd. Dat maakt deze software essentieel voor eindgebruikers die de DNSSEC-verificatie niet aan hun internet service provider willen overlaten en voor organisaties die zeker willen weten dat de mobiele computers van hun werknemers onderweg bij de juiste IP-adressen uitkomen.
Vanaf 15 mei jongstleden is DNSSEC voor alle .nl-domeinen beschikbaar. Dat betekent dat deze bescherming nu in principe door alle registrars en internet service providers aan de domeinnaamhouders aangeboden kan worden. De juiste vertaling van internet-namen naar IP-adressen is voor de eindgebruiker echter alleen gegarandeerd als DNSSEC door de hele DNS-keten wordt ondersteund: van top-level domein, registrars en autoratieve DNS-servers, via de caching DNS-servers van de internet service providers, tot aan de client (de resolver).
Het eerste gedeelte komt inmiddels goed op gang. Sinds SIDN de ondersteuning van DNSSEC voor het .nl-domein volledig operationeel heeft, groeit het aantal ondertekende domeinen explosief, met name doordat DNS-operators in een keer hele bestanden voor hun klanten ondertekenen.
Stub-resolvers
Op internationaal niveau ligt het aandeel DNS queries dat om DNSSEC vraagt inmiddels boven de zestig procent. Deze cijfers worden echter gemeten op de autoratieve name-servers van RIPE NCC. Daar zullen voornamelijk vragen van de caching servers van internet providers binnen komen. De meeste clients bevatten zelf immers alleen een stub-resolver en laten de recursieve queries over aan de centrale servers die ze via DHCP toegewezen krijgen.
Op client-niveau zal de ondersteuning van DNSSEC dan ook veel lager liggen. Om de keten compleet te maken, moet de resolver immers zelf de hele vertrouwensketen (chain-of-trust) controleren. Maar Windows 7 en Windows Server 2008 bevatten beide alleen een DNSSEC-aware
resolver. Dat betekent dat alleen gecontroleerd wordt of het AD-vlaggetje (Authenticated Data) door de DNS-server in het antwoord is gezet. Dat heeft echter nauwelijks waarde als je weet dat de verbinding tussen client en caching DNS-server zelden of nooit versleuteld wordt.
Dnssec-trigger
Dnssec-trigger is een alternatieve resolver voor bezitters van een Windows- of Mac-computer. Deze probeert zo goed en veilig mogelijk gebruik te maken van DNSSEC, zonder de bestaande DNS-faciliteiten gelijk helemaal terzijde te schuiven. Bij de vertaling van een internet-naam naar een IP-adres wordt dus in eerste instantie gebruik gemaakt van de lokale DNS-servers zoals die meestal via DHCP worden aangeleverd. Voordeel van deze caches is dat ze snel en actueel zijn, en de infrastructuur ontlasten.
Zijn deze servers om een of andere reden niet beschikbaar, dan wordt een volledige, recursieve DNS-actie uitgevoerd. Dat betekent dat dnssec-trigger aan een root-server vraagt welke name-servers autoratief zijn voor het betreffende top-level domein. Daar wordt vervolgens weer gevraagd waar de DNS-informatie over de domein in kwestie kan worden opgevraagd. Enzovoort. Zo wordt de hele DNS-structuur door de resolver afgelopen.
Of de DNS records nu afkomstig zijn van de caching servers of van een recursieve query, dnssec-trigger zal voor een DNSSEC-beveiligd domein altijd de ondertekende records verifiëren, net als de trust anchors die in het hoger gelegen domein zijn vastgelegd. Op deze manier wordt de volledige vertrouwensketen geverifieerd.
Unbound
Tot zo ver doet dnssec-trigger nog niets bijzonders: het neemt de DNSSEC-verificatie voor zijn rekening waar de resolvers van Windows en OS X dat zouden moeten doen. Daarvoor maakt dnssec-trigger gebruik van Unbound op het localhost adres. Dat is een DNSSEC-validerende DNS-server die zelf zowel caching als recursieve resolving doet. Normaal gesproken gebruikt deze de caching DNS-server van de internet provider, maar dnssec-trigger herconfigureert deze zodanig dat deze functionaliteit verder uitgebouwd wordt.
Lukt het namelijk niet om zelf een recursieve resolving te doen — bijvoorbeeld omdat de netwerkbeheerders DNS queries buiten de caching servers om hebben geblokkeerd — dan wordt geprobeerd via poort 80 (HTTP) contact te maken met een DNS-server die staat opgesteld bij NLnet Labs. Dat is het not-for-profit Internet research en development laboratorium dat de ontwikkelaar is van zowel dnssec-trigger als Unbound. Hun DNS-server kan de recursieve queries voor een geblokkeerde client uitvoeren en teruggeven via deze poort die meestal open staat voor web-verkeer.
DNS over HTTPS
Lukt ook dat niet — bijvoorbeeld omdat specifiek DNS over TCP naar poort 80 door de firewall wordt geblokkeerd — dan is poort 443 (HTTPS) nog een laatste optie. Deze wordt normaal gesproken gebruikt voor versleutelde verbindingen naar het web (denk aan het slotje in de browser), maar kan ook ingezet worden om een DNS query ingebed in een SSL-verbinding te transporteren. Een tussenliggende firewall kan dan niet eens zien dat het om DNS-verkeer gaat.
Die laatste mogelijkheid, waarbij DNS over HTTPS geleid wordt, is een voordehandliggende optie. Als port 443 niet benaderbaar is — dat wil zeggen dat beveiligde web-verbindingen onmogelijk zijn — dan heeft DNSSEC immers ook nauwelijks zin.
Pop-up
Van al deze berichtenuitwisselingen, controles en fallbacks ziet de gebruiker helemaal niets. Onderdeel van het ontwerp was de eis om zo transparant mogelijk te werk te gaan. Pas als geen enkele optie blijkt te werken, wordt een pop-up windows getoond. Daarin wordt aan de gebruiker uitgelegd dat het niet is gelukt om de DNSSEC-beveiligde internet-naam te verifiëren en gevraagd of hij desondanks toch verder wil browsen. In dat laatste geval wordt gewoon gebruik gemaakt van de informatie zoals die door de caching DNS-servers wordt opgehoest. Unbound wordt dan wel uitgeschakeld, zodat die cache niet vervuild wordt met ongeverifieerde DNS-informatie.
In de hele keten zit ook nog een controle voor het gebruik van draadloze access points ingebouwd. Denk dan aan de hotspots zoals die vaak door hotels en restaurants, of in de trein worden aangeboden. Deze zijn vaak zo geconfigureerd dat ze (met behulp van valse
DNS-informatie) alle verkeer omleiden totdat is ingelogd op een speciale webpagina. Dnssec-trigger controleert dat door naar een vooraf ingesteld adres te browsen
. Komt er een andere webpagina terug dan wat daar zou moeten staan, dan weet de software dat er eerst ingelogd moet worden. Ook in dat geval krijgt de gebruiker een pop-up te zien.
Open source
Dnssec-trigger en Unbound zijn in ambachtelijke POSIX C-code geschreven. De software is ontwikkeld door NLnet Labs onder leiding van lead developer Wouter Wijngaards. Dnssec-trigger bevindt zich nu nog in het alpha-stadium. Dat betekent dat deze software alleen geschikt is om mee te experimenteren, en nog niet volwassen genoeg is om volledig op te vertrouwen. Unbound is als high-performance recursieve caching name-server buitengewoon stabiel en wordt toegepast in productie-omgevingen bij ISP's en in mobiele datanetwerken. In combinatie met dnssec-trigger kan handmatig ingrijpen door de mobiele gebruiker echter nog noodzakelijk zijn.
Beide pakketten zijn open source software, uitgebracht onder de BSD-licentie. Dat betekent dat deze gratis te downloaden en te gebruiken zijn. Naast OS X en Windows wordt ook Linux ondersteund. Daarvoor kan de tarball worden binnengehaald en gecompileerd. Maar er zijn ook RPM-files beschikbaar (voor Red Hat en Fedora, en afgeleiden daarvan).
De leveranciers van besturingssystemen werken op dit moment aan de uitbreiding van hun netwerk-stacks met DNSSEC. Of ze dat helemaal zelf implementeren of dat ze bijvoorbeeld gebruik maken van de code van NLnet Labs is niet te zeggen. Wel laat het feit dat Unbound maar liefst 50 duizend regels code bevat zien dat DNSSEC-verificatie nog behoorlijk complex is. Voor sommige Linux-distributies wordt Unbound in ieder geval in de repository opgenomen als de vervanger van de BIND resolver.
Tenslotte: elke DNS resolver is natuurlijk maar zo veilig als de client zelf. Als je desktop met malware is besmet, dan is geen enkel programma — en dus ook niet de resolver — te vertrouwen. Weet je zeker dat je systeem in orde is, dan kun je met DNSSEC en dnssec-trigger de vertrouwensketen uitbreiden tot helemaal op de client.
