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

Geoff Huston <> Wed, 28 July 2021 06:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58F603A1F6A for <>; Tue, 27 Jul 2021 23:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Xd6bN41FVM1v for <>; Tue, 27 Jul 2021 23:26:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDE133A1F69 for <>; Tue, 27 Jul 2021 23:26:59 -0700 (PDT)
Received: by with SMTP id c16so1443108plh.7 for <>; Tue, 27 Jul 2021 23:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k2/Lki/cKeKIWlCdMjoVjp600Oa6DdNcZ6UGOVPXE8w=; b=aM3EgdDACBKKMzpmETEBOs6W33XyxZau+aLKZOKz+9fQV8KRiWFbzJiGFzqmnHm5du 2pYba50hPtdc9NhM5tu1A42EbDT7XF1SJat9syXdhgJm/rjJYIqGilUKZt0bNS9lYblG Mr0eW4lGf17TXOJKly3XnGIE86OMk/d4/dTLwK4M20LvpDEfACA7sVMZvX29gtJig0Ta 7P3Kg53N+3HE9X4TW1QcZXgnxlmLbuOmv1pnjOpF5zSThGSqmfODlkp/GYE3p4wh369v ePQV2SaQ//VARNakVBYU5tFGi/9i6OkgA+rMDO9H07ILEQZj7irDuk3B7JyKcgvfmO8q nxKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k2/Lki/cKeKIWlCdMjoVjp600Oa6DdNcZ6UGOVPXE8w=; b=GU6QoQSrAIVNWT3T5rzW4es/pJn4vdvbN9+AQqU7cTlPgU19KF9qFD9B/5nj7ghows 9KKV3dUDysCj5Fi6l0auX68C697cXwjt7R/RTTt6Gs8ZZ6xS9U2VcanED1XnGflsLZzR 3nvfJXAly/jbFlTi/2IZmTuiNy16+7tT7ikUsrHrbP6HGC6oQDQ1K34UMu9FC8LHOTkF S88Hq+WamxoM/SzHMqZnKmqaDFEbEuQW0pe+YXEJunyirZS+KSlT6fMTNpTI5AF6Mj1z CKTJ4kq6CC7TTXsLr5/av+EsyK1VsWlbUbUGbn4eIxgQKrwT1CH+rVzxl2fSSRgD3BmD /Dsw==
X-Gm-Message-State: AOAM530P4V7Iv1AfFFX/e7Syu6r1MmI0Ib8OjT1TH9K5G8quoCooXjON nEFyKmrsws5H9M/ghnBN+gA=
X-Google-Smtp-Source: ABdhPJyL8zfcP+aD349qHNY/AMmYp8J3BnlSygD75nAYHrv3IO6JzWfOP7LIkw7+W4e9g8l7saKxdw==
X-Received: by 2002:a63:5153:: with SMTP id r19mr27774964pgl.56.1627453618681; Tue, 27 Jul 2021 23:26:58 -0700 (PDT)
Received: from ( [2001:44b8:110b:5100:440:191b:b1e3:3449]) by with ESMTPSA id a20sm5411432pfv.101.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jul 2021 23:26:58 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Geoff Huston <>
In-Reply-To: <>
Date: Wed, 28 Jul 2021 16:26:53 +1000
Cc: John Levine <>, " WG" <>, Puneet Sood <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20210727201504.2939B25365A4@ary.qy> <>
To: Shumon Huque <>
X-Mailer: Apple Mail (2.3654.
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: Wed, 28 Jul 2021 06:27:04 -0000

tldr - suggest cutting sections 4 and 5 completely and advancing with what’s left!

> On 28 Jul 2021, at 9:25 am, Shumon Huque <> wrote:
> For sibling glue, part of our rationale was indeed to cover the cases where 
> it is required for resolution (and not just an optimization). Those configs
> usually do involve a cycle. But our goal was not to encourage or
> discourage such configurations, but to make it easier for implementers
> of authoritative servers. Since many implementations already provide
> sibling glue, it's easier to just provide them all, rather than figure out which
> are required or not.

The language of sections 2 and 3 are clear and purposeful. For DNS resolution to work
the glue records for “in-balliwick” name servers of a zone MUST be provided as glue records
in a DNS response. clear.

Section 4 in Sibling Glue ther heads into a different direction It notes that “In many
cases, these are not strictly required for resolution” but then simply adds them as a MUST 
be returned in referral responses without any apparent justification.

If this is an optimisation technique, then SHOULD or MAY, with some explanation, makes
more sense to me in this document. But frankly even this seems to be a different 
recommendation (and a different document) to me. 

Up to section 4, this document appears to be stating clearly an omission in the current
DNS spec, namely that all in-bailiwick name server names MUST be present as a Glue record in
a referral response for resolution to work.

And while I think about it, why not just refer to in-baliwick, as defined in RFC8499?

i.e. amend section 3 to read:...

3. Recommendations

This document clarifies RFC1034 in that in-bailiwick [RFC8499] glue (being part of all
available glue records) MUST be returned in referral responses, and there is a requirement
to set TC=1 if all in-bailiwick glue cannot fit in the response.

> >* 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.
> This is a political question, not a technical one. If the DNS operator
> has external knowledge that the orphan's domain has not been delegated
> to someone else, you can make a case to leave the glue. The usual
> example is a name in a TLD which has expired but is still in the grace period,
> but it can happen anywhere someone delegates names; I run registries
> at the third level like
> I don't see how we can offer any more than general and vague advice here.
> Yeah, after thinking about this since yesterday, I'm now a little skeptical that we
> should cover this potentially thorny topic.

Section 5 deviates away from protocol requirements into registry practice and
the deviation appears to be at best a somewhat random thought!

It makes no sense to me to even include sections 4 or  5 in this document.