[DNSOP] Comment on Ranking data

[Kazunori Fujiwara <[e-mail]>]

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 <[e-mail]>