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

John Levine <> Tue, 27 July 2021 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1480F3A10D2 for <>; Tue, 27 Jul 2021 13:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=OO1U0FF6; dkim=pass (2048-bit key) header.b=mYqA8ErF
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8KS43d9ZloQI for <>; Tue, 27 Jul 2021 13:15:07 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 1FCEC3A10D0 for <>; Tue, 27 Jul 2021 13:15:06 -0700 (PDT)
Received: (qmail 94535 invoked from network); 27 Jul 2021 20:15:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17145.61006948.k2107; bh=L+O7GBzNMMR57vLXk/Aj8PV1iK9+h93sMoMDypAWa5M=; b=OO1U0FF62jje7o33WCAkMjIA1PVN4Ikbe+vEWVxGLNz6iosZPoDrrlCOqFE5gosNjjEmIcGasAIoEzv99C+luFjX8tDIrwO+OhV28CffjUFiqjsVc1sFvrtUVlJv0xiyN7zxsYTv2tohL0gjc0m+j+SoDJJbk8F7zPmrbbm9e1IAIyHQ+1lXwgjHXvCJXQUj3FfQpA6m97BvVFa0oKfFVwYydnes/M8uL9KOMmZEKmCY1mvo5d/bRwjcweuxaGdQQqim03pguJRqnQAb63+mZ1/DSRm/ndnDud8zmQmTNUKC6vRYEARgmR2wSu2HYjBAtfGTfnOED5RYkWI40V4Jlg==
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17145.61006948.k2107; bh=L+O7GBzNMMR57vLXk/Aj8PV1iK9+h93sMoMDypAWa5M=; b=mYqA8ErF9UU6FbEyYQtjjPl7b85+xNX+xTVHydFoIJKygQjIzOAQENGXsdQrdzYq6D2o9dYWWZ+UoHljEPLWmA6JvUtxl/iPsOjtb1BbxMeSy5e+En8KxPIHNtHyxrKk5OsH86aijGOhETj3r2d3qBqUVp6oOLHSG0uEKsO/lIxiMxRZx/vZh7VLIbYFiVs3QUQTj5tqEya/TyX1D55F9PxL4ZDbwZFKxqAAr/Ncs+23zmkX2NS2h4LODVNiPVZJfYiQeLuMcLpPmI/1EXnr+pZ6OUy+C+RXGFQvDKsIEwM9v+9tDZcKQ8UZVZamRKE2/a+3diC63EkeymDQv2a/KQ==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Jul 2021 20:15:04 -0000
Received: by ary.qy (Postfix, from userid 501) id 2939B25365A4; Tue, 27 Jul 2021 16:15:03 -0400 (EDT)
Date: Tue, 27 Jul 2021 16:15:03 -0400
Message-Id: <20210727201504.2939B25365A4@ary.qy>
From: John Levine <>
In-Reply-To: <>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
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 20:15:13 -0000

It appears that Puneet Sood  <> said:
>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. ...

I would prefer we completely remove the sibling glue, or at most move
it to an appendix of possbily useful minor improvements.

We say that authoritative servers MUST return all the glue, which is true
for real glue, but not true for sibling glue (unless the sibling is in
a loop which is not something to encourage.)  Let's not confuse people,

>* 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.