[DNSOP] Feedback on extended error from the IETF hackathon

Shane Kerr <shane@time-travellers.org> Sun, 24 March 2019 11:30 UTC

To: dnsop@ietf.org
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <f1ea01e2-d067-09ce-965d-d72024ed3be3@time-travellers.org>
Date: Sun, 24 Mar 2019 12:29:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cehhhflTXEb4y9A5RHq8y-ZCVTI>
Subject: [DNSOP] Feedback on extended error from the IETF hackathon
Precedence: list

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] Feedback on extended error from the IETF … Shane Kerr