Subject: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt

From: Tom Pusateri <[email-masked]>
Date: Mon, 2 Jul 2018 21:08:58 -0400

I renamed the DHCPv6 DNS Discovery draft and submitted it. There are no other changes from the early version referenced on Github.

Thanks,
Tom

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt
> Date: July 2, 2018 at 3:51:16 PM EDT
> To: "Willem Toorop" <[email-masked]>, "Tom Pusateri" <[email-masked]>
> 
> 
> A new version of I-D, draft-pusateri-dhc-dns-driu-00.txt
> has been successfully submitted by Tom Pusateri and posted to the
> IETF repository.
> 
> Name:		draft-pusateri-dhc-dns-driu
> Revision:	00
> Title:		DHCPv6 Options for private DNS Discovery
> Document date:	2018-07-02
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-pusateri-dhc-dns-driu-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pusateri-dhc-dns-driu/
> Htmlized:       https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-driu
> 
> 
> Abstract:
>   This draft provides a series of DHCPv6 options for a DHCPv6 client to
>   request from a DHCPv6 server to aid in configuring DNS servers that
>   support private requests/responses.
> 
> 
> 
> 
> 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: Bob Harold <[email-masked]>
Date: Thu, 5 Jul 2018 13:39:18 -0400

On Mon, Jul 2, 2018 at 9:09 PM Tom Pusateri <[email-masked]> wrote:

> I renamed the DHCPv6 DNS Discovery draft and submitted it. There are no
> other changes from the early version referenced on Github.
>
> Thanks,
> Tom
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-pusateri-dhc-dns-driu-00.txt*
> *Date: *July 2, 2018 at 3:51:16 PM EDT
> *To: *"Willem Toorop" <[email-masked]>, "Tom Pusateri" <
> [email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-pusateri-dhc-dns-driu-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pusateri-dhc-dns-driu/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-driu
>
>
> Abstract:
> ...

> DRIU mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/driu

-------
I have concern:

3. DHCPv6 Encapsulating Options

"There is no order
implied by the order of options sent or received. It is up to the
receiving client to determine which order to use the DNS server
configurations."

Let's not wait for some non-standard way to decide the order. Please add
'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like
in MX and SRV records.

-------
And a question:

Appendix A. ISC DHCPv6 Configuration Example

"option tls.adn code 228 = domain-list;

option tls.adn "dns.quad9.net";"

Why is this defined as a list, but only a single domain is configured. And
the text (in 1. Introduction) indicates only one domain is allowed per
option. Is there a single domain format that should be used?

-- 
Bob Harold

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 5 Jul 2018 14:02:15 -0400

> On Jul 5, 2018, at 1:39 PM, Bob Harold <[email-masked]> wrote:
> 
> I have concern:
> 
> Let's not wait for some non-standard way to decide the order. Please add 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like in MX and SRV records.
> 

Willem has said that from experience with Stubby, that the client should determine the order it uses the discovered DNS servers. The network operator advertising the list doesn’t necessarily have real time data to determine response times, delays, etc. I’m happy to discuss this more. Why should the network operator dictate this?

> option tls.adn "dns.quad9.net <http://dns.quad9.net/>";"
> 
> Why is this defined as a list, but only a single domain is configured. And the text (in 1. Introduction) indicates only one domain is allowed per option. Is there a single domain format that should be used?

Yeah, this is a bug in the ISC config file. I will fix the example.

Thanks,
Tom

---

From: Bob Harold <[email-masked]>
Date: Thu, 5 Jul 2018 14:49:31 -0400

On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <[email-masked]> wrote:

> Willem has said that from experience with Stubby, that the client should
> determine the order it uses the discovered DNS servers. The network
> operator advertising the list doesn’t necessarily have real time data to
> determine response times, delays, etc. I’m happy to discuss this more. Why
> should the network operator dictate this?
>
> I would think that the network operator, who can set the option per
subnet, would have a better idea where the subnet is, than a client machine
that roams from place to place and usually does not know where it is
located.  If the operator lists more than one server, there is likely to be
a need to designate primary vs backup in some cases.  If the client knows
better, it can certainly have its own list, and ignore or append what the
network recommends.  But the network knows better what will be faster or
even reachable from a given subnet, in my opinion.  (I run the DHCP servers
at my location, so I am probably biased.)

-- 
Bob Harold

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 5 Jul 2018 15:31:45 -0400

> On Jul 5, 2018, at 2:49 PM, Bob Harold <[email-masked]> wrote:
> 
> 
> On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Jul 5, 2018, at 1:39 PM, Bob Harold <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> I have concern:
>> 
> I would think that the network operator, who can set the option per subnet, would have a better idea where the subnet is, than a client machine that roams from place to place and usually does not know where it is located.  If the operator lists more than one server, there is likely to be a need to designate primary vs backup in some cases.  If the client knows better, it can certainly have its own list, and ignore or append what the network recommends.  But the network knows better what will be faster or even reachable from a given subnet, in my opinion.  (I run the DHCP servers at my location, so I am probably biased.)

Since the option is probably only refreshed once per day on average, the list is fairly static. Assuming that an on subnet server will respond faster than a server several hops away is a bad assumption. It depends on many factors and these will change constantly depending on the number of clients, the number of TLS connections the server can manage, number of switches and congestion at the network level including APs, etc. Since these conditions change at the sub-second level, having the client figure out which server responds best seems more flexible.

If all the servers in the list should respond, does the network operator care which one is used? Once you get past the access point, is there typically congestion in the wired network you’re trying to avoid?

I’ll put this on my slides to discuss in Montréal.

Thanks,
Tom

---

From: Bob Harold <[email-masked]>
Date: Thu, 5 Jul 2018 15:57:19 -0400

On Thu, Jul 5, 2018 at 3:31 PM Tom Pusateri <[email-masked]> wrote:

> Since the option is probably only refreshed once per day on average, the
> list is fairly static. Assuming that an on subnet server will respond
> faster than a server several hops away is a bad assumption. It depends on
> many factors and these will change constantly depending on the number of
> clients, the number of TLS connections the server can manage, number of
> switches and congestion at the network level including APs, etc. Since
> these conditions change at the sub-second level, having the client figure
> out which server responds best seems more flexible.
>
> If all the servers in the list should respond, does the network operator
> care which one is used? Once you get past the access point, is there
> typically congestion in the wired network you’re trying to avoid?
>
> Thanks for the discussion.  If the client tries them all from time to time
and picks the fastest, that is probably best.  I was assuming that most
clients would be fairly simple-minded and use the first one, and only try
the next if the first failed.  For simple clients, an order might be
helpful.  (Some IOT devices have very limited computing power.)

I would be interested in what others think.  Sorry I cannot attend Montreal.

-- 
Bob Harold