[dns-operations] .Org DNSSEC key management policy feedback
marka at isc.org
Mon Jun 22 23:39:34 UTC 2009
In message <1D337EA2-A581-47CE-98AA-E95754465293 at dnss.ec>, Roy Arends writes:
> On Jun 23, 2009, at 3:11 AM, Andrew Sullivan wrote:
> > On Sun, Jun 21, 2009 at 03:24:20PM +0000, bmanning at vacation.karoshi.com
> > wrote:
> >> On Sun, Jun 21, 2009 at 07:50:47AM -0700, David Conrad wrote:
> >>> Yes, but until the root is signed, people will still need to update
> >>> their trust anchors to reflect all the islands of trust, including
> >>> the
> >>> TLDs, they want to validated.
> >> even then, they might want to keep the .ORG key
> > I'm rather hoping not. Given the way BIND prefers the "closest"
> > configured trust anchor, I think it will make things less reliable.
> > Suppose people decide to keep their existing .org key, and then the
> > root is signed, and the key-keepers think, "Good," and stop checking
> > for updates. On the next .org key-roll, all of .org instantly goes
> > dark for those people with the stale key.
> That still hasn't been fixed? It seems wrong and very annoying. In my
> end user experience, it violates the principle of least astonishment.
Actually it doesn't. If you configure a trust-anchor for
your own company you don't want anything overriding it.
Having that overridden would be POLA violation.
Having things break because you stopped managing/tracking
them is not a POLA violation.
> I remember the main counter argument was that folks might want to
> configure the .ORG key for everything in and under .ORG, and not trust
> the root key for .ORG, but do trust the root key for everything else.
> Doesn't fly. There might be simple dependencies from domains under ORG
> on something not ORG. See for instance http://www.links.org/?p=635 on
> "who pwns the internet".
For . and ORG I agree. For ORG and ISC.ORG I disagree.
For wattle.id.au (when it is signed) and andrews.wattlet.id.au
I disagree. There are couple of hundred zones where your
policy makes sense. There are millions where named's default
policy will make sense.
Your policy model make sense if you *start* doing DNSSEC
during the bottom up development phase. If you start in
the top down phase it doesn't and top down is the long term
> kind regards,
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations