Re: [DNSOP] changes to extended errors based on your comments

Shane Kerr <> Mon, 26 August 2019 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61B7612011F for <>; Mon, 26 Aug 2019 14:53:53 -0700 (PDT)
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 SAB6VOSSm_AD for <>; Mon, 26 Aug 2019 14:53:52 -0700 (PDT)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD05212001A for <>; Mon, 26 Aug 2019 14:53:51 -0700 (PDT)
Received: from ([2001:470:78c8:2::9]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1i2Mvu-0007mB-E4 for; Mon, 26 Aug 2019 21:53:50 +0000
References: <>
From: Shane Kerr <>
Message-ID: <>
Date: Mon, 26 Aug 2019 23:53:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] changes to extended errors based on your comments
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, 26 Aug 2019 21:53:53 -0000


On 10/08/2019 07.30, Wes Hardaker wrote:

> 8.3.5 NOCHANGE 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.
>    + Response: If there sufficient support, we'd certainly add it.  This
>      is primarily intended to be used for extreme cases and only when
>      problems/unusual are detected.  Most DNS messages won't contain EDE
>      options and when they do they'll likely fall below the DNSSEC
>      amplification factors that are out there.  We think the benefit of
>      including the extra information outweighs the problems with sending
>      it.  But we'd certainly love to hear more feedback from the
>      community to see if there is agreement one way or another here.

I guess on balance always having the information is the simplest 
approach. If there is a specific concern this can be changed.

> 8.3.6 NOCHANGE On the gripping hand, adding unasked-for information may have privacy
> ------------------------------------------------------------------------------------
>    implications. Possibly adding a "Privacy Considerations" section would
>    be useful?
>    + response: What would you like us to add to such a section?  The
>      question/answers section likely has most of the sensitive
>      information.  If you'd provide text to clarify your thinking, we'd
>      gladly include it.

I looked through RFC 6973 Section 7 - - and didn't see anything 
that stuck out obviously to me.

Possibly the only real concern is with extra text. It currently reads:

    The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold
    additional information useful to network operators.

Quad9's proposal to include various helpful information like how 
dangerous a particular answer might be made me think that we should be 
careful not to leak information in this channel. For example, a response 
should not say something like, "daily query limit reached for account 

Possibly the description could be changed to something like:

    The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold
    additional information useful to network operators. Care should be
    take not to leak private information that an observer would not
    otherwise have access to, such as account numbers.