On Mar 13, 2018, at 11:27 AM, Joe Abley <jab...@90.212.199.in-addr.arpa> wrote: > The canonical service that is difficult to use (or at least bootstrap) by > name rather than address is the DNS. If we imagine the intersection of the > DNS and TLS to be non-zero, there's your use case. This was Paul's point. > > DNS resolvers are normally referred to by address. This does imply a need for > address stability, and a lack of the kind of agility that is possible in > other services. People who have renumbered popular resolvers whose failure > has real end-user impact are nodding right now. And possibly checking their > pockets for valium.
Indeed. But I don't think you actually answered my question. I get the idea that in theory, DNS servers are configured this way. But we are talking about a situation where the resolver is contacting a service over TLS because, one assumes, privacy is important, or the local network is filtering DNS, or something like that. So now, where is that IP address coming from? DHCP? That doesn't match the trust model. You must be connecting to a server that you know, or else there's no reason to prefer it to the local resolver. If it's a server you know, you should do the trust establishment ritual when you configure it. So the trust establishment nugget needs to contain both a name and one or more IP addresses, not just an IP address. Problem solved, no need for new technology, other than to specify what the trust establishment nugget looks like. So the interesting problem is how the server with which the host has already established trust signals that its IP address is going to change at some time in the future, so that the host resolver knows to switch IP addresses. It's not how to establish trust on an IP address. If you have to establish trust on an IP address, you've already lost.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
