Thanks for your feedback about the extended errors draft. Below are
responses to some of your previously raised points in email to dnsop:
8.3 Shane Kerr
~~~~~~~~~~~~~~
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.
----------------------------------------------------------------------
8.3.1 DONE Minor suggestion: text for the descriptions should be consistent
---------------------------------------------------------------------------
regarding capitalization. So:
* Forged answer -> Forged Answer
* DNSKEY missing -> DNSKEY Missing
* RRSIGs missing -> RRSIGs Missing
----------------------------------------------------------------------
+ Response: Good point, thanks! done.
8.3.2 NOCHANGE 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.
+ Response: Good point... though because we removed rcode-binding
this sort of is resolved
----------------------------------------------------------------------
8.3.3 DONE 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: Yep. Fixed in the latest version (and simplified)
----------------------------------------------------------------------
8.3.4 DONE multiple RCODE issues
--------------------------------
+ Response: The response code has been dropped, as noted above
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"
----------------------------------------------------------------------
8.3.5 NOCHANGE 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.
+ Response: If there sufficient support, we'd certainly add it. This
is primarily intended to be used for extreme cases and only when
problems/unusual are detected. Most DNS messages won't contain EDE
options and when they do they'll likely fall below the DNSSEC
amplification factors that are out there. We think the benefit of
including the extra information outweighs the problems with sending
it. But we'd certainly love to hear more feedback from the
community to see if there is agreement one way or another here.
8.3.6 NOCHANGE On the gripping hand, adding unasked-for information may have
privacy
------------------------------------------------------------------------------------
implications. Possibly adding a "Privacy Considerations" section would
be useful?
+ response: What would you like us to add to such a section? The
question/answers section likely has most of the sensitive
information. If you'd provide text to clarify your thinking, we'd
gladly include it.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
