On Tue, Apr 14, 2020 at 8:44 AM Paul Vixie <[email protected]> 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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
