Is this a DNS security hole?

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Sun May 2 12:00:40 UTC 2004


Don't multi-post.  If you are going to post a single message to multiple
newsgroups, cross-post.

IY> this seems like a security hole to me

It is, to an extent (although not to the extents that some respondents have
suggested).  However, it's one that is difficult to close, because many
people, in flagrant defiance of best practice for delegations, _want_ the
functionality that requires this hole to exist.

IY> now "victim.example.com"  is tied to the IP address, it doesn't
IY> even try to resolve it from "example.com" 's DNS server.....  
IY> why is this happening??   

Because of the fundamental design of the way that the distributed DNS database
is distributed.  There are four sets of content DNS servers that can tell one
information about "victim.example.com.": the "testing.example.com." content
DNS servers, the "example.com." content DNS servers, "com." content DNS
servers, and the "." content DNS servers.  Resolving proxy DNS servers can end
up consulting, at first, _any one_ of these sets of content DNS servers when
resolving queries about "victim.example.com.".  The procedure that you
describe causes the "com." content DNS servers to have data for
"victim.example.com." in their DNS database, which (in accordance with the
algorithm in RFC 1034) they then publish directly (when asked) instead of
responding with referrals to the "example.com." content DNS servers as they
would do otherwise.  So resolving proxy DNS servers that end up happening to
consult the "com." content DNS servers first (or second, after following a
referral from the "." content DNS servers) will receive the answer that the
"com." content DNS servers have in their DNS database.

Other respondents have called this "poisoning" by the "com." content DNS
servers.  It isn't poisoning, though.  The "com." content DNS servers are
perfectly legitimate sources of information about "com." and all of its
subdomains.  Delegation is not exclusive in the DNS.

The problem, seen from the viewpoint of query resolution, is not poisoning. 
It is inconsistency.  What the "com." content DNS servers publish is not
poison.  But it is inconsistent with what the "example.com." (or
"victim.example.com.") content DNS servers publish.  And thus the overall
distributed public DNS database is not consistent.

The solution to the problem is to enforce best practice for the intermediate
domain names used in delegations, namely that they must be subdomains of the
domain name being delegated.  (e.g. The intermediate domain names used in the
delegation of "example.org." must be subdomains of "example.org." itself.) 
However, some people employ merely _good_ (not best) practice, where the
intermediate domain names are merely subdomains of the enclosing superdomain.
(e.g. The intermediate domain names used in the delegation of "example.org."
are merely subdomains of "org.".)  This prohibits closing this hole, since it
requires that registrants have the capability for registering "HOST" records
that aren't easily related to their "DOMAIN" records.

Some people don't even employ good practice, let alone best practice, and use
intermediate domain names in delegations that aren't even subdomains of the
enclosing superdomain, rendering their delegations effecitvely glueless. 
(e.g. The intermediate domain names used in the delegation of "example.org."
are, say, subdomains of "net.".)  However, somewhat ironically, the analogous
hole caused by such _bad_ practice _is_ closed, by the bailiwick restrictions
in modern resolving proxy DNS server softwares.  (Modern resolving proxy DNS
servers refuse to take the "org." content DNS servers' word for anything that
they may say about subdomains of "net.".)

IY> If this is true, anyone can hijack other people's domain name
IY> using DNS and point to his IP address

In theory (according to the RRP specification, although it is difficult to see
how the relevant restriction can be enforced at all in practice), one can only
hijack domain names that have been registered via the same registrar that one
is using to perform the hijack.


More information about the bind-users mailing list