De tijd is dus gekomen om te kijken om van DLV af te gaan stappen en kijken of de resolving correct blijft werken. De tijd is dus ook gekomen dat SIDN binnenkort DNSSEC gaat ondersteunen, want de belofte was om dit een maand na de root-zone te gaan ondersteunen.

Helaas werken sommige oplossingen niet correct zoals de resolver in de Fritz!Box. Bij het opvragen van de nameservers van de root-zone met het verzoek om DNSSEC te gebruiken besluit de firmware om op slot te gaan voor een paar minuten. Er is een bugreport naar AVM gegaan en hopelijk komt er binnenkort een update.

De vraag die ook al bij IPv6 kwam is hoe lang het nog gaat duren voordat het mainstream gebruikt kan worden. Want veel verouderde oplossingen worden nog steeds verkocht en zolang is het nog niet geleden dat oa SpeedTouch-modems alleen maar A en CNAME records konden verwerken.

In een logfile staat de volgende melding en wat er uit is op te maken is dat de nameserver op IP-adres 70.84.207.245 de verbinding niet aanneemt. Ook is af te lezen dat er een verzoek wordt gedaan voor de nameserver records voor domein cordaidke.org.

Feb 1 22:35:43 ns-cache2 named[9352]: connection refused resolving 'cordaidke.org/NS/IN': 70.84.207.245#53

Dus laten we beginnen om te kijken waar dingen fout gaan. De eerste stap is om te kijken of alle nameservers goed werken, zodat we deze kunnen gaan gebruiken bij het onderzoek. De nameserver records voor een domein komen ook uit de bovenliggende zone in de vorm van glue records. Er is dus altijd achter te komen wat de officiële nameserver records zijn.

$ dig +short cordaidke.org ns
dns1.thebook.com.
dns2.thebook.com.

Nu duidelijk is welke officiële nameservers er zijn bevragen we eerst dns1.thebook.com of deze op de hoogte is van de nameserver records voor domein cordaidke.org. Hiervoor komt net hetzelfde antwoord als ook via de org-zone is verkregen mbv de glue records. Nu we hetzelfde doen met dns2.thebook.com dan krijgen we helaas geen antwoord, maar wel een bevestiging dat de nameserver niet kon worden bereikt.

$ dig +short cordaidke.org ns @dns1.thebook.com.
dns2.thebook.com.
dns1.thebook.com.
$ dig +short cordaidke.org ns @dns2.thebook.com.
;; connection timed out; no servers could be reached

Sommige mensen op deze wereld plaatsen RFC1918 adressen in DNS om zo een soort splitbrain/view te bouwen voor hun DNS-infra. En het mag duidelijk zijn waarom RFC1918 adressen nooit gerouteerd zullen worden op Internet. Een snelle controle laat dan ook zien dat het geldig IP-adres lijkt, maar bij het kijken of de machine ook daadwerkelijk reageert levert een negatief beeld op.

$ dig +short dns2.thebook.com a
70.84.207.245
$ ping -c 4 dns2.thebook.com
PING dns2.thebook.com (70.84.207.245) 56(84) bytes of data.

--- dns2.thebook.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3023ms

De reden waarom geen verbinding kan worden gezocht kunnen er vele zijn, maar om uit te sluiten dat het aan je huidige verbinding ligt is het verstandig om vanaf een andere locatie ook een soort gelijke test uit te voeren. Bij dit incident lijken er routering problemen te zijn in het netwerk van The Planet, maar mocht het aanblijven dan kan het verstandig zijn om contact op te nemen met de tech-c van de betreffende zone.

De volgende stap die recentelijk is ingezet is om zonefiles structureel op fouten te controleren. Door zones beter en strikter te gaan controleren zouden deze zometeen minder problemen moet geven als deze gesigned moeten worden. De checks die BIND uitvoert gaan dus stelselmatig van warn naar fail, om zo RFCs beter na te leven. Een MX-record die naar een CNAME verwijst zou dus niet meer bij de signer uit moeten komen bijvoorbeeld.

Hiermee komt ook het genereren van de sleutels in beeld, maar ook de key rollover en het periodiek ondertekenen van zones. Er staat de komende tijd nog voldoende op de agenda en ook om over te schrijven.

Maar eerst over het probleem zelf en ja het is een probleem. Het is misschien ook wel iets waar Bert Hubert van PowerDNS naar hinten tijdens Hacking at Random. Er zitten nog veel fouten in de resolvers die moeten worden opgelost en dit bleek ook tijdens een test in Zweden met DNSSEC waarbij veel thuisrouters omvielen terwijl ze hoorden te blijven werken. Het onderstaande dus met zorg gebruiken.

$ dig vu4juskpieril.dns.grc.com.

;; Query time: 2597 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Sun Dec 20 11:27:02 2009
;; MSG SIZE rcvd: 295

Er wordt een vraag uitgezet bij resolver en deze moet bijna oneindig bezig blijven om met een antwoord te komen. Of de resolver blijft “eeuwig” bezig, of stopt met werken door een gebrek aan geheugen bv, of omdat het niet op te lossen en geeft een timeout, of geeft alleen het eerst antwoord. Voorlopig lijken BIND en PowerDNS goed te werken en ook de firmware voor routers van AVM aka Fritz!Box.

Als je mensen wilt pesten dan is de bekende 1×1 pixel image in je e-mail, webpagina, etc wel een aardige optie. Zeker omdat dan ineens veel software alles moet gaan werken zoals virusscanner, spamfilters, contentfilters, etc, etc. Hier ligt ook een groot probleem en waarom ik geen voorstander ben van dit soort toepassingen. Het maakt het probleem eigenlijk veel groter dan het eigenlijk is, want vaak zijn die applicaties even slecht geschreven of maken gebruik van dezelfde bibliotheken als normale applicaties.

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.

Aangezien DNSSEC ondersteuning bij PowerDNS en NSD beperkt is blijft voorlopig alleen Bind over als bruikbare optie aangezien het wel crossplatform moet werken. Bind is en blijft de defacto-standaard op bijna elke Unix-platform zoals HP-UX, Solaris, AIX, BSD en vele Linux-distributies. Ook omdat dit de referentie implementatie is van bijna elke RFC gerelateerd aan DNS.

Een eerste probleem dook al op bij de eerste testen, want goede entropy gaat een probleem vormen. De normale pseudogenerator voor deze getallen is blocking totdat er weer voldoende random getallen zijn, maar helaas kan het dus even deuren voordat er onvoorspelbare sleutels zijn. Een alternatief is om de non-blocking pseudogenerator te gebruiken welke vrij snel getallen kan opleveren, maar deze kunnen voorspelbaar zijn door hergebruik van oude getallen. Als dit laatste gebeurt zijn we weer terug af bij waar we begonnen zijn met de huidige DNS-problemen.

Voor deze problemen zal een oplossing moeten worden gezocht welke hoogstwaarschijnlijk in de vorm van hardware zal gaan zijn om aan de vraag van willekeurige getallen te kunnen voldoen. De eerste apparaten die lijken te voldoen zijn ongeveer 100 euro per stuk wat een redelijke prijs is. Nu wordt het uitzoeken of deze worden ondersteunt onder oa Linux en Solaris, maar hopelijk zijn er andere oplossingen zeker nu het kernel cryptographic framework vormt heeft gekregen in Solaris 10.