[DNSOP] NS2/NS2T proper locations

[Brian Dickson <[e-mail]>]

On Tue, Apr 14, 2020 at 8:44 AM Paul Vixie <[e-mail]> 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
cut.

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

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.

Brian