At 12:03 -0700 9/10/09, David Conrad wrote:
On Sep 8, 2009, at 1:19 PM, Edward Lewis wrote:
Correct me if I'm wrong, but the architecture of DNSSEC assumed (rightly or
wrongly) a single hierarchical deployment model.
Ok, if I must. DNSSEC does not assume a single hierarchical deployment
model. [...] but it was not until RFC 3008 that the recommendation was made
to have the authorization to sign data follow the tree.)
Are you saying that 3008 has been deprecated? If so, why the big stink about
signing the root?
How did you draw the conclusion that RFC 3008 was deprecated? It has
been obsoleted by DNSSEC III (RFC 4033-4035). What is said above is
"the architecture of DNSSEC assumed a single ... model" is a false
statement.
ISC has now thrown a non-hierarchical component to deployment, DLV, into
the mix.
ISC has exercised the principle of "local policy overrides" all.
Yep. If you decide to shoot yourself in the head, that's up to you.
What I object to is tying the ability of zone managers to roll a key to
you putting the gun to your temple.
Again, you are jumping to conclusions. DLV is well within the
original concept for DNSSEC. Whether or not there are operational
issues with the implementation.
DLV is perfectly within the heart of the soul of DNSSEC.
Heart and soul? Seriously? Then perhaps it shouldn't be informational and
the implementation should conform to the spec (or vice versa).
Yes, seriously. Don't let paperwork get in front of code, i.e., it
probably should be better documented, but that's not the bottleneck
here.
DLV is a bletcherous hack that should not exist and I publicly apologize to
the world for mentioning its predecessor to Paul. Mea culpa. Of course, one
of the reasons I dropped it was that after thinking about it, I realized
that it wouldn't scale and had stunningly bad operational and deployment
characteristics if it ever gained any sort of following.
That may also be true. In as much as the single hierarchical model
didn't appear "until" RFC 3008, it did appear for a reason. The
reason was that trying to have a general purpose authorization model
proved to be too onerous for the three of us writing code then and we
"punted it for future generations."
If you want DLV to be a long-standing component of the DNS infrastructure,
I'd suggest:
- get the RFC out of informational and into standards track
- get somebody to implement the RFC (or, alternatively, document what has
been implemented)
- figure out some way of propagating changes to potentially numerous
unrelated DLV registries
Again jumping to conclusions. 1) DLV fits the original concept. 2)
The updated concept set that aside. 3) What we have today has
exhibited operational problems.
At this point you can throw it out or work on it to make it better.
That's not my call, but, at NANOG in Philly, one operator of a
recursive server expressed a desire to have someone to rely upon for
trust anchor management.
Still, what it is attempting to do is within limits.
And within the limits of local policy, that's fine. What is simply broken
is having that local policy have global impact.
The local policy of "trusting DLV" is not having a global impact,
just a local impact on the parties relying on the cache with that
policy.
What would impress me is a proposal to sign the root zone that included a
real good look at the provisioning interface as well as an OT&E. For
instance, promise me a response to a DS change in a matter of hours or
minutes, not a day.
Did you provide these comments to NTIA? Have you provided comments to
IANA staff regarding potential improvements to the ITAR?
To NTIA, yes, with acknowledgement. As far as IANA, I've exchanged
private email with Kim Davies and Richard Lamb about this (May 27 and
28, 2009). If you want, I can forward copies of the messages to you
privately.
PS - To date we have more operational experience with DLV than a signed root.
More and more I will know what to anticipate when rolling DNSSEC
out the door,
at least as far as DLV is concerned.
There are multiple DNSSEC testbeds. Are you making use of them?
No - none have been appropriate for what we would want to test.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
