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

Shumon Huque <> Wed, 28 July 2021 11:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D6213A0802 for <>; Wed, 28 Jul 2021 04:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 J7MxAQiX3X3g for <>; Wed, 28 Jul 2021 04:05:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B4683A07F8 for <>; Wed, 28 Jul 2021 04:05:07 -0700 (PDT)
Received: by with SMTP id x90so2603918ede.8 for <>; Wed, 28 Jul 2021 04:05:06 -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=qNQT9/RmEy24q+FLcNwuXlvSepUeHAcSJXDmb+txnoQ=; b=WxRt3mPR4v8VXP8Tc1nVNoAlP63vj0n9U4r2Rbcq4Mxjytty5qSHiUjOUxbZGSYhUo o/6zyGqd7AZ6sSSu19B4oOJij+olbSUb3N9iW6S8yukDkpOERVyXLZHrFcGwk17IS+zJ husIz+Sb2RubsOql7MVNDWkdZxTfYFbIGKcG+KK+wbVBd5tGEgPbqUIz/sHqhobAzX3Q lH/FXziDbX/507DqU30TUsosKZ79HsTFVLd5eyzW7gXme86zeH+fAW3xrBeq1LkpgPKS lMeC4DD7U8OvbbFOjJQo8Gq5Kpw5d3vn8h3IXkKQ33eS41n0udN/2KFwFW0cx2E6+VWZ KP5g==
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=qNQT9/RmEy24q+FLcNwuXlvSepUeHAcSJXDmb+txnoQ=; b=DaEB+Y5LX+/4EB9dGgRgEouafRdhxcwBhfFJxbh71lu+x6v/Xk3uxwpappsJRrPwiF Uz8Rbig+HXCRoaNMA1sjaeDrE3mFQ3PbTVqW2lpaI/dT4lG5awtR5EbUk8IQKP1e5Pzh KC062MitjLlSKS7uLaJH+gt3VgZY2m+jDDpRGRw2JkyxTc1V4j4g/LxiTXoqFagyga4y Z5J0woCNak2okwsTsucURWbvzUtoE4TCZbMKnuyFuuUkcrNxmr/z60qzt5CdxYN5Vqp9 Xyfd17pwVb7E14KQfXoJfkmgCEzgrllurJ4Z1y1ltL80W30DXyGDXPdIMkU+56b72ghF sW7A==
X-Gm-Message-State: AOAM5300UwyIWuLAP7EpHSDAtCiHlryrLwhB3ZvMgY6UDOaG1SzdoSnF YVN0/qsVWk5y/u27NuwAEGXgvJIclh5QStoweJc=
X-Google-Smtp-Source: ABdhPJzxzvCR8KW3eIjJD72LV1gHpOxqaPBZwtWw67LGuGtQsP8S/6UkbiFKZqfnKcOnI/+jOUGCkLiRqcqocBnIybU=
X-Received: by 2002:a05:6402:3096:: with SMTP id de22mr33384545edb.91.1627470303881; Wed, 28 Jul 2021 04:05:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210727201504.2939B25365A4@ary.qy> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Wed, 28 Jul 2021 07:04:52 -0400
Message-ID: <>
To: Geoff Huston <>
Cc: John Levine <>, " WG" <>, Puneet Sood <>
Content-Type: multipart/alternative; boundary="000000000000586e4a05c82cf598"
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 11:05:10 -0000

On Wed, Jul 28, 2021 at 2:26 AM Geoff Huston <> wrote:

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

Sibling glue was already covered in RFC 1034 (even though there was no term
for it). To quote
(Section 4.3.2, 3b):

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

Text was not as precise back then, but my reading of this is that the
nameserver should
put "whatever" addresses it has in the additional section. It says to
include glue RRs (defined
earlier as data that allows access to subzones), but doesn't differentiate
between glue below
the zone cut of the referral or glue it has for other subzones.

(An earlier section does say that glue is only necessary if it's below the
cut, but the
intent of the paragraph seems clear. Put "whatever" addresses I have in the
referral. And
"only necessary" doesn't address the corner cases we've described where
sibling glue is
required for resolution).

This paragraph also says to include addresses it may have from
authoritative data, which is
okay, but that's not glue, so we didn't cover it in the draft.

It also says 'addresses from cache' (mixed mode recursive/authoritative
servers were more
common then). This phrase should be deprecated in my opinion. Cached
addresses may
include things that are certainly out of bailiwick of the delegating zone,
and I assume would
likely be disregarded by most paranoid resolvers.