[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?