US government mandates? use of DNSSEC by federal agencies
oberman at es.net
Wed Aug 27 12:35:03 CDT 2008
> Date: Wed, 27 Aug 2008 19:25:03 +0200
> From: Jeroen Massar <jeroen at unfix.org>
> Steven M. Bellovin wrote:
> > On Wed, 27 Aug 2008 09:53:26 -0700
> > "Kevin Oberman" <oberman at 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 at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 224 bytes
Desc: not available
More information about the NANOG