Re: [DNSOP] Implementations of extended error?

Shane Kerr <> Mon, 04 February 2019 10:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24FB5130E59 for <>; Mon, 4 Feb 2019 02:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lrdp2I9EGMMK for <>; Mon, 4 Feb 2019 02:51:21 -0800 (PST)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0B3B130E2E for <>; Mon, 4 Feb 2019 02:51:21 -0800 (PST)
Received: from [2001:470:78c8:2:58d9:59d2:f762:b06f] by with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1gqbrL-0001HX-Ll; Mon, 04 Feb 2019 10:52:15 +0000
To: Wes Hardaker <>
References: <> <> <>
From: Shane Kerr <>
Message-ID: <>
Date: Mon, 04 Feb 2019 11:51:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Implementations of extended error?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Feb 2019 10:51:23 -0000


On 01/02/2019 22.21, Wes Hardaker wrote:
> Shane Kerr <> writes:
>> I was thinking about adding some support for this at the IETF hackathon, but I'll be
>> meeting with some of the open source DNS folks this weekend at FOSDEM, and seeing if
>> that collides with their existing plans.
> Excellent!  I look forward to hearing the reports of the conversations.

My own thinking is that extended error is much more important on the 
resolver side than on the authoritative side, so that's what I was 
asking about. The stub side is also super-important, so maybe I should 
look at that too.

There was some discussion that it might be tricky to get correct 
information out of the bowels of a resolver that wasn't designed with 
this sort of reporting in mind. I'm not so worried about that, as any 
additional information seems better than SERVFAIL to me. 😉

Here's what I took away (people can and should correct me where I am wrong):

* ISC has no specific plans for BIND, but will implement extended error 
codes eventually. "Looks like a reference implementation if you stand 
back a bit and squint."

* CZ.NIC has no plans for Knot Resolver, and still have to look 
carefully at the latest draft (although Petr has some interesting ideas 
about what he thinks is valuable in this area).

* NLnetLabs has no specific plans, but Willem thinks that it is cool and 
wants to work with me on it at the Hackathon. Maybe I can work on 
Unbound and he can work on getdns, so we can have inter-operable tests 
(admittedly from a single company).

I forgot to ask anyone from PowerDNS, which is kind of stupid of me 
since they did 99% of the work for the DNS devroom at FOSDEM (especially 
Peter van Dijk).

As far as the stub side, I also didn't ask anyone from the 
systemd-resolverd side, but given that they apparently disable basically 
all DNS functionality introduced after RFC 1035 by default, I don't know 
how useful support there would be.

And finally also on the stub side, I did not talk to anyone on the glibc 
team or anyone of the distribution folks depending on it.

Apologies for any incorrect reporting here, and for anyone that I omitted.