IETF Logo Mail Archive

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

Roy Arends <roy@dnss.ec> Wed, 10 November 2021 10:21 UTC

Return-Path: <roy@dnss.ec>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B93A0CC7 for <dnsop@ietfa.amsl.com>; Wed, 10 Nov 2021 02:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0brFOnVX78H for <dnsop@ietfa.amsl.com>; Wed, 10 Nov 2021 02:21:09 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF943A0CC6 for <dnsop@ietf.org>; Wed, 10 Nov 2021 02:21:08 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id t11so1639125qtw.3 for <dnsop@ietf.org>; Wed, 10 Nov 2021 02:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGRXSJjDDHHHXW0L6Qis0HUbxtoWtzzDSJ9+5OjXGi0=; b=MSFr251yg6nGKCCkSfGM5LOAsKD9spXaSnnztMrI5D6zHKeupX2pt/AuOV3teB3Dr+ uC+JWopFHj/DTmmJjNha49knbLmJ2leWS/fXpl1yM17gtRhJjuF0PuJbuHnfZeV2V5hk kXXlruN21kC5Qd6rL1GqEmNPZrWq83k2YLeWA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGRXSJjDDHHHXW0L6Qis0HUbxtoWtzzDSJ9+5OjXGi0=; b=KOrX+r7jga5ImgAHZVUzbKR7WsNiJUAfnPp2eMvcidc5sa2VClQZYbyKVLr92ze0aD Lc581UQ361abDo4FZCR8ZeWKDcjtIhbWLG8y6tFofvIZb/vJxBcNeUTnoEFUvAPh2JII LhsFHuj3yeZM8L9BNuBYfRy60So1a54cWZGszekFz18w1em/tf/DzzQ6DLs4kIVAQBx5 iuz+cG4cPRtILU9nf2bLcxOUsyRAwJ8ZlhnI80LnnHUlhE7dfIQgEbSybVJySUrqvxEx Nov4O5HxcgROg74raj1crk7aGb8Bo0+rLcEPBnsILi/I/StIlfmutisEP2Zte+Xwy3VS Njrg==
X-Gm-Message-State: AOAM531Xu6Bqk6qBPX5dT4f4DUxyhEaCsRJ8CXbLtCMsUgV2SNrAS0xr sXvchm3naepsHCfsSXeMc9OT1g==
X-Google-Smtp-Source: ABdhPJwoQk6YKtVo2RFw/0PX8limCuT0mAS8fWdVOp+xqkP4Ntwg4qF15JeqMDYLgTSh3/yLxow9jA==
X-Received: by 2002:a05:622a:54f:: with SMTP id m15mr16178940qtx.365.1636539666956; Wed, 10 Nov 2021 02:21:06 -0800 (PST)
Received: from smtpclient.apple ([88.81.139.247]) by smtp.gmail.com with ESMTPSA id l2sm546542qtk.41.2021.11.10.02.21.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Nov 2021 02:21:06 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <f04edd49-a1a5-bca9-2d0c-ff44051cd46f@nic.cz>
Date: Wed, 10 Nov 2021 10:21:03 +0000
Cc: dnsop <dnsop@ietf.org>, Matt Larson <matt.larson@icann.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <618B3436-5244-4F96-B535-00CBC9FBB60C@dnss.ec>
References: <8A09A0DF-D915-45AD-AD57-229641F19120@dnss.ec> <f04edd49-a1a5-bca9-2d0c-ff44051cd46f@nic.cz>
To: "libor.peltan" <libor.peltan@nic.cz>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1LK0Ff9mmh4VTf1-BeItyL_rOkU>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting
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: Wed, 10 Nov 2021 10:21:14 -0000

> On 10 Nov 2021, at 09:35, libor.peltan <libor.peltan@nic.cz> wrote:
> 
> 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.

Thanks! I really appreciate feedback on this! Keep it coming!

> 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,

Why would that be 100 bytes long? An error-reporting domain should be kept rather short.

> so sending it with very every response may lead to perceptible increase in traffic, including increase in TCP fallbacks.

Would it help to require the authoritative server to only add this option when there is space to do so?

> 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.

This is not that! If we were sending new EDNS0 options to authoritative servers, it will lead to additional round-trips to dodge broken servers. This is the way of “dodging broken implementations”. It won’t get these implementations fixed, and this additional resolver code to route around brokenness in the field will eventually end up at flag-day. 

Consider the current method of returning unsolicited new options in responses: A resolver may not handle unsolicited new EDNS0 options. They will either be fixed or not be used. This is not a negotiation, unless the resolver falls back to send a query without EDNS0. I have been told by developers that there are more broken authoritative server software out there than broken resolver software.

Field tests are taking place to measure impact.

Hope this helps!

Warmly,

Roy

v2.23.0 | Report a Bug | By Email