The Domain Name System (DNS) has been in the news a bit recently, mostly
because of a ham-handed
by the US Department of Homeland Security (DHS) to control the master
signing key for the DNS Security Extensions (DNSSEC) root zone. While the
impact of that is still being
it certainly does not help alleviate
the fears that other countries have regarding US control of the Internet.
Meanwhile, the DHS is
pushing adoption of DNSSEC
which further fans the flames, even while there are serious
about the protocol and what, if any, real problems it solves.
On another front, Bugtraq readers will have noticed a
call to action
regarding DNS issues from security researcher Gadi Evron. All of this
seems like a good reason to take a look at DNS and DNSSEC and to try to
shed some light on the state of Internet name lookups.
DNS is one of the most
commonly used services on the Internet, every time one puts 'lwn.net' into
a browser, it is used to turn that name into an IP address. In a naive
implementation, the browser causes the machine to talk to one of the 13
root servers (k.root-servers.net for example) requesting information
about a nameserver for 'net'; it will get a response listing the 13 servers
that handle requests for the 'net' top-level domain
(D.GTLD-SERVERS.NET for example).
As part of the answer, it also receives the IP address for D.GTLD-SERVERS.NET
(otherwise it would have to query for that IP address which could lead to
an infinite loop) and it uses that address to query for a nameserver for
'lwn.net'. The response is a set of hosts and their IP addresses that are
the nameservers for the 'lwn.net' domain and these in turn can be queried
to get the IP address of the host of interest. After all that, the browser
can connect to the IP address on port 80 and commence with the HTTP request.
In most cases, all of that traffic does not get generated each time a hostname
needs to be resolved because there are caches that store
information on intermediate hosts. Hosts are typically configured to talk
to a caching nameserver when they make DNS requests. The caching nameservers
store name-to-IP mappings for as long as the time-to-live (TTL) value will
allow. TTL values are an amount of time in seconds that the
information returned is valid; they are chosen by a domain owner as a
tradeoff between quick responses to changes and DNS traffic reduction;
typical values range from two hours to two days. When a caching nameserver
finds a mapping in its cache with time still left in the TTL, it can just
provide that information to a requester without making any queries upstream.
DNS has worked, by and large, for a long time, but it is not without its
problems. Anyone who can intercept DNS queries and/or reply in a way that
looks like it
came from the queried server can control the name resolution process,
providing a number of opportunities for phishing and other kinds of
malfeasance. Because the information is typically cached, one redirection
with an enormous TTL can have a large impact in what is known as a DNS cache
poisoning attack. A poisoned cache sufficiently high in a hierarchy of
caching DNS servers can affect large swaths of the Internet as the redirection
can trickle down to each of the nameservers below it.
It is against this backdrop of cache poisoning and exploitable flaws in
some DNS implementations (Wikipedia has some good examples
calls to implement
DNSSEC have increased. By using public
DNSSEC removes the possibility of spoofing the nameserver for a domain
through a DNS reply. DNSSEC replies will be signed using the private
key of the domain and can then be verified using the public key. If the
response does not verify, it does not contain valid information for that
domain and should be discarded. At first blush, this seems like a good
thing that will eliminate some existing problems; as with many things,
though, the devil is in the details.
In order to verify any signed queries, one must obtain the public key from a
trusted source; invalid public keys just lead to the same forgery issues
that are present in the current system. The public keys will have to
be signed in a hierarchy that corresponds to the domain name hierarchy and
the top-level master signing key will be the key at the top of the heap.
Its public portion will be distributed with DNSSEC enabled software and the
private part will
sign the keys for the root servers. The root servers will sign the keys for
the TLD servers which will in turn sign keys for each of the domains. By
verifying each step before caching the information, nameservers can ensure
they have correct DNS mappings.
There are some inherent problems in DNSSEC and perhaps the highest profile
issue is with the exposure of all the zone data. Because DNSSEC is tasked
with providing an authoritative 'not found' message for hosts without an
entry, it enables enumeration of all hosts in a zone. The 'not found'
messages need to be signed, but it is deemed important not to have the
private keys online (in case of a security breach); it also cannot just
be a single signed 'not found' message because it could be replayed, in
effect knocking a valid host out of the DNS. The solution involves
ranges of invalid hostnames each with their own signed 'not found' message.
Through a series of queries, an attacker can gain all of the 'not found'
ranges which leaves the available hostnames obvious in the gaps.
This is very different from the current DNS where one could only ask for
hosts by name and essentially get a yes or no answer.
This information leakage was at first considered to be a non-issue by the
IETF group working on DNSSEC. They have since been convinced that this
problem would prohibit adoption in some jurisdictions and would severely
limit some of the more interesting uses for DNS after it becomes
secured. The latest proposals provide for a 'not found' message that
contains a canned signed portion along with a cryptographic hash of the
hostname requested and recipients would need to verify both the signature
and that the hash corresponds to the request that they made before
accepting the response.
There are also legitimate questions about why DNS needs to be secured. Even
if you are certain you know the right address to use for a particular domain,
you are not guaranteed that a connection made to that IP actually gets to
your intended destination. In order to ensure that, you must have another
layer of encryption such as HTTPS or ssh using verified
keys. It also does not really help against the vast majority of phishing
scams as it does not assist users in recognizing that
'thisistotallynotpaypal.com' is not in any way the same as 'paypal.com' even
though they end the same way.
There are some interesting applications for secured services like DNSSEC, but
critics argue that those applications should be implemented separately from
DNS. There is no need to risk
breaking the currently working DNS system by adding additional complexity for
little or no gain. If putting DKIM keys
into a nameserver-like structure is desirable, and many would argue that it
is, create a new system, perhaps based on DNS/DNSSEC, that implements it.
In the meantime, they contend, we should leave DNS alone.
Given these questions and a bit of concern whenever any government - but
particularly the US government - tries to muscle in on Internet governance, it
should come as no surprise that there is a bit of an uproar regarding the
DHS key control attempt.
It is not completely clear why the DHS believes it must control the master
signing key; the theories range from the bland, through clueless and into
nefarious. It is possible that DHS believes it is the only entity that
can be trusted with the keys, a position which tends to cause muttering about US
arrogance. Another possibility is that DHS does not really understand what
the keys are and what can be done with them. The paranoid are concerned that
the keys might be used to set up a parallel set of root servers that
remake the Internet into something more in line with the Bush administration's
vision of what the Internet should look like. By co-opting or otherwise
manipulating Internet routing, the DHS, some fear, could stage a complete takeover via this
alternate sanitized hierarchy. No matter what the reason, it certainly stirs
up people who feel that Internet governance should be handled by
international organizations and not by the US government.
The problems that Gadi Evron brought to the attention of Bugtraq readers
are independent of the DNS vs. DNSSEC debate as neither address the issues
that he is trying to solve. A great deal of Internet malware, botnets,
spyware, viruses, phishing, etc. relies on name resolution in order to do
its work. They typically use nameservers and IP mappings with
very short TTL values which allows them to be highly mobile, rapidly
changing nameservers and IP addresses as they get detected and shut down in
the whack-a-mole game that gets played continuously on the Internet.
The white hats simply cannot move fast enough even if they do not run
up against slow moving or hostile ISP administrators.
The easiest place to handle this kind of domain is with its registrar, who
can completely shut it down by routing its nameservers to nonexistent hosts.
This ability to essentially remove a domain's existence can be abused
(as GoDaddy proved with
seclists.org earlier this year) and there need to be some strict policies and
procedures in place to govern how that power is to be used. In addition,
there are so-called black hat registrars that do not care and perhaps
encourage malicious behavior from some of their registrants. Evron
was reporting on a message he sent to the registrar operations mailing
list highlighting the problem and looking for solutions. His message to
Bugtraq reported on the progress and asked for further ideas.
DNS is a critical piece of Internet infrastructure and anything that impacts
it will be felt by a lot of people; anything that breaks it will break the
net. All of the services that we use rely, at least to a limited
extent, on DNS and any serious outage would make the Internet completely
unusable. Because of that, a conservative approach is required. Threats can
come from both criminals and governments (though some would claim that is
redundant) and we need to protect the net from both. Perhaps DNSSEC tips
things too far one way and another approach is needed. It will be interesting
to see how it plays out.
to post comments)