Gecentraliseerde DNSSEC-validatie op gesloten netwerken

31 oktober 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.

Waartoe dient de AD-vlag?

De AD-vlag (Authentic Data) wordt gebruikt door (caching) 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 de DNS-records ook de AD-vlag terugsturen. 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, paragraaf 3.1.6) bepaalt dat autoritatieve servers 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-antwoorden, nu kan de AD-vlag ook worden gebruikt in DNS-vragen. In paragraaf 5.7 van RFC 6840 kunnen we lezen dat voorheen geadviseerd werd de AD-vlag in DNS-verzoeken uit te zetten. Nu levert het aan zetten van de AD-vlag in de DNS-vraag alleen informatie over de uitkomst van de validatie op (middels de AD-vlag in het DNS-antwoord), maar niet meer de DNSSEC records zelf. De netwerk-tool dig ondersteunt deze mogelijkheid inmiddels via de +adflag optie. De DO-vlag blijft zoals voorheen gebruikt worden om DNSSEC-informatie 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 het DNS-antwoord via een man-in-the-middle 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.

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 autoritatieve 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 (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 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.

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.

Reacties

  • vrijdag 20 juli 2018

    Veilig internet

    Op een nieuwe manier inloggen bij je bank? Wees alert!

    Thumb-Rabobank

    Cybercriminelen spelen in op introducties van nieuwe tools en diensten

    Lees meer
  • dinsdag 18 juni 2019

    Over SIDN

    Ontmoet SIDN op de KvK Startersdag in Utrecht

    KVK Startersdag

    Zaterdag 22 juni van 10.00 - 16.00 uur

    Lees meer
  • dinsdag 5 december 2017

    Veilig internet

    Online advertenties steeds vaker ingezet door internetcriminelen

    Thumb-hacker

    Bezoekers worden misleid met een valse domeinnaam

    Lees meer

Sorry

De versie van de browser die je gebruikt is verouderd en wordt niet ondersteund.
Upgrade je browser om de website optimaal te gebruiken.