Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

"libor.peltan" <> Wed, 10 November 2021 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75DC63A0820; Wed, 10 Nov 2021 01:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.231
X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YN5WBLaOKs3S; Wed, 10 Nov 2021 01:35:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6683A3A07D7; Wed, 10 Nov 2021 01:35:39 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 968AE13FB49; Wed, 10 Nov 2021 10:35:36 +0100 (CET)
To: Roy Arends <>, dnsop <>
Cc: dnsop-chairs <>, Matt Larson <>
References: <>
From: "libor.peltan" <>
Message-ID: <>
Date: Wed, 10 Nov 2021 10:35:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting
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: Wed, 10 Nov 2021 09:35:46 -0000

Hi Roy,

> Change 2) There was an observation by developers that some 
> authoritative servers do not parse (unknown) EDNS0 options correctly, 
> leading to an additional roundtrip by the resolver. It was suggested 
> that authoritative servers could return the new EDNS0 option 
> “unsolicited”. This is already the case for Extended DNS errors. We 
> have adopted this suggestion. It was also pointed out that this kind 
> of unsolicited behaviour can be surveyed. We believe that one such 
> effort is underway.

Let me express my personal opinion here.

While sending unsolicited EDE seems fine for me as it's just few bytes, 
the error-reporting address might be usually roughly 100 bytes long, so 
sending it with very every response may lead to perceptible increase in 
traffic, including increase in TCP fallbacks.

This may be tolerable, if there were some better reason for it. But I 
don't like argumenting with broken implementations. Always dodging 
broken implementation only leads to more broken implementations (see DNS 
Flag Day etc). In ideal case, we should aim for the state where broken 
implementation are failing constantly.