at the one-hour DNSOP meeting in montreal on monday evening, the authors of
RFC 7706 described some of the use case questions they were hoping to answer
in their -bis document, and one of them hit squarely on a topic i spoke about
frequently between 2005 and 2015. i've attached a copy of the 2015 proposal,
which was reviewed by warren kumari and then presented in a non-IETF meeting
on these topics, organized by warren and i, in hong kong.
i was opposed to RFC 7706 as written, but there is no permanent record of my
reasoning since RFC documents don't include a "dissenting views" section, so
let me briefly recapitulate here.
first, all complexity comes at a cost. the new code and configuration needed
to support "mirror zones" will be a life long source of bugs and
vulnerabilities, because that's true of every new feature. the desired benefit
should be weighed against this cost. "by running one on the loopback" fails
this important test, mostly because it only applies to the root zone.
second, RDNS name servers who wanted to support this feature, which all must,
due to the competitive nature of the open source infrastructure community,
have to add features very much like authority DNS. we have been moving away
from the so-called "hybrid server" model for three decades now, and this was a
move in precisely the wrong direction.
third, access patterns of root zone data are an important input to internet
governance, and the 7706 proposal included no recommendations by which access
patterns could still be globally shared in any way -- and for reasons of
scale, they will not be participating in Day In The Life exercises.
in summary, RFC 7706 solves the wrong problem, in the wrong way, with an
inverted cost:benefit model compared to similar conceptions with similar
implementation costs.
those who hang around where i do have heard me explain that what DNS needs is
a lease model for all metadata, with secure revocation. any delegation data
including NS, glue, and DNSSEC chains, must be held by an RDNS until it
changes, and every authority must be able to signal such changes. you can
think of this as like a micro-secondary server at the RRset level, plus
NOTIFY. no network partition should keep an RDNS from returning all
information which is still available ("on this side of the partition") needed
to reach services and assets which are still available ("on this side of the
partition"), and DNS got that wrong by externalizing dependencies.
however, that is not the subject of the attached 2015-era "hong kong"
proposal. at DNSOP monday night, a use case that was mentioned for 7706-bis is
where the local copy of the root zone not be necessarily co-served by an RDNS.
that is a much smaller problem than "leasing for all metadata in case of a
network partition", and is squarely addressed by the modest proposal below.
one world, one internet, one namespace.
--
PaulTitle:: Distributed Autonomous Root Service for the IANA DNS Namespace
Abstract::
While the autonomy and reliability goals of DNS are well met by the
current system from the point of view of DNS content providers, there
is much unfortunate centralization from the point of view of DNS
content consumers, including external dependency, and surveillance.
This document describes a set of technical and administrative methods
which have long been in common use, and which can be used to alleviate
notable centralization, external dependency, and surveillance risks.
These methods may be of interest either to operators of individual
connected Internet hosts, or to operators of a residential, campus,
commercial, or regional networks, or to nation-states.
Introduction::
The Domain Name System (DNS) is a hierarchical, autonomous, reliable,
universal database. Hierarchy and autonomy are achieved by delegation
of subtrees of the name space where local content including further
sub-delegation require no central coordination. Reliability is
achieved by mirroring content across a designated set of loosely
coupled authority servers, and by caching of previously fetched data
in widely distributed intermediate servers. Universality is achieved
by digital signatures using public key cryptography on DNS authority
data, with a chain of proofs reaching from any signed data back to a
single common root zone signing key managed by the Internet Assigned
Numbers Authority (IANA).
Autonomous networks, whether at the level of a single host, or a small
office or home office, or a residence, campus, Internet service
provider (ISP), region, or country, face two shortcomings related to
their dependency upon centralized DNS authority servers, including DNS
Root name servers. First, outside surveillance agents can witness the
DNS query traffic generated by the autonomous network, thus revealing
to outside parties the general nature of an autonomous network's DNS
lookups. Second, connectivity loss between an otherwise-autonomous
network and the IANA root name servers usually results in loss of
local service within the local network, even when internal
connectivity has not been lost to the servers containing DNS local
content or to local endpoints described by such local DNS content.
Therefore [while the autonomy and reliability goals of DNS are well
met by the current system from the point of view of DNS content
providers, there is much unfortunate centralization from the point of
view of DNS content consumers, including external dependency, and
surveillance. This document describes a set of technical and
administrative methods which have long been in common use, and which
can be used to alleviate this centralization, external dependency, and
surveillance. These methods may be of interest either to operators of
individual connected Internet hosts, or to operators of a residential,
campus, commercial, or regional networks, or to
nation-states.](abstract)
NOTE WELL: This document does not describe, nor does its author
recommend, any method by which autonomous networks can amend or edit
the DNS name space for specialized local use. The Internet's continued
success and relevance relies on a single universal namespace, managed
cooperatively by the Internet Assigned Numbers Authority (IANA), such
that any domain name can be looked up anywhere, and that the lookup
result will mean the same thing everywhere.
It is the Internet's RDNS servers whose collective "hints file"
effectively determines the names and addresses of the authority
servers for the root zone (hereafter called "root servers"). The names
and addresses from the "hints file" are also reflected in NS records
at the apex of the root zone, such that any change to the names or
addresses of the root servers must be reflected immediately in a
corresponding change to the apex NS record set of the root zone, and
eventually in a change to the "hints file" used by the Internet's
collective RDNS servers.
Similarly, for DNSSEC validation, an RDNS must also be configured with
at least one trust anchor for the root zone which allows records to be
validated a priori when received. This trust anchor must be updated
periodically to reflect replacements for the root zone signing keys,
as old keys are gradually retired and new keys are created.
A working DNS configuration requires cooperation between RDNS
operators, root server operators, and a root zone publisher -- and
that cooperation must be expressed by coherent set of <root zone
signing key, root zone trust anchor, root zone apex NS RRset, hints
file>.
The Problem Space::
Root Server Names, Addresses, and Anycast:
At the time of this writing there are 13 IANA root server names, each
possessing one IPv4 address, and most also possessing one IPv6
address. As stated previously, these names and addresses are encoded
into both the "hints" configuration used by every RDNS server, and the
apex NS record set of the root zone. Most of these root name servers
are widely anycasted, meaning that most regions of the world are
locally served by one or more of these anycast nodes. The root name
server operators are generally amenable to installing new anycast
nodes for interested parties, including Internet Exchange Point (IXP)
operators, Internet Service providers (ISPs), and even some larger
university and enterprise networks.
There are two problems left unsolved by wide scale root name server
anycast as currently practiced, from the point of view of autonomous
network operators who are considering their external dependency and
surveillance risks. First, not all networks are eligible for anycast
root name service -- there are billions of connected hosts, hundreds
of millions of connected networks, and tens of millions of RDNS
servers, whereas there can be only hundreds of anycast root name
servers. For the many connected hosts and networks with no nearby
anycast root name server, root name service is both an external
dependency risk and a surveillance risk.
Second, no network smaller than the global Internet itself has anycast
instances of all root name servers. When an RDNS wants to know which
authority server for a given zone is the closest or fastest, it does
so by sending queries to every address of every name server for that
zone, eventually settling into an equilibrium where most queries are
forwarded to the closest (measured) server. Those external measurement
queries are a source of information leakage, and they constitute a
surveillance risk, even when one or more root name server anycast
instances are deployed locally or nearby.
The Solution Space::
New hints, new server names, new server addresses:
As explained previously, the cooperation perimeter that's required for
correct root name service is a matching set of the following:
1. a root "hints file"
2. the root zone apex NS record set
3. the root zone's signing key
4. root zone trust anchor.
Any set of cooperating authority server and RDNS operators who agree
to such a matched set of data and metadata can disconnect themselves
in nearly all externally visible ways from the global Internet's root
name server system. This is frequently done inside disconnected or
protected networks operated by military or security agencies or within
high-security enterprise networks. It has also been done successfully
by the Open Root Server Network, which duplicates the IANA top-level
domain (TLD) namespace exactly, but uses non-IANA authority servers to
offer a viable and independent alternative to the IANA root name
servers.
The general work flow for creating and using a non-IANA set of root
name servers is as follows:
1. decide on four invariants:
a. a set of name server names and addresses;
b. a root zone signing key, and a key management
regime;
c. a set of name server operators, such that every
address from (1.a) has one or more publication
servers, most likely anycasted from several locations;
d. a publication point for hints, trust anchor, and
zone data;
2. craft an import process to be run one or more times daily:
a. fetch the IANA zone;
b. verify, and then strip off IANA's DNSSEC signatures;
c. replace IANA's root name server names in the apex
NS record set with name server names chosen in (1.a);
d. re-sign the zone using the signing key from (1.b);
e. publish the new zone, using NOTIFY and IXFR, at (1.c);
3. begin root zone re-generation and publication process at (2);
4. begin operations for autonomous root zone servers at (1.b);
5. reconfigure cooperating RDNS servers to use the autonomous
hints and trust anchors published at (1.d).
The addresses chosen for these non-IANA root name servers need only be
reachable within the cooperation perimeter. So for example, on a single
host, addresses within the "loopback" network can be chosen, and in
networks using RFC 1918 private addresses, it's reasonable to choose
private addresses. The names chosen can have any form, and for simplicity
it's reasonable to assign them as top-level names (such as "root-x.",
"root-y.", and "root-z."). Such top-level names do not represent changes
to the IANA name space, since they will never be seen or fetched by any
users or any applications other than DNS itself.
To reiterate: the cooperation perimeter for DNS root name service and
recursive name servers (RDNS) is just an agreement on the names and
addresses of the root name servers, and a matching DNSSEC key set for
root zone content publication and root zone content validation. Any
autonomous network including a single host (via its "loopback"
network), or a LAN or a campus or an ISP or a regional network or a
national or international "backbone" network can easily recreate these
conditions, and by so doing, can mitigate the external dependency and
surveillance risks present in the current DNS root name service
architecture.
On the Nation-State Opportunity:
There is no technical reason why a nation-state who is concerned about
the transparency and accessibility of Internet governance could not
pursue an "autonomous network" strategy, where some set of trusted
high-availability in-country root name server names and addresses were
chosen, and a trustworthy in-country root zone representing the IANA
name space were published. If so, the use of these in-country root
name servers and this national root zone trust anchor could be made a
matter of national policy or even national law. If a nation-state had
an effective national firewall, then this configuration could even be
enforced, by making all out-of-country root name servers and anycast
instances unreachable in-country.
Summary::
On the Internet, opportunities for effective unilateralism are quite
rare. In general, cooperating parties can work together however they
wish to. For example, anyone who wishes to periodically fetch, edit,
and re-sign the IANA root zone for reasons of local policy can
certainly do so. Accordingly, the methods described in this proposal
are already in wide use.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
