Re: [DNSOP] Verifying errata 5316 against RFC1034.

[Warren Kumari <[e-mail]>]

On Sun, Apr 1, 2018 at 5:06 PM, Evan Hunt <[e-mail]> wrote:
> On Sun, Apr 01, 2018 at 01:33:17PM -0400, Warren Kumari wrote:
>> I'm also somewhat confused what the caching the wildcard answer
>> *means* - if I have *.example.com cached and then get a query for
>> foo.example.com I still need to query for it (note that this is all
>> before DNSSEC / Aggressive NSEC / etc) and so what is the "use" of the
>> cached wildcard? AFAICT, searching for the wildcard itself is only
>> useful for debugging, so caching it seems wasteful at best.
>
> It could also be wasteful not to. First, the resolver has to examine every
> name to see whether it's a wildcard before deciding whether to cache it,
> which has a small but non-zero cost. Second and more significantly, every
> time an explicit query for a wildcard name arrives, an iterative query
> must be sent to resolve it.
>

Fair 'nuff. I was expecting that it would be very seldom that a
recursive would see queries for the wildcard explicitly, but I accept
your point.

> I strongly suspect the reason the text was there was to prevent
> implementations from naively using a cached wildcard record *as* a
> wildcard -- i.e., synthesizing answers when there was a cache miss,
> instead of sending a query to the authority.  As long as an implementation
> doesn't do that, I see no reason to worry about it.
>
>> Can folk help me understand what should happen with this errata?
>
> Errata, as I understand it, are meant to fix drafting errors, not
> correctly-expressed but wrong ideas.  I agree with Mukund that the
> requirement shouldn't be there, but I'm not sure which class of error
> it is - bad writing or wrong thinking. If it was wrong thinking, then it
> calls for correction in a bis document rather than an erratum.

Yup, that it is the big question - while I agree that caching them
shouldn't be harmful (and that some implementations do), we cannot
retroactively change published documents with Errata.

The "IESG Processing of RFC Errata for the IETF Stream"
(https://www.ietf.org/iesg/statement/errata-processing.html) speaketh
thusly:
"Changes that modify the working of a protocol to something that might
be different from the intended consensus when the document was
approved should be either Hold for Document Update or Rejected.
Deciding between these two depends on judgment. Changes that are
clearly modifications to the intended consensus, or involve large
textual changes, should be Rejected. In unclear situations, small
changes can be Hold for Document Update."

This is not clearly a modification to the intended consensus (yet),
and currently feels unclear to me, so I'm going to give this another
few days (~1 week) and then, probably, mark it Hold for Document
Update. I'd still appreciate peoples' views and comments on if this is
correct.

W

>
> Errata can be published an awful lot faster, though.
>
> --
> Evan Hunt -- [e-mail]
> Internet Systems Consortium, Inc.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf