DNSSEC: DNS Secutity Extensions
May 3, 2006 § Leave a comment
Somewhat off-topic, but I’ve recently been doing
some research on DNSSEC (aka Secure DNS). I was quite surprised
to discover that the current RFCs about this were
only published last March, so it is a relatively recent development (not
counting the earlier, un-implementable versions
:-).
some research on DNSSEC (aka Secure DNS). I was quite surprised
to discover that the current RFCs about this were
only published last March, so it is a relatively recent development (not
counting the earlier, un-implementable versions
:-).
[Read more] for a list of
interesting resources I’ve discovered about DNSSEC and
SIG(0).
The current RFCs, primarily published in March 2005:
?
RFC
2931: DNS Request and
Transaction Signatures ( SIG(0)s
)
RFC
2931: DNS Request and
Transaction Signatures ( SIG(0)s
)
DNSSEC Overview (pdf) from
DE-CIX 3rd Technical
Workshop (16 Sep 2005, Holger
Zuleger)
DNSSEC HOWTO (pdf) Olaf Kolkman, April
2005
Basics of
DNSSEC (ONLamp.com, by Ibrahim Haddad and David Gordon, 10/14/2004
— slightly out of date)
DNSSEC solves many of the worst DNS security
problems. It uses generally known technology and is backwards-compatible with
the existing DNS infrastructure. It is completely transparent to the user
population and downstream administrators if they choose not to implement the
extensions. While it does require installation of BIND 9 [9.3 — ed.] or later,
you should upgrade to BIND 9 for many other beneficial reasons.
problems. It uses generally known technology and is backwards-compatible with
the existing DNS infrastructure. It is completely transparent to the user
population and downstream administrators if they choose not to implement the
extensions. While it does require installation of BIND 9 [9.3 — ed.] or later,
you should upgrade to BIND 9 for many other beneficial reasons.
Secure
dynamic DNS howto (by IETF Ops, 2002/03/17)
dynamic DNS howto (by IETF Ops, 2002/03/17)
Dynamic update of a zone and DNSSEC signing
of a zone are orthogonal concepts. However, since both require modern software
and both require key management the additional cost of full DNSSEC for such a
zone becomes marginal and is therefore a good
idea.
BIND 9.3.0s20020122 (9.3.0
snapshot) or newer required for SIG(0)?Note: BIND has to be compiled with
OpenSSL (built using the ‘–with-openssl’ configure option) if you want to use
DNSSEC features such as SIG(0) or a signed zone.
of a zone are orthogonal concepts. However, since both require modern software
and both require key management the additional cost of full DNSSEC for such a
zone becomes marginal and is therefore a good
idea.
BIND 9.3.0s20020122 (9.3.0
snapshot) or newer required for SIG(0)?Note: BIND has to be compiled with
OpenSSL (built using the ‘–with-openssl’ configure option) if you want to use
DNSSEC features such as SIG(0) or a signed zone.
Differences Between TSIG and SIG(0) (RFC
2931)
2931)
There are significant differences between
TSIG and SIG(0). Because TSIG involves secret keys installed at both the
requester and server the presence of such a key implies that the other party
understands TSIG and very likely has the same key installed… SIG(0) on the
other hand, uses public key authentication, where the public keys are stored in
DNS as KEY RRs and a private key is stored at the signer. Existence of such a
KEY RR does not necessarily imply implementation of SIG(0)…. For these
reasons, SIG(0)s SHOULD only be used on requests when necessary to authenticate
that the requester has some required privilege or identity.
TSIG and SIG(0). Because TSIG involves secret keys installed at both the
requester and server the presence of such a key implies that the other party
understands TSIG and very likely has the same key installed… SIG(0) on the
other hand, uses public key authentication, where the public keys are stored in
DNS as KEY RRs and a private key is stored at the signer. Existence of such a
KEY RR does not necessarily imply implementation of SIG(0)…. For these
reasons, SIG(0)s SHOULD only be used on requests when necessary to authenticate
that the requester has some required privilege or identity.
iHack, therefore iBlog 
Leave a Reply