nanog mailing list archives

Re: US government mandates? use of DNSSEC by federal agencies


From: "Kevin Oberman" <oberman () es net>
Date: Wed, 27 Aug 2008 10:35:03 -0700

Date: Wed, 27 Aug 2008 19:25:03 +0200
From: Jeroen Massar <jeroen () unfix org>

Steven M. Bellovin wrote:
On Wed, 27 Aug 2008 09:53:26 -0700
"Kevin Oberman" <oberman () es net> wrote:

So the question I have is... will operators (ISP, etc) turn on
DNSsec checking? Or a more basic question of whether you even
_could_ turn on checking if you were so inclined?
As far as I can see, at least with bind-9.5, operators would have to
turn it off. It looks to me like dnssec-validation defaults to on. It
also appears that bind-9.4 defaults to 'off'. 

Right.  The real questions are the clients and the trust anchor -- what
root key do you support?

A distributed one. I personally don't really see an issue with
downloading a public key for every TLD out there. These keys could come
in a pack even by an OS distribution, nicely PGP signed et all...
Nobody in his right mind manages this per box anymore anyway, and
packages for distributions and auto-updates are well-present anyway.

The presence of a key file can also mean to the resolver that one
can/has_to check dnssec results.

How do you propose to establish the initial trust for these keys?

How will they be updated? NIST recommends rolling the zone keys
every month and the key signing key annually. Files in distributions are
way too static for these intervals. (I think NIST's recommendations are
extremely excessive, but I am required to comply with them or explain to
OMB why not.)

This is the reason for the DLV concept and it will be needed (in some
form) at least until the root is signed and most likely until .com and
.net are signed.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman () es net                       Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Attachment: _bin
Description:


Current thread: