Gecentraliseerde DNSSEC-validatie op gesloten netwerken
Gepubliceerd op 31-10-2012
De AD-vlag wordt door caching DNS -servers gebruikt om aan te geven dat zij de DNSSEC records hebben gevalideerd. Een client hoeft deze controle dan niet meer zelf uit te voeren.
Deze setup is natuurlijk alleen veilig op een netwerk waar de beveiliging van 'the last mile' gegarandeerd is. Denk dan aan bedrijfsnetwerken, campusnetwerken, en gesloten netwerken van internet-providers en mobiele operators. Daar kan DNSSEC-validatie samen met DNS-caching gecentraliseerd worden op de recursing DNS-servers.
Daarnaast lijkt de rol van de AD-vlag in de nabije toekomst te worden uitgebreid: was deze tot nu toe alleen gedefinieerd voor DNS-antwoorden, inmiddels wordt ook gewerkt aan het gebruik van de AD-vlag in de DNS-vragen.
Waartoe dient de AD-vlag?
De AD-vlag (Authentic Data) wordt gebruikt door DNS-servers om aan te geven dat zij de DNSSEC records hebben gevalideerd. Een client hoeft deze controle dan niet meer zelf uit te voeren. In zijn DNS-verzoek vraagt de (stub) resolver om de DNSSEC records door de DO-vlag (DNSSEC OK) te zetten. Met de netwerk-tool dig zou je daarvoor de optie +dnssec gebruiken. De DNS-server kan dan met die records ook de AD-vlag meegeven. Op die manier neemt deze dus niet alleen de caching maar ook de validatie voor zijn rekening.
Maar let op bij het testen van een validerende DNS-server: de specificatie van DNSSEC (paragraaf 3.1.6) bepaalt dat autoratieve servers geen validatie hoeven doen voor hun eigen domeinen. Zij mogen de AD-vlag dan wel zetten, maar alleen als zij hun autoratieve records op een veilige manier hebben gekregen. Dat moet dan wel apart geconfigureerd worden.
Wanneer kun je de AD-vlag vertrouwen?
Het crypto-technische antwoord luidt natuurlijk: nooit! Omdat het traject tussen (stub) resolver en DNS-server in het algemeen niet is beveiligd, kan de inhoud van het DNS-antwoord via een man-in-the-middle aanval altijd veranderd worden. Dat betekent dat alle niet-DNSSEC records en alle meta-data (de headers) in principe niet te vertrouwen zijn.
Voor dit probleem van 'the last mile' zijn op dit moment verschillende oplossingen beschikbaar:
- De uitwisseling van DNS-informatie kan beveiligd worden met TSIG (Transaction SIGnature). Dit protocol wordt vaak gebruikt om DNS records tussen autoratieve servers uit te wisselen, en om updates voor Dynamische DNS vanaf de DHCP-servers naar de DNS-server te beveiligen.
TSIG is ook te gebruiken tussen resolver en DNS-server, maar is daar geen voordehandliggende optie. Omdat dit protocol gebaseerd is op symmetrische cryptografie, moet eerst een geheime, gedeelde sleutel tussen client en server worden uitgewisseld. - DNSCrypt is wel gebaseerd op een asymmetrisch protocol, en daarmee beter geschikt voor de beveiliging van 'the last mile'. Het wordt gebruikt door DNS service provider OpenDNS om het verkeer met hun clients te versleutelen. Het systeem is een afgeleide van DNSCurve, ontwikkeld door Daniel J. Bernstein (DJB), die een naam heeft hoog te houden waar het gaat om het schrijven van veilige, snelle internet-software. Hij is onder andere de ontwikkelaar van qmail en djbdns.
DNSCrypt wordt met name ondersteund door OpenDNS en is beschikbaar voor Windows, Linux, Mac OS X en de iPhone. - DNSSIG zet zich af tegen DNSCrypt. Het wil vooral een zo transparant mogelijke oplossing zijn, door gebruik te maken van het TXT record.
- Met Secure Dynamic Update heeft Microsoft een protocol ontwikkeld voor de tunneling van DNS-verkeer. Dit systeem maakt gebruik van de GSS-API en een variant van Kerberos.
- Dan is DNS-over-TLS een veel logischer (want open) alternatief, maar vanwege de overhead net zo onelegant voor de versleuteling van het verkeer tussen resolver en DNS-server als Secure Dynamic Update.
Ondanks alle initiatieven van de afgelopen tien jaar, lijkt het erop dat geen van deze technologieën uiteindelijk ingezet zal worden om 'the last mile' te beveiligen. Hoewel het voordehandliggend is om de validatie van DNSSEC te combineren met het cachen van de DNS records, wordt daarbij wel de cryptografisch beveiligde DNSSEC-keten verkort. In het ideale geval loopt deze immers van het trust anchor helemaal tot op de client. Als ook de validatie op de DNS-servers uitgevoerd wordt, moet dus een nieuwe technologie voor het laatste stuk van het traject worden ingezet om het transport van de AD-vlag te beveiligen.
Daarnaast biedt het DNS-protocol geen mogelijkheid om door te geven wat er precies is misgegaan als een DNSSEC-validatie mislukt is. Wordt validatie straks door de web-browser op de client uitgevoerd, dan kan deze de gebruiker ook een inhoudelijke foutmelding geven. Het lijkt er dan ook op dat validatie op de client in de toekomst de standaard gaat worden.
Waar is de AD-vlag dan wel te gebruiken?
De AD-vlag is wel te gebruiken op een netwerk waar de beveiliging van 'the last mile' gegarandeerd is. Denk dan aan bedrijfsnetwerken, campusnetwerken, en gesloten netwerken van internet-providers en mobiele operators. Daar kan DNSSEC-validatie samen met DNS-caching gecentraliseerd worden op de recursing DNS-servers. Niet voor niets worden DNSSEC records wel door de Google's Public DNS service gecached en opgehoest, maar wordt de AD-vlag nooit gezet. Zij kunnen het tussenliggende traject immers niet garanderen.
Daarnaast lijkt de rol van de AD-vlag in de nabije toekomst te worden uitgebreid: was deze tot nu toe alleen gedefinieerd voor DNS-antwoorden, inmiddels wordt ook gewerkt aan het gebruik van de AD-vlag in de DNS-vragen. In paragraaf 5.7 van deze Internet Draft kunnen we lezen dat voorheen geadviseerd werd de AD-vlag in DNS-verzoeken uit te zetten. Straks levert het aanzetten van de AD-vlag alleen informatie over de validatie op, middels de AD-vlag in het DNS-antwoord, maar niet meer de DNSSEC records zelf. De netwerk-tool dig ondersteund deze mogelijkheid inmiddels via de +adflag optie. De DO-vlag blijft gebruikt worden om de volledige DNSSEC records op te vragen.
