The discussion Ted and I have been having comes down to the question of whether we are only going to support Internet DNS or private use of DNS. The two are almost but not quite the same.
Recall that DNS is more or less unique among IETF protocols in that it was designed to support non-IP protocols from the start. We use a couple of bytes every message declaring IN class. The original Inter-Network Protocol was sold as being the glue that bound networks together. There are things that are true of a network that are not true of an Inter-Network and vice versa. One of the consequences of IP-everywhere is that a lot of the work Clark et. al. did on this has been lost. But these differences still matter. The enterprise network folk have a lot more influence on the product schedules of Apple, Microsoft etc. than the rest of us. They are the people who write the RFPs that the marketing depts use to decide on product features. The Internet is an inter-network that has a single namespace that is the same for all connected devices and is visible to every network device. A network namespace is only unique locally. It typically contains the Internet name space but this is not required, it may be a subset of the Internet namespace. A network may not be Internet connected at all (airgap). The network namespace may be subject to fine grain access control. This is a critical distinction for network managers but the implications for the DNS protocol are actually rather modest. The only thing missing from the DNS protocol is the option of using a user account in the client-resolver protocol. TLS certificate based client auth gives us that capability in theory. Practice is different. DPRIV is not the place to discuss an authentication mechanism but we should be able to state where an authentication mechanism would plug in. Another point that was raised aw 'complexity'. Which is such a loaded term I would like to avoid using is to compare proposals. Complexity is like a balloon, push down in one place and it pops up in another. PKIX got the way is did through under-engineering. People punted on requirements early on, then invented whole new protocols to deal with them later on because the core didn't extend well. Complexity isn't always a choice. But you usually get some choice as to where that complexity goes. For DPRIV, I want the minimum client implementation to be as simple as possible. I don't mind if implementing a resolver is a little bit more complex. So I am quite happy if we decide to REQUIRE a DPRIV resolver to support both a lightweight UDP session and a TCP/TLS session. In fact I already suggest something of the sort because hotels etc tend to have screwed up UDP connectivity on occasion. So we do need port 443 transport as a fallback option. If we were to mandate that a DPRIV resolver support both protocols on an equal basis, we don't need to get into arguments about the performance that is 'possible' with TCP in particular network circumstances that may or may not be achievable in real life. Whether we support one additional session layer or two does not make much difference to the complexity of a resolver. The folk writing the clients will know whether the cost/benefit of supporting one or both private mechanisms makes best sense for them. The end goal I think we should shoot for is to retire the unencrypted DNS client-resolver protocol. To do that we have to show that the DPRIV scheme is 'better' than current in every possible Internet circumstance and be 'better' for the network owner for every network circumstance. I don't care what the VeriSign/USC folk measure, they cannot hope to beat one UDP round trip for speed in fact they can't even match it with the deployed TCP stacks. And I can't hope to make any protocol offer 100% connectivity on UDP alone. Give folk both options and I think we can persuade pretty much every stakeholder we need to influence to make the switch.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
