On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon <mel...@fugue.com> wrote: > A user who relies on the dhcp server for dns server info is no worse off. > The problem is that if your host lets the dhcp server override the DoT or > DoH configuration you entered manually, you are a lot worse off. >
This seems to be a static vs dynamic setup. Either you use dynamic and you will happily accept what you get from DHCP and possibly upgrade to (HTTP|TL)S or you have set your resolvers statically and you are already ignoring the nameservers provided by the DHCP server. If you do not accept the servers provided by DHCP, there is no reason you would accept extra attributes for those same snameservers. Manu > So you have to specify how you’re going to handle this. I’m not saying > don’t do it. I’m saying figure out how to specify it so that either that is > the only use case, or the other is the only use case, or the implementor > knows how to make the right thing happen for both cases. Don’t just pretend > there’s no conflict. > > On Sun, Aug 19, 2018 at 6:07 PM Doug Barton <do...@dougbarton.us> wrote: > >> I agree with Steinar's sensibilities on this, FWIW. >> >> Ted, you've restated your thesis several times now, but what I haven't >> seen is an answer to my question, so let me pose it a different way. >> >> How is a user that relies on the DHCP server's DOH or DOT resolving name >> server instructions worse off than one who relies on the DHCP server's >> ordinary resolving name server instruction? >> >> Also, we're not talking about introducing a new service here, we're >> talking about a configuration detail for a service that not only already >> exists, but is critical to get any real work done once you're on the >> network. >> >> Doug >> >> On 08/19/2018 12:28 PM, Ted Lemon wrote: >> > I am indeed saying that when the IETF publishes a standards track >> > document with an applicability statement, the IETF is recommending >> that, >> > where applicable, the specification be used. >> > >> > The problem with not deciding on the trust model is that it would be >> > impossible to write a clear applicability statement, and hence the >> > protocol would be implicitly applicable in all cases. When you are >> > designing a protocol with very serious and significant trust >> > implications, this is a really bad idea. >> > >> > Think about DHCP providing an SMTP server address. Does that make >> > sense? What is the trust model? The IETF does indeed recommend this >> > for IPv4, but we didn't do it for IPv6 because we'd realized by the >> time >> > we did RFC 3315 that not every single thing you can in principle >> > configure with DHCP should be configured with DHCP. >> > >> > >> > On Sun, Aug 19, 2018 at 2:48 PM, <sth...@nethelp.no >> > <mailto:sth...@nethelp.no>> wrote: >> > >> > > The DHCP solution is compatible only with trust relationship >> two. So if >> > > the IETF were to recommend this way of configuring DoH and DoT, >> we would >> > > essentially be throwing away the privacy benefits of DoH and DoT >> (assuming >> > > that such benefits exist). >> > >> > I don't believe people are saying that the IETF should *recommend* >> > this way of configuring DoH and DoT - they're saying the DHCP option >> > should be *available*. >> > >> > Are you saying that all DHCP options introduced so far have been the >> > IETF recommended way of configuring things? >> > >> > Are you saying that no new DHCP option can be made available unless >> > the IETF recommends this way of configuring things? >> > >> > Both of these sound equally unreasonable/unlikely to me... >> > >> > Steinar Haug, AS2116 >> > >> > >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
