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

Puneet Sood <> Tue, 27 July 2021 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 625F63A0E9B for <>; Tue, 27 Jul 2021 08:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.098
X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Tk-iMhLs13FJ for <>; Tue, 27 Jul 2021 08:42:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D96E13A0E94 for <>; Tue, 27 Jul 2021 08:42:35 -0700 (PDT)
Received: by with SMTP id n11so7872953wmd.2 for <>; Tue, 27 Jul 2021 08:42:35 -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; bh=b0tprhdq9rKqs6PjhnswA+Oc7yUHRBCsJqDEINyf0Tg=; b=wOGtqgW/11jQKoYdZuiXV1KuV6DqUSgT0PyK/RNS5TH81OjGLJUOoQrx2ZABC+Xgz+ hqt85lyBTBBS/9NWG51NfMy9PpF5g+o+R2MRDsckaoTVaMPJka6LKfhWfSHgHHa+KbZM +zv0iqjCA9o871MpFD4T9/zWeYFFheJ6iB3HM46ZaV7cXd92ZhYOLG0BhrsBYU52cj2E CJTareAs90pPN6i7wVCzQVmjsHGglqdvpoE/w2LBw066bubG/GkAQkWlnCSeUJMh1gvc NcFaq8SoP4WiVFSzrDN0Q+OFNHn5PUniFqL5f1X4OPqkPnBT4F526YtstdBRD3YStDa8 XWyg==
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; bh=b0tprhdq9rKqs6PjhnswA+Oc7yUHRBCsJqDEINyf0Tg=; b=AOWtEGY5SWWVgGS1MZBmwPZ3GYkvE77ujU9kW6bNc4DPLqKxssgHdNFSziGopA3O7q hn47UUpWjEB5vi4o2Y6RCMnEqGlKQim9oUTt7+ueV08MYwPugjZFfH6Eyq4dltGg4hAD 3+JISxo9Xk5JAW0NBIQFu8UZkVna6d1U0ZZXgHnUAobrHZA+SHyxQv5LBPI84fZfSEnU Yrpdi14fdcMbH31kX+PsXkmxVJupOj2R41gNlKRrrgyuUNqJpmgO/CY+XNuuP2gG6NVH qvjJJCRRO4xBb9FnzC340caLmgB7EoC+uNPK14Em/4QNlBX1Z5HtgmO/Ob7q6tNnrclY OZuA==
X-Gm-Message-State: AOAM530Xt24FTGAsxmw0mfsFg6ax+hHaOuwrVN6lhl3Lwk+f6P4x/e/k 7bCxi5/G/6MD0gdd+CBevxq4FSmIvmFYQ6GQwYeB2kfCQqgJPA==
X-Google-Smtp-Source: ABdhPJxAVI50lomVR4US07JJ8Nv9qjhgU7fEo2IcIw0n95Gc+uGTybGpD4a7Y1qXZ8MjvSFhRE3cn71YlMv3jiZHR7M=
X-Received: by 2002:a1c:46c4:: with SMTP id t187mr4905679wma.64.1627400551560; Tue, 27 Jul 2021 08:42:31 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Tue, 27 Jul 2021 11:42:19 -0400
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.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: Tue, 27 Jul 2021 15:42:40 -0000

Couple of comments and a readability suggestion

* +1 to Geoff Huston's request to provide justification for why
sibling glue is desirable in a response. Also would prefer to not make
it mandatory in a referral response. If the sibling glue is referring
to a dns operator, it is possible that the resolver already has seen
the nameserver names before and has the needed A/AAAA records in
cache. Truncation in this case would require a redundant query.

* Section 5: Promoted or orphan glue
The considerations for handling orphan glue will be different for a
TLD vs a lower level zone within a domain. I would think that orphan
glue in a TLD context should go away when a zone is deleted/expired.
Maybe even have sanity checking to prevent such an operation.

A readability suggestion
* Move the description of all types of glue upfront before getting
into recommendations.
- real glue
- sibling glue
- loops with sibling
- orphaned glue
* Describe the recommendations for including glue.
This should also call out the scenario where different kinds of
glue/referrals are present in a response (glue, sibling glue). This is
implicit in the wording now.


On Mon, Jul 26, 2021 at 5:06 PM <> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>         Title           : Glue In DNS Referral Responses Is Not Optional
>         Authors         : M. Andrews
>                           Shumon Huque
>                           Paul Wouters
>                           Duane Wessels
>         Filename        : draft-ietf-dnsop-glue-is-not-optional-02.txt
>         Pages           : 7
>         Date            : 2021-07-26
> Abstract:
>    The DNS uses glue records to allow iterative clients to find the
>    addresses of nameservers that are contained within a delegated zone.
>    Authoritative Servers are expected to return all available glue
>    records in referrals.  If message size constraints prevent the
>    inclusion of all glue records in a UDP response, the server MUST set
>    the TC flag to inform the client that the response is incomplete, and
>    that the client SHOULD use TCP to retrieve the full response.
> The IETF datatracker status page for this draft is:
> There is also an HTML version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list