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 <[email protected]>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop