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

Shumon Huque <> Wed, 28 July 2021 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C2993A2143 for <>; Wed, 28 Jul 2021 14:23:31 -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 7EAiq5bDvJGu for <>; Wed, 28 Jul 2021 14:23:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54E5D3A2142 for <>; Wed, 28 Jul 2021 14:23:26 -0700 (PDT)
Received: by with SMTP id x14so5102262edr.12 for <>; Wed, 28 Jul 2021 14:23:26 -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=jors6WZ+hs6fGQPtxEG0SJV8NWbt8+F9F4SCgyQPIA4=; b=i/ZtSgH1vF7V9LhiGD7e5Pv/tkh0Y/IyDJE6nWfJwtpHltBEombUzyOjdCqF9M/kgl xT4P6Ox/hxMeRgVmfDJP0+3ppwIfYQYKpL58n1nexx+6QgrmFKcsqpeV2epWQU8fnGfH EUEgdmkHv7OdHqDgk68irA8ZOxt4dgzH62eApETtEEiQ3OBTZrj3m28mC4a7bCgsEAWO d5TEnoOh6aIyi/BI/tzgWxDoFND6cSssr7Tl/MxoxHHpiIvvGKZzUs3z3Q4hXC4/1C9Y r0MJABNB/I0WLzSbaIkYKm84ck+orKHJVQj7fqtnMEOZGZcEieMap9QGL8wZwavC9Rt0 e2+w==
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=jors6WZ+hs6fGQPtxEG0SJV8NWbt8+F9F4SCgyQPIA4=; b=br03BcJvS5vJndgdGjs8aDhD4ixz+WMEkj9tNlxNOowxjZAP1QL80ki/1HPDU34x0Q PoOEwoDSYZTxKAU9OtgbUHuchee3CuN6w6M8lOS9JBdtvktmHCEXteVL+bgFOiTnyXbH bK3WhUfDoHeerbyrQlR6Kb6igEGa2KCTiJYn+vX+6WogRQLUnyOSL416PwDQ7OH+4JHX a9aWOMQvsznSgZkKw5xrz1Uch8asqd1Nl09sg6Hp2kEohjqsbFHCPUq114APBpgdQeLQ 73SCqplbxo9LPc4FcQQApHHJ2Pf1iDVKvkZBNBjCIWdAHtABiDUjYJb/P0c8tH/XLJpl TC2g==
X-Gm-Message-State: AOAM533fMDC91yEQGCE+x3um8lS3L7bXzDdUlYsmqdMsxd03RBA67ibN lSq2Vo9904aZ8kXb7A9czZOU6WogRz1LV7n2maM=
X-Google-Smtp-Source: ABdhPJz4t/BfqIwaJcNhN9KvOuySqPXSyJRx8cQx/Ihy3Vgy2uVDsLNU3i5Z/YBNTix6ue1dspOTUj3hf7AQehZqwAQ=
X-Received: by 2002:a05:6402:270d:: with SMTP id y13mr2222288edd.66.1627507403787; Wed, 28 Jul 2021 14:23:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210727201504.2939B25365A4@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Wed, 28 Jul 2021 17:23:12 -0400
Message-ID: <>
To: John R Levine <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="000000000000ac118605c8359837"
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 21:23:31 -0000

On Wed, Jul 28, 2021 at 12:20 PM John R Levine <> wrote:

> On Wed, 28 Jul 2021, Shumon Huque wrote:
> > Sibling glue was already covered in RFC 1034 (even though there was no
> term
> > for it). ...
> Sure, but we've been cleaning up the ambiguities and errors in 1034 for 30
> years.  A straightforward reading of that paragraph also gives you the
> Kaminsky attack.

The Kaminsky attack can redirect in-bailiwick nameserver names just as
easily as out-of-bailiwick. The defenses against it are (1) make it harder
(source port randomization etc), or (2) deploy DNSSEC. Glue is
anyway, so the only real defense against misdirection is DNSSEC and
a secure referral to the child.

Also, sibling glue is easier to accept for a paranoid resolver. It may not
be in-bailiwick (i.e. a subdomain) of the "delegated zone", but it is in-
bailiwick of the "delegating zone". If a paranoid resolver, ignores and
re-queries for the sibling names, it ends up requerying the same authority
and then getting a response with in-bailiwick glue. So, it just did a bunch
of additional work for not much benefit in my opinion.

But this is an interesting topic. What do resolver implementations do
when presented with sibling glue? Can implementers comment? I think
this can help inform what we recommend in the draft.

"MUST" in RFC-ese means you have to do something in order to interoperate.
> I think we all agree that the DNS will operate fine without sibling glue,
> other than NS loops which I personally don't care about. That makes it at
> most a MAY, and I agree with Geoff's reasons to take it out completely.

I don't agree we should take it out, since as I pointed out, RFC 1034
covers this type of glue (without giving it a name), and the algorithm will
include it if it is there. If there is a compelling security or other
reason to
remove that, someone should make that case (I haven't heard it yet).

But it seems we will not get consensus on truncating if sibling glue doesn't
fit, so I'm okay with relaxing that requirement.