Subject: [DNSOP] Verifying errata 5316 against RFC1034.

From: Warren Kumari <[email-masked]>
Date: Sun, 1 Apr 2018 13:33:17 -0400

Hi all,

We have this errata:
https://www.rfc-editor.org/verify_errata_select.php?eid=5316

The document as published says:
"A * label appearing in a query name has no special effect, but can be

used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it.  The result of such a query should not be cached.

Note that the contents of the wildcard RRs are not modified when used to
synthesize RRs."

and the Notes in the Errata says:
"It is perfectly OK for an RR with a wildcard label '*' to be cached
as long as it's not used to synthesize any RRs on a caching resolver.
The DNS implementations BIND and Unbound both cache such RRsets with
wildcard label in the owner name."

Sure enough, BIND caches the answer (I must admit that this surprised
me) but should the errata be approved? When the document was
published, was the intent that wildcard records should NOT be allowed
to be cached?

Note that if behaviors have changes, and implementations should now
cache the record, then we need to document that in a -bis (or similar)
document.

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.

Can folk help me understand what should happen with this errata?
W

-- 
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

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 1 Apr 2018 23:58:07 +0530

> Can folk help me understand what should happen with this errata?

To elaborate further:

IMO there's no argument against caching if the cached record set (with
wildcard owner name) was not used in synthesis of RRs. I suspect RFC
1034 language was written to prevent that, not the actual caching
itself.

Caching takes place not just by BIND, but Unbound as well and does not
cause problems, so the stronger requirement is unnecessary and ought to
be re-worded.

That is.. unless there is something I've missed. ;) What else is the
problem in caching wildcard records?

> cache the record, then we need to document that in a -bis (or similar)

I agree about this in the scope that we even allow some synthesis with
DNSSEC now in RFC 8198.

But the errata is still for the 1987 document, i.e., as it was back in
time. There doesn't seem to be any sense in having this requirement and
implementations ignore it anyway.

		Mukund

---

From: Evan Hunt <[email-masked]>
Date: Sun, 1 Apr 2018 21:06:19 +0000

> 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.

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.

Errata can be published an awful lot faster, though.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: bert hubert <[email-masked]>
Date: Mon, 2 Apr 2018 09:42:05 +0200

> cause problems, so the stronger requirement is unnecessary and ought to

PowerDNS recursor will also happily cache a *.record but not do anything
special with it.  I also see no strong requirement for this.  In fact not
caching a * record would open up fun ways of creating more spoofing
opportunities I bet.

	BErt

---

From: Warren Kumari <[email-masked]>
Date: Mon, 2 Apr 2018 09:56:05 -0400

> 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.

> 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

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 2 Apr 2018 20:12:04 -0400

On 2 April 2018 at 09:56, Warren Kumari <[email-masked]> wrote:

> Hold for Document Update seems like the right choice to me.  I don't think
it's proper Errata for the reasons already mentioned, and as we're already
discussing maybe obsoleting 1035 with a rewrite, Hold seems more prudent
than Reject.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Apr 2018 10:35:53 -0400

>> Update. I'd still appreciate peoples' views and comments on if this is

One week is up, and I posted it as Hold for Document Update.

Thanks everyone for your review and advice.

W