Re: [DNSOP] Comment on Ranking data

[Willem Toorop <[e-mail]>]

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