Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

From: Donald Eastlake <[email-masked]>
Date: Fri, 23 Nov 2018 23:57:27 -0500

I like the Extended Error Code using EDNS idea. This was effectively
what was done with TSIG and TKEY that have an expanded Error field
inside the RR. However:

 >> I don't see any reason for the complex two-dimensional table to
new error codes. Given that 16 bits is available for "INFO-CODE"
(which I think, to follow the DNS nomenclature used in TSIG and TKEY,
should just be called "Error"), I don't see why these extended error
codes, which provide more detail beyond the top level Error code
value, can't be from the single unified DNS error code table. That
way, wherever you get a DNS Error code (from RCODE or the EDNS
extended error field or the TSIG or TKEY error fields or wherever,
there is just one table to look it up in. For example, you could
Reserve 4096 through 8191 for this purpose, which is probably enough
values :-)

 >> Since RCODEs are 4 bits, I don't see why a 16-bit RESPONSE-CODE
field is required. Even if you want to be able to provide additional
information for the 12-bit error codes of RCODE as extended by base
EDNS, there is still enough room in the previous 16-bit word which has
15 unused bits in it. Just move the RESPONSE-CODE up into the previous
word.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

On Tue, Oct 30, 2018 at 1:42 PM Paul Vixie <[email-masked]> wrote:
>
>
>
> Ray Bellis wrote:
> ....
> > FWIW, I really wish in retrospect that EDNS(0) had defined the extra
> > rcode bits as being for a _sub-type_ of the primary RCODE, i.e. SERVFAIL
> > is always "2" in those four bits in the main header, with the extended
> > field in the EDNS response allowing for more detail (c.f. this draft).
> >
> > Unfortunately with the newer RCODEs just being assigned contigiously
> > from 16 onwards that's no longer possible :(
>
> it was never possible -- we needed more rcodes, even though we now know
> we also need more detail on existing rcodes.
>
> --
> P Vixie
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop