DNS alleen gegarandeerd veilig met DNSSEC-validatie op de client van de eindgebruiker
AD-vlag alleen te vertrouwen op gesloten netwerken
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 netwerken waar de beveiliging van 'The Last Mile' gegarandeerd is. Denk dan aan bedrijfsnetwerken, campusnetwerken, en gesloten access-netwerken van internetproviders en mobiele operators. Daar kan validatie samen met de caching van DNS-records gecentraliseerd worden op de recursing DNS-servers.
In alle andere gevallen raden wij aan om 'end-to-end'-validatie tot op de clients van de eindgebruikers uit te voeren. Eindgebruikers die een gegarandeerd veilige DNS-resolver willen, zullen daarvoor zelf de Unbound resolver of een andere validerende resolver moeten installeren. De installatie en configuratie van Unbound met DNSSEC-Trigger beschrijven we een ander artikel op deze website. Beheerders van kleinere netwerken kunnen dnsmasq inzetten, een gecombineerde DNS/DHCP-server die ook DNSSEC ondersteunt.
Waartoe dient de AD-vlag?
De AD-vlag (Authentic Data) 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. In zijn DNS-query vraagt de (stub-)resolver om validatie (en de RRSIG-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 de DNS-records ook de AD-vlag meesturen. 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 (RFC 4035, sectie 3.1.6) bepaalt dat autoritatieve nameservers geen validatie hoeven doen voor hun eigen domeinen. Zij mogen de AD-vlag dan wel zetten, maar alleen als zij hun autoritatieve records op een veilige manier hebben gekregen. Dat moet dan wel apart geconfigureerd worden.
Inmiddels is de rol van de AD-vlag uitgebreid: was deze voorheen alleen gedefinieerd voor DNS-responses, nu kan de AD-vlag ook worden gebruikt in DNS-query's. In RFC 6840, sectie 5.7, kunnen we lezen dat voorheen geadviseerd werd de AD-vlag in DNS-query's uit te zetten. Nu levert het aanzetten van de AD-vlag in de DNS-query alleen informatie over de uitkomst van de validatie op (middels de AD-vlag in de DNS-response), maar niet meer de RRSIG-records zelf. De netwerk-tool dig ondersteunt deze mogelijkheid inmiddels via de '+adflag'-optie. De DO-vlag blijft zoals voorheen gebruikt worden om ook de RRSIG-records op te vragen.
Wanneer kun je de AD-vlag vertrouwen?
Het crypto-technische antwoord luidt natuurlijk: nooit! Omdat het traject tussen de (stub-)resolver en (caching) DNS-server in het algemeen niet is beveiligd, kan de inhoud van de DNS-response via eenman-in-the-middle (MITM)-aanval altijd veranderd worden, zonder dat de client dat detecteert. Dat betekent dat de inhoud van de records en alle meta-data (de headers) in principe niet te vertrouwen zijn.
Hoewel het voor de handliggend (en efficiënt) is om de validatie van DNSSEC te combineren met het cachen van DNS-records, wordt daarbij wel de cryptografisch beveiligde DNSSEC-keten ingekort. In het ideale geval loopt deze immers van de root zone (.) helemaal tot aan het bijbehorende trust anchor op de client. Als ook de validatie op de caching 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.
Voor dit probleem van 'The Last Mile' waren eerder al verschillende oplossingen beschikbaar:
De uitwisseling van DNS-informatie kan beveiligd worden met TSIG (Transaction SIGnature). Dit protocol wordt vaak gebruikt om DNS-records tussen autoritatieve nameservers 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 voor de hand liggende 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-dienstverlener
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, djbdns en EdDSA. DNSCrypt wordt met name ondersteund door OpenDNS en is beschikbaar voor Windows, Linux, macOS 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.
Ondanks alle eerdere initiatieven en ideeën, is geen van deze technologieën uiteindelijk (structureel) ingezet om 'The Last Mile' te beveiligen. In plaats daarvan zijn de open standaarden DoT, DoH en DoQ nu dé manier om het transport van DNS-verkeer te beschermen. Deze standaarden zijn echter relatief nieuw en worden nu vooral gebruikt op applicatieniveau (in de webbrowsers).
Waar is de AD-vlag dan wel te gebruiken?
De AD-vlag is (zonder verdere bescherming) wel te gebruiken op een netwerk waar de beveiliging van 'The Last Mile' gegarandeerd is. Denk dan aan bedrijfsnetwerken, campusnetwerken, en gesloten access-netwerken van internetproviders en mobiele operators. Daar kan DNSSEC-validatie samen met DNS-caching gecentraliseerd worden op de recursing DNS-servers.