Subject: RFC proposal on DNS spoofing prevention

From: bert hubert <[email-masked]>
Date: Thu, 10 Aug 2006 22:00:25 +0200

Dear namedroppers,

Remco van Mook and I have written an RFC draft that explains the risks of
DNS spoofing, and how to address these by a proper combination of zone
configuration and nameserver software.

It can be found on:

 * http://ds9a.nl/rfc/dns-anti-spoofing.html
 * http://ds9a.nl/rfc/dns-anti-spoofing.txt
 * http://ds9a.nl/rfc/dns-anti-spoofing.xml

Some salient quotes:

	For example, using the formula derived earlier on a domain with a
	3600 second TTL, an attacker sending 7000 fake answer packets/s (a
	rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the
	first 24 hours, which rises to 50% after a week.

	For a domain with a TTL of 60 seconds, the 10% level is hit after 24
	minutes, 50% after less than 3 hours, 90% after around 9 hours.

	(...) 
	
	These and other developments have made the security and
	trustworthiness of DNS of renewed importance. Although the DNS
	community is working hard on finalising and implementing a
	cryptographically enhanced DNS protocol, steps should be taken to
	make sure that the existing use of DNS is as secure as possible
	within the bounds of the relevant standards.

	It should be noted that the most commonly used resolver currently
	does not perform as well as possible in this respect, making this
	document of urgent importance.

I've not previously written an RFC (although Remco co-authored RFC 2322,
which is in itself a spoof), so this process is very new to us.

We understand there are two options, an individual submission to the RFC
editor, or via the DNSEXT-WG. Each has its advantages. Olaf has already
given me some guidance, I'd appreciate hearing (perhaps privately) from
DNSEXT-WG members on the best way to proceed.

We are aware this RFC might be viewed as PowerDNS promotional material, it
is hard to defend ourselves against that allegation. This draft is written
because of a profound worry over the practical security of common current
DNS resolver implementations.

We do point out that there are (at least) two freely available nameserver
implementations that adhere to the recommendations set out in this draft,
and that the relevant PowerDNS products are 'free as in speech' as well. 

We hope list members will review this RFC draft from a technical
perspective, and that we can as is customary discuss without descending into
comparing specific implementations.

Kind regards,

bert hubert 
Remco van Mook

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Aug 2006 20:12:35 +0000

have you seen draft-ietf-dnsop-reflectors-are-evil ?

---

From: bert hubert <[email-masked]>
Date: Thu, 10 Aug 2006 22:52:20 +0200

> have you seen draft-ietf-dnsop-reflectors-are-evil ?

Yes we have, but it appears to address a different (albeit interesting)
issue. 

	Bert.

---

From: bert hubert <[email-masked]>
Date: Sat, 19 Aug 2006 20:45:02 +0200

> DNSEXT-WG members on the best way to proceed.

After hearing from some members, we've decided to submit our draft in hopes
of it becoming a WG document. It can be found here:

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=15083

and here:

http://www.ietf.org/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt

As everybody appears to be on holiday, we don't expect a lot to happen
immediately, but we hope that we can work with the WG to work out the
kinks. We already know that the abstract contains some double words.

We are also looking at several pointers we've received to related documents,
and if it is worthwhile to add references to these documents. 

Thanks,

Bert & Remco

---

From: Florian Weimer <[email-masked]>
Date: Sun, 20 Aug 2006 21:56:19 +0200

> http://www.ietf.org/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt

Some random notes:

  - You could explicitly mention that resolvers MUST NOT pass through
    message IDs generated by clients.

  - Restricting access to resolvers should not be a priority because
    interesting resolvers serve thousands of users, and you are
    probably able to find a host in that population which you can
    compromised and use to query the server.

  - Automatic fallback to TCP once a likely spoofing attack is
    detected could help to thwart the attack.  However, some operators
    undermine this approach by not providing TCP service.

---

From: bert hubert <[email-masked]>
Date: Sun, 20 Aug 2006 22:58:43 +0200

>     message IDs generated by clients.

Will do, thanks. This is probably the root cause of the forwarder based
spoofing?

>     compromised and use to query the server.

Restricting access is good anyhow to prevent DNS amplification attacks,
which are all the rage now. Even reducing the number of IP addresses that
can try to control your nameserver from "the entire internet" to "several
millions" makes sense from an anti-spoofing standpoint. It all raises the
bar.

For anti-spoofing reasons alone it might perhaps not be the highest
probability, but combined with amplification attacks it is.

>     undermine this approach by not providing TCP service.

Indeed - and it is hard to list it as a 'MAY' as the other RFCc don't offer
this option. So far, this draft only restricts your options, it does not
recommend anything at variance with existing RFCs. 

Thoughts? I really don't know what is proper in such cases.

