Thank you Fujiwara-san, I agree that some data should be discarded depending on use case.
I also think the draft should be more explicit on what data is actually meant in those ranks (i.e. referral responses with "B: Data from the authority section of a non-authoritative answer, Additional information from non-authoritative answers." etc.) and I also agree that we should remove the ranks which are currently meaningless and would not occur in practice (like the BB ranks in the list). I furthermore agree with your recommendation for DNS software to discard all data which is not in the list.
I am still contemplating whether or not the list is too generalized with respect to roles or functions in the DNS ecosystem (Authoritative, Recursive Resolver, Forwarder & Stub). Different functions get the data from different places, but since software may be a mix of those different functions, it does make sense to me to put an order to the preference of the data depending on where it came from in a single list.
Even with an authoritative only name server without cache, you could still say that data acquired over a zone transfer should be preferred over data read from a zone file (that may be just loaded to initialize a secondary name server). The other ranks in the list would then simply be inapplicable.
I acknowledge that it is better to accept DNSSEC validated secure data only when it makes sense in the context of the work a DNS software is doing instead of blindly trusting validated data. I will rephrase that in the draft. But that aside, why would it be bad to blindly trust DNSSEC validated secure data? What do others think?
Op 05-04-2024 om 09:28 schreef Kazunori Fujiwara:
dnsop WG,
RFC 2181 Section 5.4.1 Ranking data should be obsoleted.
The "Raning data" draft (draft-toorop-dnsop-ranking-dns-data-00)
defines each data's ranking and importance.
However, some of the data should be discarded depending on the use cases.
We have four DNS functions: Authoritative, Recursive Resolver, Forwarder, Stub.
Some implementations have multiple functions. For example, some
recursive resolvers have "split-holizon" and "local zones" functions.
Both "split-holizen" and "local zones" can be treated as a function
where descendants of a specified domain name behave as an authoritative
server rather than a recursive server.
Authoritative (only) servers:
Authoritative-only servers SHOULD answer zone data from a
single source (for example, zone file, zone transfer, other database),
so rankings SHOULD not be used to replace data.
"BBB: Occluded data" SHOULD be discarded.
(at least when responding to queries)
Recursive (only) resolvers:
They don't have "AAA: zone file" / "AA: Data from a zone transfer".
"CCC: Names and addresses for the root servers from a hints file"
or "CC: built into resolver software" SHOULD be used for the priming only.
The data that can be returned to the stub resolver as a name
resolution result is "A: The authoritative data included in the answer
section of an authoritative reply" only.
"A-: Data from the authority section of an authoritative answer."
NXDOMAIN response contains a SOA RR in the autority section.
Some authoritative servers add NS RRSet in the authority section.
I want to discard the NS RR set.
If you want it, send NS queries (as described in the ns-revalidation
draft).
"BB: Data from the answer section of a non-authoritative answer"
discard it.
"BB: non-authoritative data from the answer section of authoritative answers"
discard it.
"B: Additional information from an authoritative answer"
If those data correspond to type MX, HTTPS/SVCB, or SRV responses,
resolvers can decide based on local policy.
"B: Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers."
This is a referral response.
A non-authoritative response from a server with administrative
authority for a certain name that has NS RRSet in the authority
section and Glue data in the additional section is a delegated
response, and is used only for name resolution and not for
responding to stub resolvers.
The rank of the referral response is "A", I think.
Any other response may be an attack and should be discarded.
"AAA: all data that is verifiable DNSSEC secure regardless off were it came
from"
I don't like this rank.
I like to use DNSSEC validation to decide
whether to use "Additional information",
but I don't like to blindly trust data
that has been successfully validated.
I believe many recursive resolver implementations have already
discarded unnecessary responses.
Stub resolvers: accept all responses from the recursive resolver.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
