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.)
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.
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.
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.
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.
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.
--
Robert Edmonds
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
