crypto-validated?

[Jim Reid]

>>>>> "fred" == fred pasteck <fred_pasteck at yahoo.com> writes:

    >> The AD bit should only be set if the server sending the answer
    >> is DNSSEC-aware and has validated the cryptographic
    >> signature(s) on the resource record(s) in the answer. DNSSEC -
    >> Secure

    fred> How does it validate the remote box if it doesn't already
    fred> have some type of identification such as a key?

It's not the remote box that is validated per se, but the zone's NS
record(s) and any relevant A records. In DNSSEC, each resource record
in a zone is signed by a corresponding SIG record. This contains
details of how long the signature is valid and the record's
signature. Each SIG record also contains the name of a KEY record:
the public key for the private key that created the signature. There's
other stuff in each SIG record too, but that's not important here. The
KEY records are also in the DNS, hopefully in DNSSEC-signed zones!

In theory, the parent zone signs the delegations for its DNSSEC aware
child zones and the child's key(s). This procedure is supposed to
iterate until a signed root zone is reached. However there are awkward
problems signing big zones like .com. And signing the root zone
introduces another set of problems: imagine if the root key(s) got
compromised.

    >> lookup. Strong hash algorithms like SHA or MD5 allied to
    >> public-key cryptography are used to implement DNSSEC. Some of

    fred> Ah, so there is no key, just a hash?

A strong hash is generated for each resource record after it is put
into canonical form. The hash is then signed with the private key or
keys to produce SIG records => a signed version of the zone file. This
is done off-line by dnssec-signzone and friends in BIND9.

    fred> Are there specific options that must be configured to enable
    fred> DNSSEC?

There are no options as such, but there's a lot of work. The zones
have to be signed, keys have to be generated and managed, the parent
should sign the child zone's key(s), etc, etc. In some cases, key{},
server{} and trusted-key{} statements might need to be added to
named.conf. The BIND9 Administrator's Reference Manual and man pages
explain what needs to be done. There's also an excellent article on
setting up DNSSEC in the November 2000 issue of ;login, the USENIX
association newsletter. That would be a good starting point if you're
looking for more information.

The folks at NLnetlabs have been experimenting with a signed version
of the .nl zone: nl.nl. [The .se and .de zones are also taking part in
these trials. Some of the European TLDs plan to use DNSSEC for real
next year if the tests work out.] Info on what NLnetlabs have been
doing can be found at: http://www.nlnetlabs.nl/dnssec.