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

Brian Dickson <> Fri, 03 July 2020 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F06EE3A0D72 for <>; Fri, 3 Jul 2020 13:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LBmgjHuZ3pJ2 for <>; Fri, 3 Jul 2020 13:39:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 786DD3A0886 for <>; Fri, 3 Jul 2020 13:39:36 -0700 (PDT)
Received: by with SMTP id b13so10390508uav.3 for <>; Fri, 03 Jul 2020 13:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zG8JKH5W/ctTksoDbYPzeftbzNRRbw0+a540iZoSofE=; b=DKPtnlXtNDJd1KLMvHZEXCkmsLXu4Mm7Ed43t/6ttpB0DqB6vs2Zfdo0DIjKa1IoRy KNTppP3LjECAN9SaNj8kJXbL8dZ8XQB/tDaHAEQcxw+RW5Awa5KG1Ojns7at1sW3OBoS 3HEIEv+Att9TsupvnD40oaz4htRuFcH5dD/lrBvD+TrgchZke4Zr5bW6nHR+RQfL3QYB I3PI0O4MWSVABul50GazKyRe0RkHwCLWIfUw3oNoVA16zNwuMtrKENLMhyCRA7Hl3iXQ PS3nm1zEj/PzC2q58V3hmFEv6X8X0RwydDs8Cpm0NzyMrgA07tCckxB6AoYFjo3W1J5+ qnEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zG8JKH5W/ctTksoDbYPzeftbzNRRbw0+a540iZoSofE=; b=IRXz1JbicdU0Lt2ynKNchSYmLKjnCj74h7bkpgsK6dRhC3r21nmudT6kpzF9zLY1Qa tdbtn8EneZ99w/Yn0dHsNql9J9HDKTVIttWIeVYMtY53YoRPJCoIDmDEeipkBIa5W3Bo zDoqlmihPh3J95Cv/r5AXIcLstTcNpPUlbDsfXUCIs6bPdoJSAWpuK9oEBkr2CZwthon 5aMLRC1o92LNrw+mHorcZy/sXvVH4b5xtUVQbP86zswhi7N5g+uy9o8sa77r/iiGZeqj e5Ay7Ni3kN0ufLL5Y9RTbkK7tPm/vNf/iYDZGoGbSPU4/gu+582Hq8NdwcsVzm8ZuqTk WZwg==
X-Gm-Message-State: AOAM531ipIbQtC1jwphcMimbcctvDKn9W17dl25u06NQZnbtBUzrbmvq eXeItWVh7zyR4BFcSk8mgqvei9zAbI/LgYIZHQy89w==
X-Google-Smtp-Source: ABdhPJzyNegD2Ok6cRLjJx/31v1kEzGGDQupOepwr02XofuyEKXVr7s+H6VMO/saYdbEuxI/X4OK8DCpFZy8k4EiJ0o=
X-Received: by 2002:ab0:232:: with SMTP id 47mr27813920uas.48.1593808775467; Fri, 03 Jul 2020 13:39:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <20200703175942.1D0441C485EE@ary.qy>
In-Reply-To: <20200703175942.1D0441C485EE@ary.qy>
From: Brian Dickson <>
Date: Fri, 3 Jul 2020 13:39:24 -0700
Message-ID: <>
To: John Levine <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="000000000000e6d69f05a98f85df"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
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: Fri, 03 Jul 2020 20:39:38 -0000

On Fri, Jul 3, 2020 at 10:59 AM John Levine <> wrote:

> In article <
>> 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?

It makes clear the difference between implied and inferred.
The flag clearly indicates that some glue which would otherwise be
considered necessary has not been sent.
It simplifies the implementation on the receiver's side: no flag, all glue
was sent; flag, some glue is missing.
The recipient never has to determine whether there should be glue or not,
including whether the sender is a busted implementation or zone.
The recipient has a clear path of action, if it is unable to contact any of
the name servers from the referral due to missing glue: ask again (over

Additionally, the flag would signal compliance with updated 1035, for
starters. The uptake on the clarified 1035 won't be instantaneous or
universal, so it makes it possible to correctly infer whether a server is
doing things the new way or not.
Also, it would facilitate lower effort in figuring out if a TC is referral
related or not, which could be important for implementers/operators doing
large scale stuff.
And lastly, it would strongly encourage anyone not currently doing the
partial glue usage thing, to do so.

Most importantly, this is all about interoperability, including not just
the wire format but the operational signaling.
Not everyone will implement things the same way, but at least they will
have a signal about how the other party is doing what they are doing.