Debian 5.0 heeft de beschikking over BIND 9.5.1 en Debian Unstable heeft de beschikking over BIND 9.6.0 welke beide de mogelijkheid bieden om DNSSEC-validatie te gaan aan de hand van DLV. Met behulp van DLV is eigenlijk het probleem van chain-of-trust vanuit de root-zone “opgelost”. Door een derde partij te vertrouwen welke de DS-keys kan vertellen aan andere partijen wordt gevalideerde resolving mogelijk.

Een van de partijen die dit aanbiedt is ISC en is sinds BIND 9.4 te gebruiken, maar versie 9.5.1 of 9.6.0 (deze versie ondersteunt NSEC3-records) zijn aanbevolen. Gelukkig zijn er al toplevels zoals van Zweden en Brasilie welke als DNSSEC op ccTLD hebben ingevoed. Helaas heeft SIDN, de beheerder van de nl-zone, alleen een tijdelijk project gehad om DNSSEC te testen en hopelijk komt daar binnenkort verandering in met vorderingen van DRS4. Een andere toplevel welke een harde deadline heeft gekregen is het toplevel .gov welke onder de Verenigde Staten van Amerika valt. En alle overheidsinstellingen moeten met ingang van december 2009 voor zowel internet als intranet DNSSEC hebben ingevoerd. Op de dns-operations mailinglist werd ook aangekondigd dat per 1 mei 2009 .gov weer was opgenomen in dlv.isc.org zodat verificatie weer mogelijk werd. En tot nu toe lijkt deze actie redelijk probleemloos te gaan.

Sinds BIND op dit moment een van de weinige authoritive en resolving nameservers is die DNSSEC ondersteunt werd het weer tijd om te gaan testen. Helaas heeft Sun Solaris cq OpenSolaris nog geen bijgewerkte versie van BIND standaard meegeleverd en blijft alleen Debian voor mij over op dit moment. Een (virtuele) machine met Debian 5.0 met daarop BIND 9.5.1 of hoger en een werkende NTP-server zijn voorlopig voldoende om DNSSEC te gaan testen voor een resolving nameserver. Als de volgende aanpassingen worden gemaakt aan /etc/bind/named.conf.options:

trusted-keys {
dlv.isc.org. 257 3 5 "BEAAA...rBNh";
};
options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside . trust-anchor dlv.isc.org.;
};
logging {
channel dnssec_log {
file "/var/log/named/dnssec" size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 3;
};
category "dnssec" { "dnssec_log"; };
};

In het voorbeeld staat geen valide key om veiligheidsredenen en de key kan worden opgehaald bij ISC en het is verstandig om de sleutel te controleren met PGP voordat deze wordt toegevoegd. Dit is een kritiek punt in de vertrouwens relatie en door een foutieve key te importeren wordt ook de vertrouwensrelatie met de rest van de wereld beïnvloed.

Standaard is er geen directory voor logfiles van BIND binnen Debian aanwezig en met de eerste twee volgende commando’s wordt er een directory aangemaakt en de permissies goed gezet. Het commando erna zal BIND volledig opnieuw starten zodat alle instellingen worden geactiveerd en zal DNSSEC moeten werken.

sudo mkdir -m 0700 /var/log/named
sudo chown bind /var/log/named
sudo /etc/init.d/bind9 restart

Het onderstaande commando kan worden gebruikt om aan te tonen dat DNSSEC nu wordt gebruikt voor validatie. Bij de flags staat nu ook de flag ad (Authentic Data) welke alleen wordt gezet als er met behulp van DNSSEC en DLV een validatie is gedaan.

$ dig +dnssec -t any br. @127.0.0.1
; < <>> DiG 9.5.1-P2 < <>> +dnssec -t any br. @127.0.0.1
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 33043
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 7, ADDITIONAL: 1

Het is misschien onnodig om te vermelden, maar DNSSEC is geen oplossing om even te testen, neer te zetten en daarna te vergeten. De komende jaren zullen veel problemen ontstaan welke in het verleden stilletjes zijn ontstaan door slecht ontworpen infrastructuur en infrastructuur welke slecht of geen beheer heeft. En mijn persoonlijk vermoede is dat hier vooral e-mail hinder van gaat ondervinden, maar dat is iets wat tijd ons zal leren en hopelijk heb ik ongelijk.