[DNSOP] NS2/NS2T proper locations

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 14 April 2020 19:36 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 98BFF3A0DA1 for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 12:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fnvozlZxlETx for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 12:36:01 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CE63A0DA0 for <dnsop@ietf.org>; Tue, 14 Apr 2020 12:36:01 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id u11so734985vsu.10 for <dnsop@ietf.org>; Tue, 14 Apr 2020 12:36:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E4GYzAXHslWsR3q7RZa7eohRjTrtleJjvasbW2IdG7g=; b=p/URZSLYtWxneFeAvaIXfIqBNzBgBNxlEjIskGLvThtM62ywoXO6O8LjKfZdAu8cJ1 h1VGeVmSzru50cbD2qKi204ZigOmfJlKu/gqh3HCF9/O4Oh+lvEAHNwFO80DbvfuXnJs ZuCnr+vi52SbVGc32kB+HUB0I8o+7tI42N4rZPtoAEdBI6Khnjr44aYoHc5LznoXvsIk vQ+X0k+skq1t2oR2C0R2BUE6mAHCIU6pwb9LySKYPm6ygQjpTn90LePmEyToMVv2D6qi 9VYFeUsK4mLc3cc83C1jxRD1W0m973Qr27pBi2/ru6f418N3Iw5E2a4wei5JqFicMWYQ KxTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=E4GYzAXHslWsR3q7RZa7eohRjTrtleJjvasbW2IdG7g=; b=BPw4X0DfpGB1aQ2JPJzwvunIdHeVcqgm6P4dqLWJZfAccoe1c8s3eyk+AYn7p7eBxj A/OrHxKxjNbmA3UJxD6zg0YsvmWjYVCp0wd8Zt6X/SVNNdkXzsA6NiD1EF0pRECoEZDn /htznutqzyi2pSAXm9b8th0NO3Y+gnE94M411TtIKRhoV6ef+AbOYaFX3BRi/nwfXjV5 og7OIdNOS6jjuR8mwtNTd/rpyjyjYfsjf9rJ4Ht2/S9vinuZYdMxEe7nFzGNVlZHYIws PXuKOi7x2JHEsnckO14UOvo62VVqSdHonqvGUJsOj6lk9NUwNc24RffoYoQ4dPKsx6JQ aH8g==
X-Gm-Message-State: AGi0PuaYKDHq2rlK4fDnUCSUF0WXFoRenYqxHaCK+D8OUzbKKwaNLX2g JGUTO9pRg+Om/6eeGy03D1tcw4dZmUKF08E9upUNXg==
X-Google-Smtp-Source: APiQypKFoIJPVbbVlRCW1xQWe3jIUf+efZ3bO6D2mIxKU9hP6ZHeZIFq2SiZZzWIFssQu6jnojgSCQklHL6ij6wg+DI=
X-Received: by 2002:a67:fa0d:: with SMTP id i13mr1658342vsq.219.1586892960245; Tue, 14 Apr 2020 12:36:00 -0700 (PDT)
MIME-Version: 1.0
References: <060513e7-742d-6de9-cf16-c367fbb13845@redbarn.org>
In-Reply-To: <060513e7-742d-6de9-cf16-c367fbb13845@redbarn.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 14 Apr 2020 12:35:49 -0700
Message-ID: <CAH1iCip9048L-PPPVrYvaAV2cQaJzzfVC297HEXWW44jOUtWFg@mail.gmail.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000312a4305a3454fc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mhsdvaIkPriOzwtcT6s78JAyQL4>
Subject: [DNSOP] NS2/NS2T proper locations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 19:36:04 -0000

On Tue, Apr 14, 2020 at 8:44 AM Paul Vixie <paul@redbarn.org> wrote:

> today it was proposed that NS2 be added as a new record-set type that
> could exist in either the parent or the child, similar to NS, and
> reminding several of us about the DS debacle.
Would the authors of that draft please post into this mailing list,
including asking for comments etc?

Here's my view on this:
If there is a parent/child delegation NS set, which include the names of
nameservers that are not strictly in-bailiwick (i.e. inside the namespace
of the child zone), the NS2/NS2T do NOT belong on either side of the zone

For those cases, the ONLY place that makes any sense is WITHIN the zone(s)
containing the nameserver name(s).

It would make sense to keep this consistent between the in-bailiwick and
out-of-bailiwick cases, so for that reason I propose the use of either in
the child zone itself, or the nephew zone that Paul suggested.

So, specifically, if the example use case is:

example.com NS ns1.example.net

then the placement of the NS2/NS2T records (regardless of content, form, or
anything else) should be as follows:
in zone example.net:
ns1.example.net A <IPv4 address>
ns1.example.net AAAA <IPv6 address>
ns1.example.net NS2 <whatever is needed for the NS2 functionality>

This is the ONLY way that decouples the incremental changes desired from
updates to the authoritative information that is associated with the
nameserver's functionality (including what protocol it serves).

Nameservers do not receive queries on a name basis, only on an IP basis.
They can answer differently for the content of zones, but there is nothing
analogous to SNI to indicate the QNAME prior to the connection being

Plus, scaling. Maintaining NS and NS2 and NS2T records in parallel is akin
to maintaining what amounts to a bazillion glue records, when glue is not
technically required for same-TLD NS names.