Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

Shane Kerr <> Thu, 25 October 2018 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26A82130EC0 for <>; Thu, 25 Oct 2018 13:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bs3X76qmq5i8 for <>; Thu, 25 Oct 2018 13:11:07 -0700 (PDT)
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 9D13C130EE0 for <>; Thu, 25 Oct 2018 13:11:05 -0700 (PDT)
Received: from [2001:470:78c8:2:511f:b040:e564:d9d1] by with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1gFlyK-000393-Rb for; Thu, 25 Oct 2018 20:11:12 +0000
References: <> <>
From: Shane Kerr <>
Message-ID: <>
Date: Thu, 25 Oct 2018 22:11:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
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] Working Group Last Call for draft-ietf-dnsop-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: Thu, 25 Oct 2018 20:11:09 -0000

Dear DNS colleagues,

I definitely agree with George that last call seems a bit premature. As 
he points out, section 6 is a large open question. We need to either 
change EDNS behavior to allow an unsolicited EDNS option in a response 
or change this draft to include an appropriate EDNS option when it 
queries. Personally I think the draft should specify that the query 
should include an empty version of this EDNS option to indicate support 
(this is actually helpful, as it doesn't make too much sense sending 
back extra information that clients will ignore, decades of BIND adding 
useless ADDITIONAL section data notwithstanding).

Plus there's also this odd bit of stray text laying around:

    Here is a reference to an "external" (non-RFC / draft) thing:
    ([IANA.AS_Numbers]).  And this is a link to an

Also is this correct:

    o  OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the
       length of the payload (everything after OPTION-LENGTH) in octets
       and should be 4.

If I am correct there are at least 6 octets after the OPTION-LENGTH and 
possibly more if EXTRA-TEXT is present.

Also, this text seems a bit unclear:

    R - Retry  The R (or Retry) flag provides a hint to the receiver that
       it should retry the query, probably by querying another server.
       If the R bit is set (1), the sender believes that retrying the
       query may provide a successful answer next time; if the R bit is
       clear (0), the sender believes that it should not ask another

The "probably by querying another server" is odd. In my mind it should 
explicitly apply to querying another server ONLY.

The draft refers to EXTRA-TEXT twice, and EXTRA-INFO once which is 
presumably meant to be the same thing. In any case, I think the encoding 
of this field should be specified as either ASCII or UTF-8. I prefer 
UTF-8, because otherwise I won't be able to send back 🤯 emoji in error 
messages (and the authors won't be able to use the 🍄 emoji that they 
clearly want).

I am not sure I agree with these recommendations:

4.1.5.  Extended DNS Error Code 5 - Unsupported DNSKEY Algorithm

    The resolver attempted to perform DNSSEC validation, but a DNSKEY
    RRSET contained only unknown algorithms.  The R flag should not be

4.1.6.  Extended DNS Error Code 6 - Unsupported DS Algorithm

    The resolver attempted to perform DNSSEC validation, but a DS RRSET
    contained only unknown algorithms.  The R flag should not be set.

This seems like a case where a stub resolver may want to try another 
full-service resolver that may support more algorithms, so perhaps the 
text "The R flag should not be set" should be removed.

While the draft suggests that it is possible to add multiple EDE to a 

    o  RESPONSE-CODE, 2 octets: this SHOULD be a copy of the RCODE from
       the primary DNS packet.  When including multiple extended error
       EDNS0 records in a response in order to provide additional error
       information, the RESPONSE-CODE MAY be a different RCODE.

It is not explicit about how this is done. If the intention is for a 
resolver to forward this back to a stub resolver, then it needs to be 
mentioned, probably in section 3, something like this. However, then we 
also need some text describing how a client behaves when presented with 
multiple EDE.

Finally, do we have any implementations of this draft? It seems pretty 
straightforward, but I don't actually think that it's possible to 
develop interoperable code with the draft as it stands today. I vaguely 
recall that we wanted running code going forward to try to starve the 
DNS camel...



On 25/10/2018 00.30, George Michaelson wrote:
> How can it go WGLC with section 6 an open question?
> in every other respect I like the document. Bad Hair and all.
> I would like to understand if we could work out a way to do traceroute
> in the codes, with some defined code to ask the DNS resolver to
> perform a TTL drop on a counter and mark itself into the chain, which
> would help uncover resolver chains.
> With IANA registry requests, I may be wrong here, but I thought we had
> some (boilerplate?) language about how IANA is asked to operate the
> registry: what criteria judge acceptance. Is it like the OID and
> basically open (hair oil) slather, or is it only at WG RFC documented
> request?
> -G
> On Wed, Oct 24, 2018 at 4:42 PM Tim Wicinski <> wrote:
>> Hi
>> We've been talking with the authors of Extended Error and now that
>> they've gotten around to updating the document, and the chairs
>> feel it is ready for Working Group Last Call.
>> We're going to kick this WGLC off this week and run it through IETF103.
>> This will give folks time during the meeting to bring up any issues
>> they may have there.
>> This starts a Working Group Last Call for draft-ietf-dnsop-extended-error
>> Current versions of the draft is available here:
>> The Current Intended Status of this document is: Standards Track
>> Please review the draft and offer relevant comments.
>> If this does not seem appropriate please speak out.
>> If someone feels the document is *not* ready for publication,
>> please speak out with your reasons.
>> This starts a two+ week Working Group Last Call process,
>> and ends on at the end of IETF 103: 9 November 2018
>> thanks
>> tim
>> _______________________________________________
>> DNSOP mailing list
> _______________________________________________
> DNSOP mailing list