DNS Security Extensions
Tekniken bakom DNSSEC
Med DNSSEC signeras viktiga domäner. Den DNS server som ställer en
fråga till en signerad domän kan med domänens publika nyckel
verifiera att exempelvis en adresspost är korrekt. Den digitala
signaturen används för att verifiera att adressposten är äkta och
inte förändrad.
Vid användning av asymmetrisk kryptering (privat-publik
kryptering) är svagheten att kunna garantera att den publika
nyckeln verkligen är den publika nyckel som den utger sig för att
vara. En falsk domän, med falska signaturer och en falsk publik
nyckel, kan resultera i ett korrekt DNS svar. För att garantera
äktheten av den publika nyckel för en domän, så kan den exempelvis
signeras av den överliggande domänen.
Exempelvis så signeras den publika nyckeln för domänen
labb.certezza.net av domänen certezza.net. Den publika nyckeln för
certezza.net signeras av net som i sin tur signerats av
root-servrarna. Root-servrarnas publika nycklar är givna på
förhand, på samma sätt som deras IP-adresser. Denna verifiering
kallas för "walking the chain of trust".
Publika nycklar kan också signeras av någon annan part som man har
förtroende för.
DNSSEC innebär nya poster i zonfilen
För att bland annat möjliggöra distribution av publika nycklar och
signering av befintliga DNS-poster, så har ett antal nya posttyper
(resource record )skapats.
KEY används för att beskriva publika nycklar. Posten innehåller
information om vilket protokoll som avses (DNSSEC, Oakley/IPSEC
etc), vilken algoritm som avses (RSA/MD5, Diffie-Hellman, DSA etc)
samt värdet för den publika nyckeln.
SIG används för att beskriva signaturer. Posten innehåller bland
annat information som beskriver vad som signerats, signaturens
giltighetstid, vem som utfört signeringen samt själva
signaturen.
NXT (non exist) använd för att beskriva DNS-poster som inte
existerar. Detta för att undvika en svaghet som annars skulle
finnas i DNSEC. Tanken med NXT posten är att generera ett svar även
om man frågar efter en post som inte finns.
Efter att ha studerat detta närmare i detalj, som inser man att
zonfilerna kommer att växa radikalt. De kommer att vara långt mer
komplexa än dagens zonfiler. Detta kommer att ställa större krav på
bandbredd och DNS kunnande. Det förstnämnda är troligen inte något
problem sett i ett längre perspektiv, men det sistnämnda är redan
idag en bristvara. Det finnas visserligen verktyg för att signera
zonfiler och förse dessa med lämpliga KEY, SIG och NXT poster. Det
utesluter dock inte att de som hanterar DNS måste förstå även dessa
delar.
DNSSEC ställer nya krav på DNS servers
Inom ramen för RFC2535 så har ett antal kriterier satts upp för
vad en DNS server skall klara för att vara DNSSEC-compliant. För
att undvika missförstånd har jag valt att inte översätta
dessa.
A full server compliance:
- ability to read SIG, KEY, and NXT RRs in zone
files
- ability, given a zone file and private key, to add
appropriate SIG and NXT RRs, possibly via a separate
application
- proper automatic inclusion of SIG, KEY, and NXT RRs in
responses
- suppression of CNAME following on retrieval of the
security type RRs
- recognize the CD query header bit and set the AD query
header bit, as appropriate
A fully compliant resolver:
- understands KEY, SIG, and NXT RRs including verification
of SIGs at least for the mandatory algorithm
- maintains appropriate information in its local caches and
database to indicate which RRs have been authenticated and to what
extent they have been authenticated
- performs additional queries as necessary to attempt to
obtain KEY, SIG, or NXT RRs when needed
- normally sets the CD query header bit on its
queries
DNSSEC - Mer information
RFC2535 DNS Security Extension
RFC2536 DSA KEYs and SIGs in the DNS
RFC2537 RSA/MD5 KEYs and SIGs in the DNS
RFC2538 Storing Certificates in the DNS
RFC2539 Storage of Diffie-Hellman Keys in the DNS
RFC2540 Detached DNS Information
RFC2541 DNS Security Operational Considerations
Draft Simple Secure DNS Dynamic Update
© 1999 Thomas Nilsson, Certezza AB
