Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

John Levine <johnl@taugh.com> Fri, 03 July 2020 17:59 UTC

Return-Path: <johnl@iecc.com>
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 E081C3A0CC1 for <dnsop@ietfa.amsl.com>; Fri, 3 Jul 2020 10:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Viy937fC; dkim=pass (1536-bit key) header.d=taugh.com header.b=ukS5+LjK
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 u6oaPu0jP_Z8 for <dnsop@ietfa.amsl.com>; Fri, 3 Jul 2020 10:59:39 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 3B1633A0CC0 for <dnsop@ietf.org>; Fri, 3 Jul 2020 10:59:38 -0700 (PDT)
Received: (qmail 27799 invoked from network); 3 Jul 2020 17:59:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6c94.5eff7209.k2007; bh=UErtNZaLKpzrIi9KB3LP2ZM33cHI0KyWoik6wYVMBvg=; b=Viy937fCXwRYwJF8R0lHNTxDNHFlRMPyxZFUsyP8NWL3as75DSOwNF3mK+KRdQ6Oeb2jBMp6MjUjMx6ANqHJ+OIh6aSOjZXWs7Ww7GTBPrv8UqRuf89RW9Ud22rdOStnbTF7gmmZdSrBmlEF00mic4yn3akr5clnMnVBgvrY5f2Ndqm6PvMDFI/ZhVxrxngdPLK3rp8kLm9iAkxYnx4OsL8YKGK9e4Cmt84aXdnJneWzHXLMvEuodXKZKnckArRk
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6c94.5eff7209.k2007; bh=UErtNZaLKpzrIi9KB3LP2ZM33cHI0KyWoik6wYVMBvg=; b=ukS5+LjKrs1SQ9HdVnxzJBjaDfGs8/gGSMjtBnjhftOb9aXuJPkDBUNz5JefflvYKhC9ssDZ56dznGaDMtu+ms26qDSndKMkyiNC/VjzWxG3EXgYl9uHG+JgMNYpLrPIdLVdJK7rj/ih3lUsRJREJ9sje2+yN6fH9Du5dmNqVJBg1GwKN0w4T7ZBfT13nh4xQKEVVt9ik+7ZTql0cUcmo5QPdEsty5QsfjhxmkXa2sPEVG8i6nBjU79FWqUgJhxw
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Jul 2020 17:59:36 -0000
Received: by ary.qy (Postfix, from userid 501) id 1D0441C485EE; Fri, 3 Jul 2020 13:59:42 -0400 (EDT)
Date: 3 Jul 2020 13:59:42 -0400
Message-Id: <20200703175942.1D0441C485EE@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
Cc: brian.peter.dickson@gmail.com
In-Reply-To: <CAH1iCirMLsLmohChQCvqiS6ra0MYK40eJsDm_B5pMXAgXRnEpg@mail.gmail.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OhSOihUJAoEsGGL_R2nAMlyw_OA>
Subject: Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.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, 03 Jul 2020 17:59:41 -0000

In article <CAH1iCirMLsLmohChQCvqiS6ra0MYK40eJsDm_B5pMXAgXRnEpg@mail.gmail.com> you write:
>There are a whole bunch of unused bits in the core element of the OPT RR
>(the place where the DO bit exists). That would be an excellent (IMHO)
>place to signal the situation here (partial glue truncation).
>
>Such a bit would hopefully disambiguate the cases where TC=1 is set,
>allowing for graceful handling (try to use the available glue, prepare for
>the failure case and retry over TCP if it does fail).
>
>Thoughts?

I think it would be easier to clarify the existing rules and encourage
people to follow them rather than inventing new flags that are
unlikely ever to be implemented.

For the particular case of partial glue on referrals, so long as the
packet has all of the answer records, it's never wrong to go ahead and
use the glue it's got. What would a flag do?