IETF Logo Mail Archive

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

Paul Vixie <paul@redbarn.org> Fri, 07 January 2022 05:59 UTC

Return-Path: <paul@redbarn.org>
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 060983A1465 for <dnsop@ietfa.amsl.com>; Thu, 6 Jan 2022 21:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.813
X-Spam-Level:
X-Spam-Status: No, score=-2.813 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-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=redbarn.org
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 9XL6zZh6yPy9 for <dnsop@ietfa.amsl.com>; Thu, 6 Jan 2022 21:59:21 -0800 (PST)
Received: from util.redbarn.org (util.redbarn.org [24.104.150.212]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34FD3A1467 for <dnsop@ietf.org>; Thu, 6 Jan 2022 21:59:19 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 964CE125EA7; Fri, 7 Jan 2022 05:59:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1641535159; bh=39NQOWvK4xjPL7g8lE6xBaTggRdHQbt0tsp3EUmnepA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=IZAVSE87YtHAfEycUw7VVs4xuR4iMCDz1EczGcHldGHqgUEKcY+sBj8NXU8sB5zIP K8ad7H+WH7tV3nOKYwcpitkSx1jGZUoF07XkPDFs7r0bjS09kURmOBiylAnqEosq8L YHIsmpQXtUay+vGVmIawoz3EsB+Bs2o7jPuzuC00=
Received: from [24.104.150.163] (dhcp-163.access.rits.tisf.net [24.104.150.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BF5DD7597E; Fri, 7 Jan 2022 05:59:16 +0000 (UTC)
To: Paul Wouters <paul@nohats.ca>
Cc: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
References: <c775a81b-d892-23ab-4954-4852559f66d1@redbarn.org> <86BD4B9B-609B-479E-9C32-BEC9E3D5EF68@nohats.ca>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <132fd62e-6e3d-3d2a-1b64-e1c00feaab49@redbarn.org>
Date: Thu, 06 Jan 2022 21:59:16 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54
MIME-Version: 1.0
In-Reply-To: <86BD4B9B-609B-479E-9C32-BEC9E3D5EF68@nohats.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4s38mlcBeT_Itzxhu6gaN0vrRz8>
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 05:59:29 -0000


Paul Wouters wrote on 2022-01-06 18:14:
> 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 😀

adobe.net is unrelated to adobe.com.

> 
> 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 don't think any draft can or should specify behaviour in the face of a 
data loop other than (a) servfail and (b) required. if this draft is not 
going to touch on data loops, that's fine, leave it out. if it does, 
though: "servfail required".

-- 
P Vixie

v2.23.0 | Report a Bug | By Email