Subject: [dns-privacy] Internet-DNS versus Network DNS

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Feb 2015 11:04:21 -0500

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.