Subject: [DNSOP] Fwd: New Version Notification for draft-tapril-ns2-01.txt

From: "Tim April" <[email-masked]>
Date: Mon, 13 Jul 2020 16:34:27 -0400

Hello DNSOP,

First, apologies for not sending a note like this to the list with the 
-00 version. I reviewed the thread(s) that happened after the last work 
group webexes right after IETF107 and tried to incorporate the feedback 
from the webex and email threads into the latest revision.

A summary of the changes can be found below and also at the end of the 
draft. The primary areas of focus in this update were to remove the 
“kitchen-sinky” ness of the record, (including the removal of the DS 
information) and then adding more clarity around the uses of the record.

* Removed DS and DNSKEY SvcParamFields. Avoids issues with DNSSEC 
signing in the parent.
* Removed IPv{4,6}Hints SvcParamFields. There was a discussion on DNSOP 
about how glue is required
* Updating when to sign the NS2 / NS2T records (removed signing in the 
parent)
* Attempting to clean up the introduction, goals and motivations of the 
document
* Adding a privacy considerations section
* Adding more clarity around when to include/expect the NS2/NS2T records
* Adding this note that CNS2 will not be included in this draft
* Prohibiting NS2 and NS2T from existing at the same name
* Making the statement about the parent records being glue and should 
not be signed

This document is tracked in a GitHub at https://github.com/timapril/ns2.

Questions, Comments,  Reviews, GitHub Issues & Pull Requests and all 
welcome.

Thank You,

--tim

Forwarded message:

> From: [email-masked]
> To: Tim April <[email-masked]>
> Subject: New Version Notification for draft-tapril-ns2-01.txt
> Date: Mon, 13 Jul 2020 13:02:57 -0700
>
> A new version of I-D, draft-tapril-ns2-01.txt
> has been successfully submitted by Tim April and posted to the
> IETF repository.
>
> Name:		draft-tapril-ns2
> Revision:	01
> Title:		Parameterized Nameserver Delegation with NS2 and NS2T
> Document date:	2020-07-13
> Group:		Individual Submission
> Pages:		20
> URL:            
> https://www.ietf.org/internet-drafts/draft-tapril-ns2-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-tapril-ns2/
> Htmlized:       https://tools.ietf.org/html/draft-tapril-ns2-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-tapril-ns2
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-tapril-ns2-01
>
> Abstract:
>    Within the DNS, there is no mechanism for authoritative servers to
>    advertise which transport methods they are capable of.  If secure
>    transport methods are adopted by authoritative operators, transport
>    signaling would be required to negotiate how authoritative servers
>    would be contacted by resolvers.  This document provides two new
>    Resource Record Types, NS2 and NS2T, to facilitate this negotiation
>    by allowing zone owners to signal how the authoritative 
> nameserver(s)
>    for their zone(s) may accept queries.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Jul 2020 17:38:46 -0400

Hi Tim,

I would like to be able to describe authoritative DNS servers with SVCB, so
I think this is a good general direction.  Some questions:

1. Instead of NS2T, could we use SVCB with an _dns prefix label?  (That
would be the logical SVCB mapping for "dns://nsX.example.com", RFC 4501.)
A version of this is proposed in
https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-01#section-5 for
a different purpose, but I think it should work for this too.
2. What's the difference between NS2 in AliasMode and a normal NS?  Is it
strictly a hint that the child zone contains an NS2T?
3. Is there any downgrade defense here, if the parent zone is not
using NS2?  It seems like an intermediary who can strip the NS2 records
in-flight can force downgrade to unencrypted transport.  (In contrast to
https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-00)

On Mon, Jul 13, 2020 at 4:35 PM Tim April <ietf=[email-masked]>
wrote:

> Hello DNSOP,
>
> First, apologies for not sending a note like this to the list with the -00
> version. I reviewed the thread(s) that happened after the last work group
> webexes right after IETF107 and tried to incorporate the feedback from the
> webex and email threads into the latest revision.
>
>    - Removed DS and DNSKEY SvcParamFields. Avoids issues with DNSSEC
>    signing in the parent.
>    - Removed IPv{4,6}Hints SvcParamFields. There was a discussion on
>    DNSOP about how glue is required
>    - Updating when to sign the NS2 / NS2T records (removed signing in the
>    parent)
>    - Attempting to clean up the introduction, goals and motivations of
>    the document
>    - Adding a privacy considerations section
>    - Adding more clarity around when to include/expect the NS2/NS2T
>    records
>    - Adding this note that CNS2 will not be included in this draft
>    - Prohibiting NS2 and NS2T from existing at the same name
>    - Making the statement about the parent records being glue and should
>    not be signed
>
> To: Tim April [email-masked]
> URL: https://www.ietf.org/internet-drafts/draft-tapril-ns2-01.txt
> by allowing zone owners to signal how the authoritative nameserver(s)
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>