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