[DNSOP] Feedback on extended error from the IETF hackathon

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

Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AD661131148 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 04:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3aNkGXtNxWF7 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 04:30:13 -0700 (PDT)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0215131138 for <dnsop@ietf.org>; Sun, 24 Mar 2019 04:30:10 -0700 (PDT)
Received: from [2001:67c:1232:144:ad24:cd93:9366:dfbe] by time-travellers.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1h81Ki-00033q-Jb for dnsop@ietf.org; Sun, 24 Mar 2019 11:30:32 +0000
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
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 11:30:21 -0000

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)  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


    INFO-CODE:  3
    Purpose:  Answering with stale/cached data
    Reference:  Section
-> should be RESPONSE-CODE 0


    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:

    INFO-CODE:  8
    Purpose:  No NSEC records could be obtained
    Reference:  Section 4.2.8


    INFO-CODE:  1
    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?