The Domain Name System (DNS) is, in a nutshell, a distributed directory service
managing information about so-called domain names. Its core service is the
mapping from host names to IP addresses, performed for each domain by one of
the authoritative name servers for that domain. The DNS is a critical infrastructure
for the World Wide Web. Users rely on a correct binding from host names
to IP address to get access to the services they wish to use. Browsers rely on
correct bindings when enforcing origin based security policies.
1. Cache Poisoning
There are two types of attacks that break the correct binding between host
names and IP addresses. On one side there are the ‘traditional’ attacks impersonating
an authoritative name server to forge IP addresses in the domain of that
server. Cache poisoning attacks exploit certain features of the DNS, including
the caching strategy of resolving name servers and a challenge-response authentication
that relies only on the unpredictability of challenges, to achieve this
goal. A particularly effective cache poisoning attack using so-called additional
resource records is due to Dan Kaminsky1. Defences against cache poisoning
attacks can be provided at the infrastructure level, e.g. by running separate
resolving and authoritative name servers in a domain, by designating random
ports for replies from the authoritative name server as to increase unpredictability,
and ultimately by having the response from the authoritative name server
digitally signed (DNSSec, RFC 4033 to RFC 4035 [1,2,3]).
2 DNS Rebinding
There is a second type of attack where an authoritative name server is the source
of incorrect bindings. Such DNS rebinding attacks and were first discussed in .
DNS rebinding attacks exploiting features of browser plug-ins are described in
. With DNS rebinding the attacker circumvents origin based policies in the
client browser. For example, a script from a page hosted by the attacker may
connect to a victim’s IP address the browser accepts to be in the attacker’s
domain because it has been told so by the attackers authoritative name server.
The client browser would have to double check with the host at the designated
IP address whether it considers itself to be in the attacker’s domain. It must also
be noted that it is an intrinsic problem if the client accepts policy information
from a third party without checking its veracity.
More generally, we may ask whether it is necessary for an application to rely
on the DNS to provide an authenticated binding between a name (not necessarily
a domain name) and an IP address. Alternatively, we could split the task
of a rendezvous service that binds a name to an unauthenticated IP address
from the task of an authentication service verifying that an address given indeed
belongs to that name. The security property expected from the infrastructure
would then be availability, which might be achieved by running multiple independent
rendezvous services. Address authentication could be implemented in
the application layer, e.g. based on secrets shared between client and server such
as a user password.
