On Sun, Apr 1, 2018 at 5:06 PM, Evan Hunt <[email protected]> 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 -- [email protected] > 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
