Hello, Robert-san, Thank you very much for productive comments. details are in-line.
> From: Robert Edmonds <edmo...@mycre.ws> > Kazunori Fujiwara 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 >> >> Abstract: >> >> This document obsoletes Section 5.4.1 (Ranking data) of RFC 2181, and >> specifies directives whereby the source of the data determines for >> what purposes it may be used. >> >> We hope that this draft will clarify the handling of DNS data. >> >> Please review and comment. > > Hi, > > 1) > > I disagree with the obsolescence of Section 5.4.1 of RFC 2181 in its > entirety. If there are specific problems with 5.4.1 they should be > spelled out and fixes applied that update 5.4.1, as has been done > previously. > > For instance, RFC 5452 updates RFC 2181. Section 5.4.1 of RFC 2181 is > explicitly updated by RFC 5452's Section 9.1 ("Query Matching Rules"), > and, arguably, there is an implicit update to 2181's 5.4.1 via 5452's > Section 6 ("Accepting Only In-Domain Records"). > > What happens to these parallel updates to 5.4.1 if the entirety of > 5.4.1 is obsoleted by a new document? Are those parallel updates added > together with the new update in this draft and remain in effect, or > do they share fate with the original 5.4.1 text and are themselves > obsoleted? (Certainly, the text in 5452 is very important and should not > be obsoleted.) Then, authors will change "obsolete" to "update". > 2) > > I am not sure I agree with the assertion in the Introduction of > draft-fujiwara-dnsop-ranking-data-00 that Section 5.4.1 of RFC 2181 > ("Ranking Data") *assumes* the shared database model of Section 2.2 of > RFC 1035 ("Common Configurations"). (I'm assuming this is a reference > to the 4th unnumbered ASCII art diagram in that section: "a host that > supports all aspects of the domain name system".) > "Ranking Data" is *consistent with* the shared database model of > "Common Configurations" but does not *require* that model of > implementers. I would argue that "Ranking Data" is consistent with all > of the diagrammed models in "Common Configurations". For instance, if a > resolver lacks support for loading data from a zone file, the top rank > "Data from a primary zone file, other than glue data", is simply not > applicable to that implementation, since it cannot obtain data from a > zone file. Agree. > 3) > > I disagree with this assertion as well (emphasis added): > > The DNS server assumed in Section 5.4.1 (Ranking data) of [RFC2181] > is considered to be a model with a shared database described > in Section 2.2 (Common configurations) of [RFC1035] that has both > Authoritative server and Recursive Resolver functions. It is assumed > that information obtained from zone files, zone transfers, and name > resolution will be mixed together. > > **However, at the time of writing, this is no longer the practice of > name servers and resolvers.** > > Recursive resolvers still do mix authoritative and recursive functions. > See e.g. RFC 6303 and RFC 7706 Section B.1. It is also a somewhat common > practice to configure local authoritative data into a "mostly recursive" > server for various use cases. RFC 7706 support is special. BIND 9's static-stub and Unbound's stub-zone seems to override root-servers' IP addresses to specified IP address. Local root responses are treated as Authoritative (Root) servers' responses. A multi-function name server can be treated as a collection of functions that serve a domain name (including the root) and below. BIND 9's zone within recursive mode and Unbound's local-zone changes that the server will act as an authoritative server at the specified domain name and below. > 4) > > Directive 3 of the -00 draft: > > https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-ranking-data-00#section-4-1.3.1 > > Non-authoritative responses (referral/delegation responses) > from authoritative servers MUST only be used to query the delegated > authoritative server during the name resolution. > > This would appear to prevent the caching of this information since > it can "only be used [...] during **the** name resolution". This > information should be cachable (to prevent e.g. sending repeated > queries to parent nameservers if a child zone's nameservers are down > or misconfigured), but of course these kinds of records "should not be > cached in such a way that they would ever be returned as answers to a > received query" ("Ranking Data" paragraph 4). > > Perhaps "during name resolution" is meant instead of "during **the** > name resolution". However, see (5) below, since deleting the "the" might > have another, unrelated effect. Yes. I agree. > If a single article results in these kinds of interpretation issues then > I think the text is too compact to replace the kind of longer, narrative > explanation of "Ranking Data". > > 5) > > There is an implementation choice between "child-centric" and > "parent-centric" resolution, i.e. whether the apex NS RRset from a > child zone, if obtained, should be used in preference to the delegation > NS RRset from a parent zone for the same owner name when resolving. > One of the choices is clearly supported from a standards perspective by > referring to the ranks in Section 5.4.1 of RFC 2181. > > If Section 5.4.1 of RFC 2181 is obsoleted in its entirety and replaced > with the Directives in draft-fujiwara-dnsop-ranking-data-00, it would > appear Directive 3 is the most relevant for this question, but I'm not > sure if it is detailed enough to clearly support one of or both of these > implementation choices. If the "the" were dropped from "during the name > resolution" as suggested in (4) above, this Directive would be more > supportive of both options. > > I am not stating an opinion on the "child-centric" vs. "parent-centric" > issue but this would be one of the things that would ideally be > explicitly decided and explained clearly if "Ranking Data" is entirely > replaced with new text. Change "obsolete" to "update". > 6) > > The current version of the DNS Terminology document relies, although not > strongly, on text in "Ranking Data" for several of its definitions: > > https://www.rfc-editor.org/rfc/rfc9499#section-5-1.30 > > Address records: > Records whose type is either A or AAAA. [RFC2181] informally > defines these as "(A, AAAA, etc)". Note that new types of > address records could be defined in the future. > > https://www.rfc-editor.org/rfc/rfc9499#section-7-2.32 > > Glue records: [...] > > A later definition is that glue "includes any record in a > zone file that is not properly part of that zone, including > nameserver records of delegated sub-zones (NS records), address > records that accompany those NS records (A, AAAA, etc), and any > other stray data that might appear." (Quoted from [RFC2181], > Section 5.4.1) Although glue is sometimes used today with this > wider definition in mind, the context surrounding the definition > in [RFC2181] suggests it is intended to apply to the use of glue > within the document itself and not necessarily beyond. Change "obsolete" to "update". Authors will submit next version after IETF 122. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
