IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt

Paul Wouters <paul@nohats.ca> Fri, 07 January 2022 02:14 UTC

Return-Path: <paul@nohats.ca>
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 767833A0DE6 for <dnsop@ietfa.amsl.com>; Thu, 6 Jan 2022 18:14:57 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 0tzWK7jOu1j6 for <dnsop@ietfa.amsl.com>; Thu, 6 Jan 2022 18:14:52 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC823A0DEF for <dnsop@ietf.org>; Thu, 6 Jan 2022 18:14:52 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JVRcj63HXz370; Fri, 7 Jan 2022 03:14:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1641521685; bh=4F1Xs24X1DyD+W3GtW6Uys7d4+YnXSNdZn8anlkSNs8=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=saFaOr1iTwlwOCQDxI5UFNcUw2t4tYqhbSpgv67jtB21Wkr4OFBVXnW98xaswuWzJ 5pfuWCwph2Dj0+gYlZoSXXOl5TicRoetnpNQCQkYwo+6UlfNFBH/SFLEesILFEPq5U xFrmcmJzu+gJEJ0SQoJV7ijC6NJxDGgAIfiDC9qE=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ex_cwUBqIvvR; Fri, 7 Jan 2022 03:14:44 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 7 Jan 2022 03:14:43 +0100 (CET)
Received: from smtpclient.apple (unknown [193.110.157.208]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id E37C21EA6E5; Thu, 6 Jan 2022 21:14:42 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Thu, 06 Jan 2022 21:14:41 -0500
Message-Id: <86BD4B9B-609B-479E-9C32-BEC9E3D5EF68@nohats.ca>
References: <c775a81b-d892-23ab-4954-4852559f66d1@redbarn.org>
Cc: dnsop <dnsop@ietf.org>
In-Reply-To: <c775a81b-d892-23ab-4954-4852559f66d1@redbarn.org>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
X-Mailer: iPhone Mail (19C56)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oaPh7C_jX0qGuok5h2kgBTzjKJc>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt
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: Fri, 07 Jan 2022 02:14:58 -0000

On Jan 6, 2022, at 20:48, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org> wrote:
> 
> 
> 
> George Michaelson wrote on 2022-01-06 16:50:
>> for a 200 in 200,000,000 problem? Ban it.
> 
> i agree that we should ban it, but not on the basis of its infrequency of use. rather, on the basis of data provenance.

Who wants to be the first to fail resolving adobe.net 😀

Seriously though, this draft is not about banning certain deployments or not. Its only concern is MAY vs SHOULD vs MUST require the found glue to be added to the response and potentially cause TC. 

I am tempted to SHOULD (or just not mentioning sibling glue at all) for two reasons.

1) the WG keeps punting this so MUST or MUST NOT seems too strong

2) in general the whole point of this draft is to get the glue in as it’s important and some implementations don’t always do that. Making it MAY or SHOULD NOT might leak into the non-sibling use case and for this 0.0000002% I don’t really care what happens. (Adobe can fix it if they need to)

Paul

v2.23.0 | Report a Bug | By Email