Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

[Robert Edmonds <[e-mail]>]

IETF Secretariat wrote:
> The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state 
> Candidate for WG Adoption (entered by Tim Wicinski)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/

Hi,

I've read the -03 version of this draft and previous mailing list
discussion about prior versions of the draft and I don't support its
adoption. There doesn't seem to be a strong (preferably data-driven)
reasoning to justify the mechanism described in the draft, and in
previous discussion [0] it's described as being, essentially, just an
interesting optimization.

[0] https://mailarchive.ietf.org/arch/msg/dnsop/NruMO-whi7UW7gzXF-gu9OrYTMg

For keeping popular records in cache, pre-fetching (e.g.
draft-wkumari-dnsop-hammer) would seem like a less disruptive technique
since it can be implemented entirely by the recursive name server, and
it can also be applied to unsigned records, of which there are still
quite a few. Pre-fetching probably doesn't help unpopular records as
much (if at all), but unpopular records (by definition) don't have as
many users as popular records.

About the draft itself:

I wondered why signalling is necessary.

• RFC 1034 §4.3.2 “Algorithm”, step 6:

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

This would seem to let an authoritative nameserver add any records
deemed “useful” to the additional section of a response. (The RFC says
“query” instead of “response” here, but that is almost certainly an
erratum.)

• RFC 2181 §5.4.1 “Ranking data”:

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

   When DNS security [RFC2065] is in use, and an authenticated reply has
   been received and verified, the data thus authenticated shall be
   considered more trustworthy than unauthenticated data of the same
   type. […]

This is the prohibition on promoting additional section RRs to answer
section RRs in the responses returned to clients. But the prohibition
only applies to unauthenticated RRs. It actually sub-divides the
“Additional information from an authoritative answer” rank into two
sub-ranks based on DNSSEC status.

Is there anywhere else in the DNS/DNSSEC specs that would prohibit that
promotion, where the additional record is DNSSEC secure? Otherwise I
would think that nameservers could populate the additional section with
whatever they want, and security-aware recursive name servers could pick
up secure RRs from the additional section, and cache them such that they
would be returned in the answer section to clients, all without any
signalling. So the EXTRA bit could be eliminated?

• Section 8 “Use of Additional information” from the draft:

   When receiving additional records in the additional section, a
   resolver follows certain rules:

   1.  Additional records MUST be validated before being used.

   2.  Additional records SHOULD be annotated in the cache as having
       been received as Additional records.

   3.  Additional records SHOULD have lower priority in the cache than
       answers received because they were requested.  This is to help
       evict Additional records from the cache first (to help prevent
       cache filling attacks).

   4.  Recursive resolvers MAY choose to ignore Additional records for
       any reason, including CPU or cache space concerns, phase of the
       moon, etc.  It may choose to accept all, some or none of the
       Additional records.

is very confusing to me. I think it doesn't apply to additional records
that are the normal result of additional section processing? I think it
is actually talking about “extra” records that are undergoing an
upgrade.

Basically, this whole idea seems to me like something that can already
be implemented today, without any specification work other than the
format of the EXTRA RR. But the EXTRA RR is just configuration
information and you don't strictly need it until you want to distribute
it interoperably.

-- 
Robert Edmonds