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

Paul Vixie <> Wed, 01 July 2020 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 919713A0C2A for <>; Wed, 1 Jul 2020 12:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wJ6rdoJkEHGL for <>; Wed, 1 Jul 2020 12:20:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 597F73A0C28 for <>; Wed, 1 Jul 2020 12:20:38 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPSA id 43CE6B0588; Wed, 1 Jul 2020 19:20:36 +0000 (UTC)
From: Paul Vixie <>
Cc: Jan =?utf-8?B?VsSNZWzDoWs=?= <>
Date: Wed, 01 Jul 2020 19:20:34 +0000
Message-ID: <9056955.dJ39pTEj9z@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.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, 01 Jul 2020 19:20:40 -0000

On Wednesday, 1 July 2020 09:41:49 UTC Jan Včelák wrote:
> ...
> We just opened this discussion internally at NS1 because we serve some
> zones with more than 10 NS records where each NS requires glue and our
> proprietary server by design adds glue only for the first four NS
> records. We are discussing if this is correct behavior if it needs to
> be revisited.

i think if you're using round robin or random selection, a subset is fine. if 
we had to codify this practice, i'd ask that at least two address records of 
each available kind be included (so, two AAAA's, two A's) or else set TC=1.

> I also think there is another proprietary implementation of an
> authoritative server in the wild which implements similar policy. It
> picks a small random subset of the NS records and adds A/AAAA just for
> these names. If the QNAME matches a name in the NS, A/AAAA for that NS
> is always included. I find this pretty smart.

RRsets shall not be divided. either send all the NS records, or none (TC=1).