Hi Shane, > On 1. 4. 2026, at 14:58, Shane Kerr <[email protected]> wrote: > > Ondřej, > I'm surprised there hasn't been discussion on this, although maybe the > LLM-generation put people off.
Shrug, I think it is better to be transparent in the use of the slightly better spell checker and autocomplete than pretend that didn't happen. Nevertheless, the updates described below have been done directly by myself alone. > 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!!! Sure, but I don't view this as "enforcement" that everyone has to implement. I would be also happy with Informational status. > 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. Yes, that's my main motivation. To document what has been done in BIND 9.21.21 (BIND 9.21.x is to be released as stable 9.22.0 later this year), and what others has been doing as well. > The second being that if we declare child-side NS to be unnecessary then we > are saving lots of useless lookups. That's the funny thing - unless you implement strict draft-ietf-dnsop-ns-revalidation then it is already the case. > 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." The full paragraph is: > The child-side NS RRset is authoritative data from the child zone and is > the correct answer to an NS query. The parent-side NS RRset received in > referrals is non-authoritative delegation information and MUST NOT be > returned as the answer to an NS query. The paragraph speaks what should happen when the AA data is received by the resolver. > It seems like it would require separate cached values for NS: one for the > parent, one for the child. That's implementation detail - you can also store the "owner" of the information inside a single database. > 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. Yet another funny thing - this is already the case - it is kind of Heisenberg's delegation - the delegation records changes when you look. Unless the cache snooping is enabled (which really should not be - yeah, that's something next on my list), the NS query to the resolver will make the resolver to resolve child's NS records replacing the delegation records. > 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. Should this guidance be part of this draft? Perhaps add something about long TTLs at the parent to this section? ## Compatibility with Existing Infrastructure > 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. Ok, I've added (A/AAAA) there. > 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. I've added word "optional" to the abstract and introduction and added reference to draft-ietf-dnsop-ns-revalidation saying that DNS resolvers are free to pick one. And the -02 is now out: A new version of Internet-Draft draft-sury-dnsop-parent-centric-resolver-02.txt has been successfully submitted by Ondřej Surý and posted to the IETF repository. Name: draft-sury-dnsop-parent-centric-resolver Revision: 02 Title: Parent-Centric Delegation Handling in DNS Resolvers Date: 2026-04-03 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/archive/id/draft-sury-dnsop-parent-centric-resolver-02.txt Status: https://datatracker.ietf.org/doc/draft-sury-dnsop-parent-centric-resolver/ HTMLized: https://datatracker.ietf.org/doc/html/draft-sury-dnsop-parent-centric-resolver Diff: https://author-tools.ietf.org/iddiff?url2=draft-sury-dnsop-parent-centric-resolver-02 Abstract: This document specifies an optional parent-centric behavioral model for DNS recursive resolvers, in which delegation decisions are always based on the NS RRset (or DELEG RRset) received from the parent side of a zone cut and are never overwritten by child-side NS data. The parent-centric model eliminates the "two sources of truth" problem inherent in the current DNS delegation design, closes the Ghost Domain and Phoenix Domain attack vectors, provides deterministic behavior in the presence of parent/child NS mismatches, and enables resolvers to safely accept sibling (out-of-bailiwick) glue by scoping delegation information to individual zone cuts. It also provides the behavioral foundation required for deployment of the DELEG extensible delegation mechanism. This document updates [RFC1034] and [RFC1035]. Ondrej -- Ondřej Surý (He/Him) [email protected] A gentle nudge is always appreciated if I take a little longer to reply. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
