At 15:23 -0800 3/4/10, Doug Barton wrote:
I agree with your point that DNSSEC is going to increase both the complexity
and the impact of misconfigurations, which is why I am leaning in the
direction of thinking that adding more bullets to the foot-shooting gun is
probably not the right way to go.
I think one point above has been understated in most discussions -
the impact of a DNSSEC slip up is an outage and the unwitting victim
will be the internet-service provider (ISP or otherwise) "help-desk."
The stakes are a bit higher and the downside falls on the wrong
people.
In my mind all of these points argue strongly against putting work into
this, even if the RRR channel was likely to adopt it, which I am
extremely skeptical about.
It would be very helpful to be able to do automatic delegation updates
in lower levels of the DNS tree.
I'm not 100% dead set against the idea, just mostly thinking it's not a good
avenue to pursue. It would be easier to judge if we had a more concrete
proposal to chew on.
I've been thinking about this and the bar BOF announced earlier. I
said before, there really might be two problems here. I don't want
to seem dismissive of some effort to automate DS updates in-line with
the DNS protocol but such a mechanism would not solve the problem in
registration.
The reason for the informal BOF (note - not even an IETF sanctioned
BOF) is to first draw out the goals and requirements. I'm really not
interested in seeing a concrete proposal at this point. The reason
for that is the lesson from EPP - although the IETF could build it,
it resulted in something that could have been much more.
EPP is by no means a failure, so I don't want to draw too strongly
from that example. There have been other protocols, like for
instance IRIS, which seemed like good ideas and sound engineering
went into them, but they fell flat on the ground because the real
demand wasn't there. What I am warning against here is thinking that
"it would be cool to just shove a bit here, a flag there, a TSIG over
that part" and think that we've come up with a mechanism that works.
This wouldn't be used by the registration environment, even if it
manages to have multiple implementations, etc., and rises to Draft
and Full Standard. If that happens the IETF may have "succeeded" in
producing something to "solve" DS consistency, but the registration
community would still be looking for something useful and we all
would be back at the start of the process.
So, as far as non-registration activity, does anyone have a firm grip
on what is required for automatic DS updates? It would be good to
have a scoping use case (or set of cases) so that the registry folks
don't keep coming with fire hoses and saying "this won't work for us."
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
