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

Brian Dickson <> Fri, 12 March 2021 03:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81ABC3A1BAD for <>; Thu, 11 Mar 2021 19:11:25 -0800 (PST)
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 V2VSawad8Ma4 for <>; Thu, 11 Mar 2021 19:11:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 635F33A1BA8 for <>; Thu, 11 Mar 2021 19:11:23 -0800 (PST)
Received: by with SMTP id h34so1301625uah.5 for <>; Thu, 11 Mar 2021 19:11:23 -0800 (PST)
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=vfOZJh1jYcuPfFJABdrpdpmyWZ9TpObu8DKSYhT4FCQ=; b=DgyB9dFVYHjygYGiLOySZoS9xrVzutq3C6rRLVpfpiE9Wlrb5zuwWERN8DjIodfegf RHsVt09KEipAiZDAYLhB+pcuZktp8WxIx05NzSYmgvTz9RfErBU3vdgXViH0wo1QJd6N TtRbcyKRXX2Y3WGIQNfYVK+/oTLE1EXEMudaC0cqO/QRnLg/ymUgLh3+cpvsI5O6glcV qHpODD+bF7Y+83BI2qMkM351m7s2hYOA594/jxrJQjZzOZXcM1uh1PRTPVX7RoGfZOhH USAw/VNFl1nruig0mGHKBfR2PMym+T9TvJfM3jVUpi9MRh6Hd1f0+Iv9kvpqJ9BYVI3P pZsw==
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=vfOZJh1jYcuPfFJABdrpdpmyWZ9TpObu8DKSYhT4FCQ=; b=SoNk1J3hpvfeGrj1IKQmvMIwjjNs0Wa15+LUZCgymd3cu/R1GVHzjclOjYS+57m+EO dRXTAzyH+rCX1zny+tzxmZ01vvFSsXroE/6BpIio4REtDB8T4x1n1HIrKnWapZ1hyuA4 GF4AuCi4BRkQpcnc6987Vyva8mU1+j+0jOW9mw+Edmg26ql+Zznv+IERATRRJBrj5zMk Y3Tf5PrGZLcjCIa3q2oB8yGFQWmj9NgkcTfyN5VYOee0m0g4uHWVAK1Pe7J8G6SQrL5p A7ofvLKRSOTcpFVYuAE9pHmi1snl2PGhKcfslacpA+yAxoFj4bkuI6XBFivj++qw69IA YWYA==
X-Gm-Message-State: AOAM531n8QHgsw0IHPOEa2Zu5Zu0nNi7AIRHxQOQ+eUB+6g716cqa8gE WNGmr+iBbm+1O6/oDDy2Vf1Cdfmr1Fyn5ASvmKI=
X-Google-Smtp-Source: ABdhPJzHv+SHayrvdBVprpPMsx2JhxzvrHpX/InyGuX4WhXpQI2qrh0zn73AIqYu/uNrODt775vXS5I4FvgUkfeQADA=
X-Received: by 2002:ab0:7035:: with SMTP id u21mr7415093ual.62.1615518682013; Thu, 11 Mar 2021 19:11:22 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 11 Mar 2021 19:11:11 -0800
Message-ID: <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary="0000000000002b642305bd4e413b"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] 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, 12 Mar 2021 03:11:26 -0000

>From the status updates today, I see this draft has expired. I really like
it (and it is quite simple), and would like to see it picked up and
completed (adopted, rough consensus reached, published).

Having reread it and the discussion, I am wondering if useful guidance can
be provided regarding the TC=1 and records added.

If as much glue as will fit is included, but not all glue fits, add all the
glue that fits, and set TC=1.
The resolver SHOULD attempt to use the available glue, but retry over TCP
if none of the servers found via the available glue respond.
I.e. How is TC=1 interpreted currently by different implementations, and is
THAT an issue that could/should be clarified, either in this document, or
in a separate document?

Is it necessary (at all) to mention keeping the glue that fits before
setting TC=1?
I don't think so, but maybe some commentary to that effect would be helpful?


On Fri, Jun 5, 2020 at 11:57 AM Paul Hoffman <> wrote:

> On Jun 5, 2020, at 10:37 AM, Wessels, Duane <dwessels=
>> wrote:
> >
> > The essence of this draft is the addition of once sentence to RFC 1034:
> >
> >  "If glue RRs do not fit set TC=1 in the header."
> >
> > I worry that this is too ambiguous.  Does it mean all glue?  One glue?
> As much as will fit?
> >
> > AFAIK most software today is designed to fill up the additional section
> with as much glue as possible.  Is the name server allowed to add only some
> glue RRs, even if more would fit (without truncating, or in a TCP response)?
> >
> > Is the name server allowed to fill the additional with all records of
> one type, AAAA or A, when the resolver might only have connectivity of the
> other type?
> >
> > There is also the question of in-domain vs sibling-domain glue.  RFC
> 8499 (Terminology) notes that "Glue records for sibling domains are
> allowed, but not necessary."  Should in-domain glue take priority over
> sibling-domain glue?  Can sibling-domain glue be omitted even if it would
> fit?
> The current document is indeed ambiguous. I propose that it be changed to:
>    If all glue RRs do not fit, set TC=1 in the header.
> Given Duane's questions above, we can do better with another change to RFC
> 1034 in this document. In this same paragraph from RFC 1034, it says:
>    Put whatever addresses are available into the additional
>    section, using glue RRs if the addresses are not available from
>    authoritative data or the cache.
> That could instead be:
>    Put at least one available address into the additional
>    section, using glue RRs if the addresses are not available from
>    authoritative data or the cache.
> I don't think it is worthwhile to go into more detail about how to choose
> how many to put in (because RFC 1034 didn't explicitly talk about message
> size), or the mix of A and AAAA (because RFC 1034 didn't anticipate more
> than one address type).
> --Paul Hoffman_______________________________________________
> DNSOP mailing list