Thanks for your input!

	Bert

---

From: Florian Weimer <[email-masked]>
Date: Mon, 21 Aug 2006 01:19:13 +0200

> Will do, thanks. This is probably the root cause of the forwarder based

I don't think so, but it's hard to tell because to my knowledge, no
one has published irrefutable evidence that this is in fact a problem
with current software (or the attacks were deliberate).

My understanding is as follows:

  - There are basically three operating modes for caching resolvers:

    (1) Query authoritative name servers directly, starting at the
        root.

    (2) Query a second cache.  Alternatively, fetch the data using
        method (1).

    (3) Always query another cache ("foward only" in BIND speak).

  - (1) is as safe as you can get using your validation function.

  - (3) is safe except for some broken MTAs which do not validate the
    completeness of data returned in the additional section (leading
    to a violation of RFC 2821).  It is also unsafe if a cache
    constructs answer sections based on data learnt from additional
    sections, which is a violation of RFC 1034 even if the data is
    validated because RR sets in additional sections are not
    necessarily complete.

  - Method (2) remains.  What happens is that the query returned from
    the second cache (say, a BIND 8 server) contains an unsanitized
    copy of the authority section (see dig "dig @61.175.199.135
    ns1.hi2000.net" for an example, which happens to predate the cache
    poisoning attacks by several months).  For some reason, the first
    cache uses this authority information in subsequent queries.

The impact of method (2) is still mysterious to me because I don't
know when the first cache is considered and when it's not.  You
obviously need both, otherwise your are basically operating in mode
(3), and you inherit whatever validation the second cache performs.

> Restricting access is good anyhow to prevent DNS amplification attacks,

See "dig se. any +bufsize=4096" for an example why this won't work.

> recommend anything at variance with existing RFCs. 

The following recommendation in RFC 1123 gives at least some wiggle
room:

| A name server MAY limit the resources it devotes to TCP queries, but
| it SHOULD NOT refuse to service a TCP query just because it would
| have succeeded with UDP.

Of course, RFCs aren't very helpful if they don't match existing
practice.

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 31 Aug 2006 15:18:10 +0300

>  * http://ds9a.nl/rfc/dns-anti-spoofing.html

I read the above draft.  A few comments:

RFC3833 lists a number of different threats against the DNS, and the
term "DNS spoofing" is commonly used to refer to at least three of
them:

  2.1.  Packet Interception
  2.2.  ID Guessing and Query Prediction
  2.3.  Name Chaining

The draft covers threat 2.2, "ID Guessing and Query Prediction", in
excellent detail, but makes no mention of the others.  It would be
helpful to note in the draft that the term "DNS spoofing" can also
refer to threats other than those discussed in the draft.

As an aside, someone ought to write an RFC describing and
recommending, or even mandating, countermeasures against threat 2.3,
"Name Chaining".  All caching server implementations in common use
today already implement such countermeasures, typically based on
discarding records whose owner name is outside the domain whose
authoritative servers are being queried.  In practice, these
countermeasures are no longer optional, but there is still no IETF
document discussing them.

>  Given the above, a resolver MUST:
>
>   o  Use a new random source port from its available range for each
>      outgoing query

I don't think this MUST is realistic for high-volume servers.  In
practice, most caching servers run on operating systems that require a
separate open file descriptor for each port, and on a busy server the
number of outstanding queries can easily exceed the number of
available file descriptors.
-- 
Andreas Gustafsson, [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 31 Aug 2006 16:39:31 +0200

On Sat, Aug 19, 2006 at 08:45:02PM +0200,
 bert hubert <[email-masked]> wrote 
 a message of 35 lines which said:

> After hearing from some members, we've decided to submit our draft
> in hopes of it becoming a WG document. It can be found here:

Good document, I've read it and I find it fine.

But it should be submitted to the dnsop WG, no, since it does not
change the protocol?

---

From: Robert Story <[email-masked]>
Date: Thu, 31 Aug 2006 13:42:08 -0400

On Thu, 31 Aug 2006 15:18:10 +0300 Andreas wrote:
AG> >  Given the above, a resolver MUST:
AG> >
AG> >   o  Use a new random source port from its available range for each
AG> >      outgoing query
AG> 
AG> I don't think this MUST is realistic for high-volume servers.  In
AG> practice, most caching servers run on operating systems that require a
AG> separate open file descriptor for each port, and on a busy server the
AG> number of outstanding queries can easily exceed the number of
AG> available file descriptors.

What about relaxing this rule a bit? Simply deleting the word 'new'
would allow for using a pool of N random ports, where 1 < N < OS
file descriptor limit. And if N is small, periodically cycling some/all
of the pool might be a good idea too.

-- 
Robert Story
SPARTA