Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

[[e-mail]]

James,

Thanks for the summary. There is also more here:
https://tools.ietf.org/html/draft-ietf-ipngwg-dns-discovery-analysis-00
https://tools.ietf.org/html/rfc4339

The reason I questioned the assumption is because of the information leakage associated with a recursive resolver.
Using the recursive resolver offered by the network, means you entrust the network with every DNS query you make.
Does that make sense for the FreePublicWIFI at the airport, the coffee shop, the home CPE, or the Enterprise?

Apart from running a resolving server on the host and doing DNS over DTLS I'm not sure how to resolve that.

Perhaps the local network must provide a recursive resolver, but the practice of using it for all queries by default is perhaps something we should wean ourselves off.

Ole




> On 1 Mar 2017, at 19:56, james woodyatt <[e-mail]> wrote:
> 
> On Mar 1, 2017, at 00:15, [e-mail] wrote:
>> 
>> Why do we assume that the local network should even provide DNS configuration?
> 
> Because the Domain Name System (DNS) is an essential service of the Internet. Allow me to provide a bit of history from memory in the hopes it will explain how this particular assumption came to be established here.
> 
> —
> 
> Many years ago, when I was implementing the predecessor of RFC 6106, while it was still an Internet Draft, I remember half-heartedly proposing in 6MAN and here in V6OPS that the way host operating systems needing automatic DNS server address configuration should cope with RA messages with the O flag cleared by querying for the SRV record at _dns._udp.local over mDNS.
> 
> I was just about to start writing an Internet Draft to that effect when various IETF participants here suggested there could be serious Security Considerations there. (Never mind that DHCPv6 has the same Security Consideration. We sort-of had DHCP Shield for that problem. There was no mDNS Shield yet.)
> 
> So I said, “What should I do? The RA message says not to expect any DHCPv6 service here. On the other hand, I have a perfectly sane ad-hoc multicast service discovery protocol already defined to do this in the event there is no DHCPv6 service. I’ve got to implement something.”
> 
> And somebody said, “What if we resurrect my old RDNSS draft?”
> 
> And other people, including me, said, “Yeah, but is there an RA Guard equivalent of DHCP Shield?”
> 
> And the answer to that was, “Well, I guess we could publish that draft too.”
> 
> And I said, “Okay, I can live with that."
> 
> And so I implemented RDNSS in the router, and I helped get RDNSS implemented in the hosts we cared most about. (I also needed to implement Stateless DHCPv6 service in the router so that another vendor’s hosts would get DNS information too. And that’s why RFC 7084 says to do both.)
> 
> —
> 
> Here’s really how we got into this mess:
> 
> 1. we made DNS an essential service of the Internet;
> 
> 2. then we made DHCPv6 the only way to configure hosts with DNS service automatically;
> 
> 3. and we made DHCPv6 optional by giving routers a way to say “there is no DHCPv6 here."
> 
> When we did that, we set ourselves up for having more than one way to configure hosts with DNS configuration. One using DHCPv6, and another for when DHCPv6 is not available.
> 
> I can think of five (5) different IETF published Standards Track protocols that are available for hosts to configure their DNS information automatically: DHCPv6, RDNSS, mDNS-SD, SLP and CoRE-RD. I can think of several more non-standard ones beyond those.
> 
> Only one of those standard protocols is one that IPv6 hosts are generally already required to implement: Router Discovery. It’s perfectly okay with me if IETF publishes a BCP that says hosts with DNS clients MUST be capable of processing RDNSS to configure their DNS information automatically. Because they are generally required to process RA messages to configure their IP service automatically. It would be a very low impact requirement.
> 
> I am opposed to dealing with this problem by telling host implementers they MUST implement a DHCPv6 client, and they MUST use it even when RA messages are telling them “there is no DHCPv6 here,” for all the reasons I enumerated previously.
> 
> 
> --james woodyatt <[e-mail]>
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops