On 3/18/25 01:08, Shumon Huque wrote:
Obviously, I'm largely in agreement with Willem in this discussion.
Let me make a few high level points though.
There are lots of other folks that are in favor of this draft that
haven't spoken up yet. I will try to poke them to chime in.
I am not in favor of downgrading this draft to Informational. I think we
could add language to the draft that does it make it optional, while
keeping the Standards Track normative SHOULD language based on the
technical analysis of its benefits.
Regarding DELEG, yes, I agree that this will make ns-revalidation and
other choices moot in the long term, and I think the choice to have the
new delegation record authoritative in the parent is a good idea. But I
feel that some folks are being way too optimistic about DELEG - usable
DELEG infrastructure I'd guess is at least 5 to 10 years (probably
closer to the latter). This draft deals with the current structure of
the DNS delegation mechanism and where authoritative data resides.
Perhaps my message was too long and an important detail got lost.
I offered **two** alternatives to ns-revalidation draft:
A. I-D.fujiwara-dnsop-resolver-update
- attacks listed in ns-revalidation draft section 8.3 are not applicable
- zero additional cost in term of queries
- easier to operate/debug because parent-child NS mismatch suddenly does
not influence resolution algorithm
- unilateral code-change in resolvers, i.e. doable in the same
time-frame as ns-revalidation
B. Making DELEG happen
That was listed as a long-term thing. It provides an additional
improvements over I-D.fujiwara-dnsop-resolver-update, but it is required.
One more mundane operational benefit I haven't seen mentioned in this
discussion -- since ns-revalidation prefers the authoritative child NS
RRset, that puts control of rapidity of NS RRset changes firmly into the
hands of the child zone operator. We've had huge problems in the past
with some of our DNS vendors routinely messing up (over the course of
multiple years sometimes), where we would have to frequently eject one
or the other vendor out of the NS RRset and have those changes visible
quickly. This is not possible if some of the major TLDs only offer very
long unchangeable TTLs and resolvers don't interrogate the child NS
RRset. You might argue that this problem could be solved by getting some
of those TLDs to offer configurable TTLs, but guess what - we've been
talking about that for ages with no significant movement, so other
protocol solutions are needed.
I can see your point. Having said that, in my eyes it is a minor
improvement with a significant added complexity. Essentially it makes
the overall system harder to debug because a TLD operator is inflexible.
That does not seem like a compelling argument for making this a standard
and pushing it to everyone's compliance checklist.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
