Ondřej,
I'm surprised there hasn't been discussion on this, although maybe the
LLM-generation put people off.
On 2026-03-16 08:16, Ondřej Surý wrote:
we’ve been working on making BIND 9 to use parent-centric delegations
and I thought
It would be useful to turn this into an Internet-Draft. This was also
kind of experiment
whether LLM can create something useful if you feed it all the
important data and know
your subject. The result had been manually curated, I did spent some
time reading
and updating the document.
...
Name: draft-sury-dnsop-parent-centric-resolver
Revision: 01
Title: Parent-Centric Delegation Handling in DNS Resolvers
Date: 2026-03-16
If this is adopted and gets turned into an RFC then it is a huge change!
HUGE!!!
I guess there are a few things to like about this. The first being that
some resolvers already operate in a parent-centric way, so documenting
that would be useful. The second being that if we declare child-side NS
to be unnecessary then we are saving lots of useless lookups.
I do think that the draft presents this change in a somewhat nonsensical
way. "The child is authoritative regarding NS, but don't use those
values to do any lookups."
It seems like it would require separate cached values for NS: one for
the parent, one for the child. Even worse, there is literally no way
that an external party can lookup the value that a resolver is using for
the parent, and that seems like it might make debugging issues tricky.
One could lookup an NS at a resolver, then query those NS directly and
get a completely different value than the resolver itself returns.
One thing that I really /like/ about the draft is that it documents
refreshing TTL values for NS on any lookup at the parent. This is
probably something resolver implementers already do, but writing it down
seems useful.
A minor point is that it mentions that the child will sometimes have a
different TTL for NS records than the parents, and this can be longer.
In general TLDs often to have insanely long TTL for NS records, and I
would guess that in most cases the child's TTL will be less. (2 days for
COM/NET/UK, 1 day for DE, although a much more sensible 1 hour for
ORG/CZ/FR/NL). I suppose that the parent /should/ have some say about
the TTL of the NS record in a parent-centric world... although since
most registries generate new zones at least several times a day I would
suggest that large TTL are unnecessarily large.
The text that says "minimum of NS RRset TTL and the accepted glue record
TTLs", I guess means associated address (A/AAAA) records? Maybe that
should be stated.
Anyway, I think this draft is a fundamental shift in thinking about how
NS are handled, and needs a lot of convincing to go forward.
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
