Subject: [DNSOP] DNS rcode assignment requirements

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Jul 2015 11:26:52 +1000

At the moment there are "private use" and "IETF Review"
	as the two levels.
	
	While doing dns-cookies it has became clear that "specification
	required" and/or "Expert Review" may be more appropriate
	than "IETF Review" in general.  Leave "IETF Review" for the
	additions to the first 16 which should only be used in cases
	where EDNS is not available.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 14 Jul 2015 23:19:23 -0400

I see two cases:

There are codes from the unified DNS error code space that are not
visible at the top level of a DNS message. For example, the Error
field of TSIG (RFC 2845) or TKEY (RFC 2930). For things like that I
have no problem with Specification Required or Expert Review.

However, for top level RCODEs that appear in the DNS message header
(possibly extended by an OPT RR), I'm not so sure. What is a resolver
supposed to do when it gets such a top level RCODE it does not
understand? You really don't want to deploy new top level RCODEs
except in a context where you have a strong assurance that the
receiver will understand it. I'm more comfortable with IETF review for
this sort of new RCODE value.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Tue, Jul 14, 2015 at 9:26 PM, Mark Andrews <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Jul 2015 15:19:05 +1000

In message <CAF4+nEGB77G7ir68B-F+T+uakVe6MY=[email-masked]>
> this sort of new RCODE value.

That doesn't require IETF review to achieve.  We don't have that
anyway with private rcodes which require no review at all.  In most
cases rcodes are just supplying a bit more information than "it
failed".

There are rcodes like NOTAUTH.  A AXFR request will get a NOTAUTH
(not authoritative) response as it is a better match than REFUSED
when the server doesn't serve the zone.  REFUSED is more policy.
This matches with UPDATE's use of NOTAUTH, but there is no RFC to
say this.  This really does not cause a issue.

NXRRSET really should be returned instead of NOERROR NODATA.  A
EDNS version bump could do this or a EDNS option which signals that
NXRRSET is understood.  Personally I think a version bump is the way
to do this but just requesting a EDNS option would achieve the same
thing and not require IETF Review/Consensus.

For DNS Cookie, is there really a *need* to go through IETF Review
for BADCOOKIE?  It's a WG item and it will get IETF Review but was
the really the need?  The expert reviewer can push back / decline
with reasons which can be appealed.  Been there, done that for DLV.

The original design of DNS-COOKIE had lots of error codes in the
option.  We now have one error code and it is a rcode.

Mark