Hello everyone,
Several folks have worked on implementing the
draft-ietf-dnsop-extended-error at the IETF Hackthon yesterday and
today. This is my own feedback on the draft based on trying to get it
added to dnsdist.
----------------
Stéphane Bortzmeyer pointed out that it wasn't clear how to encode the
INFO-CODE into the 12 bits allocated to it. I think that the idea is
that it should be represented in network (MSB) order, but probably it
should be specified.
----------------
Minor suggestion: text for the descriptions should be consistent
regarding capitalization. So:
* Forged answer -> Forged Answer
* DNSKEY missing -> DNSKEY Missing
* RRSIGs missing -> RRSIGs Missing
----------------
For some reason NXDOMAIN(3)-specific codes are listed after
NOTIMP(4)-specific and REFUSED(5)-specific codes in the draft. I think
it would make more sense to just include these in order.
----------------
Numbering is a bit weird in section 4.1.3:
4.1.3. INFO-CODEs for use with RESPONSE-CODE: NOERROR(3)
4.1.3.1. NOERROR Extended DNS Error Code 3 - Stale Answer
Probably the idea is just to have:
4.1.3. NOERROR Extended DNS Error Code 3 - Stale Answer
----------------
RESPONSE-CODE: 3 (NOERROR)
INFO-CODE: 3
Purpose: Answering with stale/cached data
Reference: Section 4.1.3.1
-> should be RESPONSE-CODE 0
----------------
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 7
Purpose: No NSEC records could be obtained
Reference: Section 4.2.8
-> should be "No Reachable Authority", 4.2.7
----------------
This code is missing in the table:
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 8
Purpose: No NSEC records could be obtained
Reference: Section 4.2.8
----------------
RESPONSE-CODE: 4 (NOTIMP)
INFO-CODE: 1
Purpose:
Reference: Section 4.4.2
-> should be "Deprecated"
----------------
Finally, I note that the suggestion of requiring that the sender have
some signal indicating that it is interested in extended errors was not
adopted. I don't insist on it, but I think it would be useful to avoid
bloating packets unnecessarily. It's a bit like the useless additional
section data that lots of servers insist on appending to answers... why
send something that will not be seen?
OTOH I realize that having this information available may be useful for
humans debugging things, even if the sender does not ask for it.
On the gripping hand, adding unasked-for information may have privacy
implications. Possibly adding a "Privacy Considerations" section would
be useful?
https://tools.ietf.org/html/rfc6973#section-7
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
