On Mar 3, 2025, at 04:53, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote: > > Dear dnsop WG, > > Willem Toorop and I submitted new draft: Clarifications to the DNS Ranking > Data > (draft-fujiwara-dnsop-ranking-data-00.txt). > > Status: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-ranking-data/ > URL: https://www.ietf.org/archive/id/draft-fujiwara-dnsop-ranking-data-00.txt > > Please review and comment.
I don’t have first hand involvement, but I believe there are still name servers that respond authoritatively for some zones and act as recursive servers for other zones. This was central to split DNS set ups (where an enterprise might have more hosts in the internal view of their zone than in the external/global view of their zone) I used to see. (I’m thinking of https://kb.isc.org/docs/aa-00851.) (I see section 5 mentions split-horizon, but I don’t think the description is fully correct. Any zone can be “overridden” (in the sense that there’s a version that is part of the global public DNS, a local copy may alter the zone), but that is per zone. An overridden zone may delegate back to zones that are also part of the global…but this is getting overly complicated and might work for a small handful of perhaps overly enthusiastic operators.) This leads to my issue with the word “merge.” I don’t think servers merge data fed via zone transfers or dynamic updates with data set learned via recursive activity. It might be tempting to “merge” glue this way, but I doubt anyone does. On the other hand servers might merge data when constructing a response - choosing data in an answer section might only be from a zone while additional (glue) section might pull in data from a cache it might have. (If it has a cache.) Question - does “merge” mean to combine what is held in memory or what is put into a response? Where does "Aggressive Use of DNSSEC-Validated Cache” (RFC 8198) fit into this? I see that as an example of an “authoritative” denial being picked out of the cache. (The long resistance to that practice was unwillingness to allow recursive servers to take on an authoritative task - responding to query, without ever passing it on to the authority, as if the recursive were the authority. (This seems to be conflict with Directive #2 in section 4 of the draft.) I’ll nod to other comments as well (RPZ/DNSBL issues, document dependencies, etc.). Is the goal to (I have to use this word) “clarify” the way in which a response is constructed? For example, in any section there ought to be no mixing of local configured data (XFR’s, RPZ) and data learned via recursion? Does DNSSEC matter in mixing rules? I would think how an implementation internally stores data is outside the concerns of interoperability, so I’m guessing the goal is to work on how responses are constructed.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
