Subject: [DNSOP] data at delegation points

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Apr 2020 08:43:59 -0700

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.

DS should never have been placed at the delegation point, and has led to 
a decade or longer of bugs and corner cases and complexity. it ought to 
have been a nephew domain of the delegation point, but, in the parent:

so instead of example.com DS, it should have been example._dnssec.com DS.

this is the approach i suggest for anything like NS2.

-- 
P Vixie

---

From: Jim Reid <[email-masked]>
Date: Tue, 14 Apr 2020 16:54:49 +0100

> On 14 Apr 2020, at 16:43, Paul Vixie <[email-masked]> wrote:
> 

Sadly, that wouldn’t work for thisisaveryveryveryveryveryveryveryveryveryveryveryveryverylong.domain.name

Which really exists. :-)

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 14 Apr 2020 17:57:36 +0200

Moin!

On 14 Apr 2020, at 17:43, Paul Vixie wrote:
> DS should never have been placed at the delegation point, and has led 
> to a decade or longer of bugs and corner cases and complexity. it 
> ought to have been a nephew domain of the delegation point, but, in 
> the parent:
>
Just to clarify if I understand that correct. The DS for example.net 
would be example._dnssec.net DS. Correct? So would you propose to do 
example._ns2.net NS2 to distinguish parent and child NS2 records?

So long
-Ralf
—--
Ralf Weber

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Apr 2020 08:58:10 -0700

> Sadly, that wouldn’t work for thisisaveryveryveryveryveryveryveryveryveryveryveryveryverylong.domain.name

i'm ok with that.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Apr 2020 08:59:05 -0700

> example._ns2.net NS2 to distinguish parent and child NS2 records?

i didn't understand the semantics of having more than one NS2, so i 
don't know.

-- 
P Vixie

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 14 Apr 2020 18:35:01 +0200

Moin!

> i didn't understand the semantics of having more than one NS2, so i 
Mainly because of getting stuff in the parent is hard and starting with 
something in the child is easier. I assume I grasped the DS concept 
correct, so if we put the _ NS2 in the parent up to the root we could 
bootstrap securely in transport and validation from the root down.

So long
-Ralf
—--
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Tue, 14 Apr 2020 12:35:49 -0700

> 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

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2020 17:07:25 -0400

>including asking for comments etc?

I'm not Tim, but the draft is here:

https://datatracker.ietf.org/doc/draft-tapril-ns2/

>Here's my view on this:
>If there is a parent/child delegation NS set, ...

Nope.  Read the draft and find out all about it.

Having read it, I'm not sure how I feel about it.  I understand the
motivation for putting advice in the DNS about which nameservers
support what query protocols, but it seems rather kitchen-sinky.

R's,
John

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 Apr 2020 10:41:20 +0200

DNS friends,

> this is the approach i suggest for anything like NS2.

I think this makes abundant sense.

Some information about delegation clearly belongs in the parent, and 
only in the parent.

NS in the child-but-also the parent was clearly a bit of a bad design. 
DS in the parent-but-kind-of-also-the-child (via DNSKEY records) was an 
attempted step in the right direction, but clearly also a bit of a bad 
design. Paul's proposal (or a similar one) seems like a really good 
approach to me.

We can include something like CDS/CDNSKEY from the very beginning as 
well, as an in-band signaling for parent/child synchronization.

Cheers,

--
Shane

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2020 11:16:20 -0400

In article <[email-masked]> you write:
>reminding several of us about the DS debacle. ...

>so instead of example.com DS, it should have been example._dnssec.com DS.

I take your point but I have a question and a half.

The plan in this draft is that NS2 would eventually replace NS
records.  Hence a zone could have a zone cut at a name that has no NS
records, so the server has to do something like scan the zone when
loaded or updated for NS2 records at names like example._ns2.com and
remember that means that example.com is a zone cut.

Adding to the excitement, NS2 in its current kitchen-sink form
replaces both NS and DS, so the name at the zone cut would not exist
at all.  The server would presumably have to synthesize an ENT there.

Does that seems feasible?  Sensible?

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Apr 2020 21:25:29 +0000

On Wednesday, 15 April 2020 15:16:20 UTC John Levine wrote:
> >...
> The plan in this draft is that NS2 would eventually replace NS records.

if so there's a much larger set of changes we'd have to consider. for one 
thing NS2 should be slabbed (one record containing a compound rdata set); for 
another it would have to incorporate what DS does now (also as a slab). and it 
would move to be delegator-only, not present or relevant at the apex, and 
therefore signed in the parent. i have hesitated to bring any of this up in 
the years since 2003 when it all first came to light, because i thought it 
would take time and attention away from getting DNSSEC deployed. (naive?)

> Hence a zone could have a zone cut at a name that has no NS

if this is meant to replace NS then it would have to be at the zone cut, and 
not a nephew-domain like DS should have been. so, i apparently misheard what 
was said on the dnsop webex about this, and didn't do my assigned reading 
before starting this thread. please accept my apologies.

> Does that seems feasible?  Sensible?

this still doesn't feel like the right era to begin the DNSv2 effort.

-- 
Paul

---

From: "John R Levine" <[email-masked]>
Date: 15 Apr 2020 17:32:48 -0400

> another it would have to incorporate what DS does now (also as a slab).

Take a look at draft-tapril-ns2-00 in which NS2 has ten subfields 
including one for the DS or DNSKEY.  Like I said, it's very kitchen-sinky.

> this still doesn't feel like the right era to begin the DNSv2 effort.

I wouldn't disagree.  I understand the motivation to have some way to say 
above the cut whether the below-cut NS speak DoT or DoH or whatever, but 
this is way more than that.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly