DNSSEC (was Re: Bind source code question )

[Jim Reid]

>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    Kevin> Perhaps a better question is: will DNSSEC ever be
    Kevin> implemented by ICANN or one of its delegees?

IIUC some of the European ccTLDs plan to deploy DNSSEC next year. The
Dutch, German and Swedish NICs have been working on this for a while
and have been co-operating with each other: comparing notes, working
out signing procedures and key administration processes etc, etc.
FWIW, nl.nl is a DNSSEC-signed version of the complete nl zone. Some
information about these activities and related experiments is
available at http://open.nlnetlabs.nl/dnssec and http://www.sigz.net.
There might be a report on the last month's DNSSEC workshop at RIPE on
their website at http://www.ripe.net.

Deploying DNSSEC for .com (in particular) introduces a whole new set
of problems. One is the size of the zone file because of the SIG and
NXT records that need to be added. The zone will be about 3 times as
big as it is at present because signing means each existing name in
the zone will get a SIG and NXT record. Another is the sheer number of
lame delegations. DNSSEC requires close co-operation between parent
and child zone administrators. There are too many clueless people who
can't even keep their zone's NS records and any glue in .com
right. Expecting them to properly manage DNSSEC keys (and get them
re-signed periodically) is unrealistic. And then there's the question
about who signs the keys of customers of other .com registrars. Would
register.com (say) want their customers to have their keys signed by
Network Solutions? Would NSI want to (have to) sign those keys?

There are other problems too. These apply to any signed zone and
DNSSEC-aware name server: like not breaking DNS implementations that
might choke on DNSSEC RR types that could be returned by DNSSEC-aware
name servers. And potentially lots of TCP queries as a result of UDP
answers getting truncated because all the crypto gunk in a signed
answer is too big to fit in a regular 512-byte DNS packet. For a busy
name server, this will be rather unpleasant.