Subject: [dns-privacy] Should the client resolver protocol be application or Transport layer?

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Jan 2015 12:29:49 -0500

I have been working on a paper tying to make sense of the 'evolved'
Internet architecture so I can (1) teach it and (2) work out how to add
security at a deep level.

Most of this is not really relevant here so I will spare you. But one part
of the work that might be relevant here is the layer at which the DNS
protocol operates is subtly different depending on whether the server is a
resolver or authoritative.

To configure a DNS service today, the user enters an IP address, for
example 8.8.8.8 (now blocked in Turkey). Which seems logical and necessary
because specifying a domain name would force us into an infinite loop
(unless of course the client has the root zone addresses hard coded).

This makes the DNS a Transport layer protocol because the discovery
mechanism is IP address and port. It is delivering a service to the
Presentation layer (mapping DNS names to IP addresses and ports), but it
only depends on the lower layers in the stack.

This all seemed well and good to me till I started thinking about the way
that zone delegation takes place in the DNS which is really rather odd.
Instead of delegating a zone to a DNS server at a specified address, the
delegation is made to a server at a DNS name. And this creates the
bootstrap problem described above and the need for glue records.

Depending on how you want to look at the situation, we can consider this to
be more harmless cruft we should ignore or we can take the opportunity to
decruft.

I think that if we want real end users, by which I mean the 99%, not the
technology 1%, I think we should write a design that allows an end user to
set their DNS resolver up using a DNS name rather than an IP address.

This would present a bootstrap problem but I really don't see that as an
issue as it is a one off event that can be solved in many ways:

* Use the DNS resolver advertised in DHCP
* Direct resolution using hard coded DNS roots
* Direct resolution using reserved DNS addresses.

The last seems to me like an idea whose time might have come. In the days
when the authenticity of the root data was assured by IP address alone
(i.e. badly) it made sense to keep the number of root services low. Today
we have hundreds of hosts sitting on 13 Anycast addresses and a political
demand (but not a technical requirement) to expand further.

I think that we should have a group of IP addresses that will by definition
connect up to the root DNS, wherever that turns out to be in the future.

And we should make sure that the IETF owns the addresses, not ICANN.