[dns-operations] DNS trust dependencies for TLDs

Matthew Dempsky matthew at dempsky.org
Thu Jun 11 07:04:39 UTC 2009

On Wed, Jun 10, 2009 at 11:38 PM, Stephane Bortzmeyer<bortzmeyer at nic.fr> wrote:
> [.FR existed long before ICANN and its existence now depends on the
> French law - "loi sur les communications électroniques du 9 juillet
> 2004" - not on ICANN so I took the liberty to change the subject.]

Sorry, I didn't realize labeling it an "ICANN TLD" was considered
offensive.  I only added that to the subject line after double
checking that the message would be on-topic for the list and noticing
the dns-operations mailing list web page states "Note that discussion
of non-ICANN root systems is explicitly off-topic."  I'll refrain in
the future.

> Do note that DNSSEC would entirely solve the mentioned attack (while
> DNScurve would not). But .FR is not signed so let's take the problem
> in another way: this attack would give control to only a portion of
> the caches (those which are closer from the 0wNEd nameserver than from
> any other one).

My understanding of other DNS caches is that they will periodically
contact all authoritative servers for a zone to account for changing
RTT over time.  Under this assumption, it doesn't matter how far you
are from a subverted authoritative DNS server: eventually a cache will
talk to it and let you take over another zone.

> (Also, to exploit the weakness, you need to be a legitimate
> customer of the cache, if the cache complies with RFC 5358.)

The attack I outline on


only requires sending an A query to the target cache.  This is quite
easy to do in practice.  E.g., sending an email to a mail server will
generally result in lookups for domain names mentioned in the envelope
(I confirmed this with gmail's mail servers).

> Matthew Dempsky jumped on the first problem (rogue secondary
> nameserver) and ignored the second one (rogue recursive cache).

There's an easy solution to the rogue recursive cache problem: use a
trusted cache.  If there aren't any external ones you trust, use a
local one.

More information about the dns-operations mailing list