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

Shumon Huque <> Tue, 27 July 2021 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F21583A101C for <>; Tue, 27 Jul 2021 16:26:08 -0700 (PDT)
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 ufMoWUdPKeXh for <>; Tue, 27 Jul 2021 16:26:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED0623A0882 for <>; Tue, 27 Jul 2021 16:25:29 -0700 (PDT)
Received: by with SMTP id r16so656161edt.7 for <>; Tue, 27 Jul 2021 16:25:29 -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=GqlFRJz+z9LVdKFulGk0mAyXfdwzfm7p+mN4Mq0WxGQ=; b=tYlFt0l5fBIvigntc6gX/91BiBXxNqSNaankSrLxjQNsIIuVOhKUVC4QVLxAvesrOb lxgWGGjfB9ZiLHXkLi1pL0A0LHKRJLa9X1JBvH7YifvkF7SUHlCjw3avZsvxg9vE79zH gUQ4cLFkvp0vmSI+ANQ2SUtjsTOuqW+deRaQkjMa30llPVe4uCQ0eiTSiStFzWljJiqQ eBNcoDT1dlecGQ8wqFQ1Qoj3wWoc2rYyxWfdhMuRDDJFWbnN2owKxTteuytz71JJ+amT brk11ptTtcm3W0WWTARqAH73sbAoMLxhn8/gXY+c7r4JX+NV30BC5MyRcs4s8IvfGKLr PhEg==
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=GqlFRJz+z9LVdKFulGk0mAyXfdwzfm7p+mN4Mq0WxGQ=; b=Rn2gABIkT/Y8WrW/WzMgtrEd60XUSx8bAq/rn0HAwFe2yB0dxEijUL/0xT+9jXf6eF sG3/jOIw2zGBDf5WncCX4Kx+zAfD+sa+YN10WJukv/LiKxP8gVh9LJbN591txcTz0vAn fJA5u/dfcoXaKcwvu8I7jwbUrHWtQ+PqAlhbonGREiciP1z69l6OlwG8FxozYaTzM2z0 //RwAECmslGL+ZsFoCEqeJq8SAxO2mserJsfhvT1/CV4fYKv+/L8D9S7bEZ0/WXOiuRi Cm4A1dtSQnOEUyLYjZuOxzp0s4lvyx1g0hgHQAqCbuKNI/JenuqZAj3/TmTj09XY4yzt jnWA==
X-Gm-Message-State: AOAM530q0f0h8trkAvGwECEWRUg0EqrRA3zfwSURntGFvojiAIZjMjMA 5Tw0CtNdh8Vuz5jIKzASUBW3lO+2ramAYv8qCAg=
X-Google-Smtp-Source: ABdhPJyaYOAGsj1mCDRu0MyT46S0d735TJag1lEGsTAQuyjBlITDA82vcBJQDkjOv5BrGFw4gDRR1vWH5Twxifv3CkU=
X-Received: by 2002:aa7:d395:: with SMTP id x21mr30293189edq.98.1627428327827; Tue, 27 Jul 2021 16:25:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210727201504.2939B25365A4@ary.qy>
In-Reply-To: <20210727201504.2939B25365A4@ary.qy>
From: Shumon Huque <>
Date: Tue, 27 Jul 2021 19:25:16 -0400
Message-ID: <>
To: John Levine <>
Cc: " WG" <>, Puneet Sood <>
Content-Type: multipart/alternative; boundary="00000000000060acb305c8232ffe"
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 23:26:14 -0000

On Tue, Jul 27, 2021 at 4:16 PM John Levine <> wrote:

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

Just to make sure we're talking about the same thing, the definition of
sibling glue is glue from another zone delegated from the same parent.
I'm mentioning this because there appeared to be confusion during
yesterday's meeting with the other case of cross zone glue from different
parents with circular dependence, a configuration which we explicitly say
cannot reliably work (and ultimately removed from the draft).

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
are required or not.

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