
Kom, lad os lege med DNSSEC
Med udbudet om administrationen af .dk stort set vundet, har DIFO og DK-Hostmaster ikke længere nogen undskyldning for at trække udviklingen af .dk i langdrag. Vi vil se en udviklingsplan der indeholder mere end advokattiltag - DNSSEC står højt på listen.
Det vil kræve noget erfaring af få udbytte af DNSSEC. Men hvorfor vente på DIFO, allerede i dag kan vi begynde at lege med DNSSEC.
Vi skal selvfølgelig bruge et domæne. Hos GratisDNS har jeg domænet hacking.dk. Det er let at tilføje nogle NS-records for dnssec.hacking.dk, som peger på min til lejligheden opsatte nameserver. Det bliver så vores legedomæne.
Dernæst sætter vi en helt standard bind op som nameserver og husker at sætte optionen "dnssec-enable" samt tilføjer en lille zone og tester at det virker. (Her brugte jeg så et par timer på at fejlfinde. NS records må ikke pege på et domæne der har et CNAME istedet for A eller AAAA records. 'dig +trace' brokker sig ikke, men rekursive resolvere gør...)
Min minimale zone ser således ud:
; ; Zone file for dnssec.hacking.dk ; $TTL 900 @ IN SOA ns.hacking.dk. peter.makholm.net. ( 2009021115 ; Serial 900 ; Refresh 86400 ; Retry 2419200 ; Expire 900 ) ; Negative Cache TTL ; @ IN NS ns.hacking.dk. @ IN A 72.14.181.177 @ IN AAAA 2001:470:1f0f:2ce::1
@ IN TXT "This is an DNSSEC test zone"
Og nu begynder det at lugte at DNSSEC: Vi skal have genereret nogle nøgler. For at lette udskiftning af nøgler er det smart at lave to nøgler, en 'key signing key' og en 'zone signing key'. Den første skal leve i lang tid og bliver skiftet manuelt og den anden kan leve i kort tid og udskiftes mere automatisk.
Begge nøgler genereres med kommandoen 'dnssec-keygen'. For hver nøgle laver 'dnssec-keygen' to filer. Den ene er den offentlige del af nøglen og kan inkluderes direkte i zonefilen og den anden er den private del af nøglen. Vi tilføjer følgende til vores zonefil:
$include Kdnssec.hacking.dk.+005+48210.key $include Kdnssec.hacking.dk.+005+58564.key
De to tal i hvert filnavn er henholdsvis algoritmen nøglen anvendes med (5 er RSA/SHA1) og nøglens id). Med nøglerne genereret og indsat i zonefilen som zonefilen signeres. Det gøres med kommandoen 'dnssec-signzone'. Den laver en ny zonefil med endelsen '.signed' og denne sætter man så bind til at bruge som zonefil. Den signerede zonefil fylder i mit tilfælde lidt over 4k.
Og værsgod, så har du DNSSEC!
Meeen, for at bruge det skal man lige fortælle sin dns-resolver at man nu stoler på de nøgler man lige har lavet. Bruger man bind kan man gøre dette ved at indsøtte noget ala følgende i sin named.conf:
trusted-keys { "dnssec.hacking.dk." 257 3 5 "AwEAAd2GFLZcYCFgkShttQANZrXY5MMO+Bm+ 29NUFu3zPKO3Dsb+EV1pmgLmpeosUVaXKP0y cbJu4cUwveEC/21s1/xfaAVWoYeVNDPWmvyJ 1GYaGRpVVpakzOz5Sg5Yno7BeCkDm+j1Xk/E lTPSmJgUJeVbWLUw2PXtOU7t7V4mQ9Ah"; };
Det er stort set indholdet af en af .key-filerne hvor man har fjernet 'IN DNSKEY'. Det Rigtige(tm) er vist at vælge den nøgle det første tal er ulige - det er ens 'key signing key'.
Men det rigtig sjove kommer først når vi laver subdelegeringer og laver kæder af nøgler. Lad os oprette domænet gdns.dnssec.hacking.dk hos GratisDNS. På administrationssiden er der en knap der hedder DNSSEC der gør alt det besværlige. Så skal man hente nøglen for gdns.dnssec.hacking.dk og konvertere den til en delegation signature (DS-record). Det gør man lettest med værktøjerne ldns-keyfetcher og ldns-key2ds fra ldns-pakken. Dette genererer så nogle .ds filer der er ligetil at inkludere i zonen for dnssec.hacking.dk - og husk at gensignere zonefilen igen.
Dette er kun en kort smagsprøve. Følg DNSSEC howto'en fra NLnet Labs. Et par andre hints:
- 'dig +multi' viser lidt ekstra informationer om DNS records
- 'drill' fra ldns-pakken er god at teste med
- Der er en [drill firefox-extension](http://www.nlnetlabs.nl/projects/drill/drill_extension.html). Men læs lige forebeholdene.
Kommentarer (7)
> NS records må ikke pege på et domæne der har et CNAME istedet for A eller AAAA records.
Jeg tror ikke at jeg forstod denne. Hvad var det du havde gjort forkert?
Hvad Robert skrev. Jeg havde brugt noget ala:
ns.hacking.dk. IN CNAME vps1.hacking.dk
dnssec.hacking.dk. IN NS ns.hacking.dk
Det fik de fleste rekursive nameservere til at brække sig med en SERVFAIL. Men en 'dig +trace dnssec.hacking.dk' beklagede sig ikke og en velkendt åben rekursiv nameserver brokkede sig heller ikke (jeg antog at det var et caching issue).
Men det er et sidespor og egentlig ikke relevant.
Hvad sker der når ISP'erne laver de DNS omregistreringer de allerede har lavet for Red Barnets filter og APG om thepiratebay?
Kan nøglen stadig passe?
Målet med DNSSEC er at verificere korrektheden af resultatet af et DNS-opslag og ISP'erne vil ganske indlysende ikke kunne levere et korrekt resultat.
Jeg er ikke helt sikker på om DNSSEC standarden beskriver hvad der bør ske, men jeg formoder at det vil svare lidt til forkerte SSL-certifikater. Browseren vil brokke sig, men give mulighed for at surfe videre.
Men DNSSEC vil på ingen måde forhindre tredjepart i et pille i DNS-pakker, det sikrer os kun at vi opdager det. Eventuelt vil det give en mere obskur fejlmeddelse end hvad folk får idag. Altså et lille skridt tilbage i de konkrete sager.
Det er nemlig det der gør DNSsec interessant.
Det øjeblik thepiratebay.org o.l. begynder at DNSsec signere, kan der ske en af flere ting.
Afhængig af hvordan ISPs DNS forwarding arkitektur er skruet sammen:
- forwarders slår the thepiratebay.org op, finder en local hijack, og kunden bliver videresendt til ISPs info side
- forwarders checker først .org delegation for thepiratebay, men der mangler DNSsec validering på local hijack, SERVFAIL returneres til kundens stub resolver, han ringer til helpdesk "det virker ikke".
Etc...
Tons of fun in perspective.
Ja, det var lige præcis det jeg tænkte. Lad os se at komme i gang

