Subject: DNS Server DoS Attacks

From: "Alec H. Peterson" <[email-masked]>
Date: Fri, 22 Nov 2002 17:37:31 -0700

These attacks seem to be on the rise.  There were the well-publicized ones 
on the root servers a few weeks ago, and yesterday UltraDNS was hit with 
one.  It occurs to me that these attacks have the potential to completely 
shut down the DNS system if they are structured properly.  I have a thought 
on how to make the system more resiliant to authoritative servers getting 
hammered, and was interested in some thoughts on it.

My thought is to add another TTL to DNS responses, similar to the SOA 
maximum parameter.  The current TTL would be similar to the SOA minimum. 
This would still allow for records to expire in a reasonable amount of 
time, but it would also allow for DNS responses to be answered in the event 
that servers in the hierarchy are unreachable for some reason.  It occurs 
to me that it is possible to retrofit existing DNS servers to have a static 
maximum timeout without any protocol modifications.

Anyway, the way I see it since DNS already has a caching infrastructure 
built in it makes sense to take extra advantage of that infrastructure when 
things are under attack.

Alec

--
Alec H. Peterson -- [email-masked]
Chief Technology Officer
Catbird Networks, http://www.catbird.com

--
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: Sat, 23 Nov 2002 01:54:00 +0000

> that servers in the hierarchy are unreachable for some reason.

keeping copies of somebody else's authoritative data and using or reusing
them beyond the (TTL,SOA) parameters would be a disaster.  even with DNSSEC
it will be dangerous, but the amount of bad data that would circulate without
end under such a scheme is unthinkably horrible.  (BIND has been criticised
for accelerating TTL depreciation when reusing additional data, but this is
the kind of data pattern this was designed to end.)

> It occurs to me that it is possible to retrofit existing DNS servers
> to have a static maximum timeout without any protocol modifications.

at the moment, only 2% of the queries hitting the root servers actually need
to be answered -- the rest is pure swill, just errors and sideeffects.  there
is, unfortunately, no way to know in the upstream routers which 2% is which,
and so we deliver the whole thing and answer it as best we can.  what this
means, though, is that the impact on a root server attack would take several
days to be felt.  while pulsar-style attacks can be harder to track to source,
the "off" part of the cycle leaves time for retries to succeed and thus let
the "useful" 2% still bear some fruit.  a solid attack lasting several days
would be trackable, unless it comes from a million-drone windows/xp army,
which leads to the ugly necessary of "massive-scale bgp4 anycasting", which
at least two root server operators are already planning to implement.

(or we could secure the edge, but i guess that's too hard.)

> built in it makes sense to take extra advantage of that infrastructure when 

if people would just cache what they already receive, then 98% of the queries
seen by the root servers would never be sent.  so, i think there's ample
evidence to refute the idea that the internet's caching infrastructure is
a model we can build on.

---

From: "Alec H. Peterson" <[email-masked]>
Date: Fri, 22 Nov 2002 19:07:00 -0700

--On Saturday, November 23, 2002 1:54 AM +0000 Paul Vixie <[email-masked]> 
wrote:

>
> if people would just cache what they already receive, then 98% of the
> queries seen by the root servers would never be sent.  so, i think
> there's ample evidence to refute the idea that the internet's caching
> infrastructure is a model we can build on.

That is a good point, that had already been made to me before I posted that 
actually.

I see your point that a sustained attack should be easy to track down, but 
I think it would be really nice if we could find a way to preemptively come 
up with a way to help mitigate these attacks, instead of operating in a 
reactive mode.

Alec

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Nov 2002 02:33:43 +0000

> up with a way to help mitigate these attacks, instead of operating in a 

well, like i said, we could secure the edge.

---

From: "Alec H. Peterson" <[email-masked]>
Date: Fri, 22 Nov 2002 19:55:11 -0700

> well, like i said, we could secure the edge.

While we're at it why don't we deploy IPv6.

Alec

---

From: Bill Manning <[email-masked]>
Date: Fri, 22 Nov 2002 19:49:35 -0800 (PST)

% --On Saturday, November 23, 2002 2:33 AM +0000 Paul Vixie <[email-masked]> 
% wrote:
% > well, like i said, we could secure the edge.
% 
% While we're at it why don't we deploy IPv6.
% 
% Alec
% 
	we are. :)  just not as quickly or as transparently
	as some would like..

--bill

---

From: "Al Costanzo" <[email-masked]>
Date: Sat, 23 Nov 2002 00:13:40 -0500

Hi,

To the best of anyone knowledge on the list.  Did anyone ever deploy IPv7 or
is it completely dead now.  Not that I really seen 6 deployed but ....

Al Costanzo

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Nov 2002 06:16:46 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

The DNS protocol should be augmented with a separate protocol for
distributing (signed) copies of the root zone (in a sensible format)
through USENET, mailing lists, etc. ISPs can and should run local root
servers.

I agree with the idea of caching root zone data for a very long time.
The root-zone protocol should promise that every piece of data will last
for a month.

Effects on load: Everybody will receive the entire zone, rather than
just the parts they need. On the other hand, any sensible format would
be much smaller than DNS packet format. More importantly, the data will
be cached much more effectively than it is with the current root-zone
protocol. Most importantly, the load will be very widely distributed.

Side benefit: It will be easy to expand to hundreds of .com servers. Of
course, the root servers could pack more than 20 .com server addresses
into a 512-byte UDP packet with the current protocol (if they drop the
silly one-name-one-address notion), and nobody would complain if the
root servers selected those addresses randomly from a much larger pool;
but distributing the root zone lets ISPs pick nearby .com servers.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Rob Thomas <[email-masked]>
Date: Sat, 23 Nov 2002 00:49:55 -0600 (CST)

] well, like i said, we could secure the edge.

Agreed.  In one study I conducted of an oft' attacked web site, 66.85%
of all naughty packets received were obvious bogons.  Not just spoofed
legitimate addresses, but outright bogons.  Honestly if I never receive
another packet from 127.1.2.3 I'll be a happy man.  :)  Think of the
amount of garbage we could avoid with some reasonably simple filtering.

The results of the study (along with a few others) can be seen in a
presentation I gave to Surfnet entitled "60 Days of Basic Naughtiness."
You will find a zip'd copy, in Powerpoint format, here:

http://www.cymru.com/Presentations/60Days.zip

The analyzed attacks are tame in comparison to what is seen today.  The
simple things work, often to a great degree.  Raising the bar won't
solve the world's problems, but it will make things a little better.

-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

---

From: "John M. Brown" <[email-masked]>
Date: Sat, 23 Nov 2002 00:47:04 -0700

packet forwarding engines won't tell the difference between 
a good query and a bad query without serious penalty to the
PFE performance.

your idea would break caching and cause more flotsam to hang 
around in various systems. 

personally, I like having things cache age out of the DNS
during an attack.  lets me change the A RR for a victim to
a different IP.  Useful for those scripts that don't update
their cached IP for the victim name.

three things will help provide better strength against DDOS
attacks.

a)  properly managed anycast of the root infrastructure.

b)  securing the edge of the net.  remove the zombie hosts
    and they can't be used as a tool.

c)  signing the root zone, more for layer 8 reasons than others.

when providers decide to start applying various tools to improve
security on the edge (ergo clients) things will become better.

John M. Brown, CEO
Chagres Technologies, Inc
Le Geek

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alec H. Peterson
> Sent: Friday, November 22, 2002 5:38 PM
> To: [email-masked]
> Subject: DNS Server DoS Attacks
> 
> 
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.

---

From: Jim Reid <[email-masked]>
Date: Sat, 23 Nov 2002 06:30:06 -0800

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    djb> The DNS protocol should be augmented with a separate protocol
    djb> for distributing (signed) copies of the root zone 

I can't believe you just said that. Does this mean you have recanted
on your previous strident objections to DNSSEC? :-)

---

From: "Alec H. Peterson" <[email-masked]>
Date: Sat, 23 Nov 2002 07:48:52 -0700

> a good query and a bad query without serious penalty to the

I don't think I understand, what does my suggestion have to do with packet 
forwarding engines distinguishing between good and bad queries?

> around in various systems.

Well yes, it would break the current caching model by changing it.

> their cached IP for the victim name.

But if your authoritative DNS servers aren't even reachable to have the 
cache get re-populated then what good is it to have the cache get aged?  My 
proposal doesn't change the current cache aging system, you can still have 
a 10 minute TTL and have an authoritative server re-query after the 
original 10 minutes has expired.  This just _allows_ caching nameservers to 
keep stuff for longer if it is not possible to re-populate the cache due to 
unreachable nameservers.

> a)  properly managed anycast of the root infrastructure.

Agreed that anycast does help.

>     and they can't be used as a tool.

Agreed.

> c)  signing the root zone, more for layer 8 reasons than others.

I fail to see how signing the root zone would keep somebody from flooding 
me with packets.

> security on the edge (ergo clients) things will become better.

No argument.

Alec

---

From: Randy Bush <[email-masked]>
Date: Sat, 23 Nov 2002 08:07:37 -0800

perhaps folk should review steve bellovin's nanog talk (dc?) on
pushback.

randy

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Nov 2002 17:28:16 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  your subscription address is
  [email-masked], please post from it or
  fix subscription your subscription address! ]

PGP 2048-bit ElGamal signatures are probably the best choice for
root-zone distribution today: the signature format is reasonably simple
and reasonably well documented, and free signature-checking software is
already widely deployed. Of course, the root-zone protocol can support
multiple signatures on the same file.

> on your previous strident objections to DNSSEC? :-)

Have you stopped beating your wife, Jim?

Anyone who wants to see what I've actually said about DNSSEC should read
http://cr.yp.to/djbdns/forgery.html.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Nov 2002 19:53:20 -0000

After receiving an email response from the Netherlands, I realize that I
should explain for international readers (and perhaps for some American
illiterates) what ``Have you stopped beating your wife?'' means.

That phrase is, at least in English, a standard reference to a fallacy
pointed out by Aristotle and also known as

   * plurium interrogationum (``many questions'');
   * the fallacy of interrogation;
   * the fallacy of presupposition;
   * the loaded-question fallacy; and
   * the complex-question fallacy.

The fallacy occurs when a question posits an unproven assumption. For
example, the fallacious question ``Have you stopped beating your wife,
Jim?'' presumes that Jim has a wife, and has been beating her; there is
no evidence for these presumptions, and in fact we all presume the
opposite.

Jim asked a fallacious question making certain incorrect presumptions
about what I have said about DNSSEC. I responded by pointing out the
fallacy and the underlying facts.

---

From: "John M. Brown" <[email-masked]>
Date: Sat, 23 Nov 2002 13:33:23 -0700

> Sent: Saturday, November 23, 2002 7:49 AM
> To: [email-masked]; [email-masked]
> Subject: RE: DNS Server DoS Attacks
> 
> 
> > a good query and a bad query without serious penalty to the PFE 
> > performance.
> 

long flight, coffee == empty, it was part of a different conversation
that slipped into this thread.  sorry.
 
Some people where arguing that you could filter via ACL's and such,
that works until the poison (bad packets) looks, smells and tastes like
what you think lunch should be.
 
> But if your authoritative DNS servers aren't even reachable 
> to have the cache get re-populated then what good is it to 
> have the cache get aged?  

keeps the system cleaner.  see pauls answer

> My proposal doesn't change the current cache aging system, you 
> can still have 

SO how does this caching change handle a zone going away ?  If I remove
a zone from service, is that not like a DOS ??

what I'm hearing is " lets have a static value that keeps data in a
cache
longer than what the owner wants, just incase things break"...  is that
correct ??
 
> I fail to see how signing the root zone would keep somebody 
> from flooding me with packets.

It doesn't.  It ""protects"" the zone, its a layer 8 warm and fuzzy
thing.  It does help make sure that the anycast box you are asking is
serving the same data as all of the others, and if its not, you can
ignore that server.

---

From: "Alec H. Peterson" <[email-masked]>
Date: Sat, 23 Nov 2002 13:37:14 -0700

> keeps the system cleaner.  see pauls answer

In the normal case, yes, and I agree that it does end up making the cache 
uglier.  But isn't it better to keep things running when things are going 
wrong?

> a zone from service, is that not like a DOS ??

The entries will stay around for a while.  If somebody really wants all of 
the DNS to disappear immediately then this would present an issue, but is 
this really a huge concern?

> longer than what the owner wants, just incase things break"...  is that

Not at all.  The owner would have complete control over his TTLs, just like 
he does now.  If the owner of the zone doesn't want to take advantage of 
this feature then he doesn't have to.

> serving the same data as all of the others, and if its not, you can

Uhm, I certainly don't disagree with that, but I still fail to see how it 
relates to the discussion at hand.

Alec

---

From: "John M. Brown" <[email-masked]>
Date: Sat, 23 Nov 2002 13:52:41 -0700

> relates to the discussion at hand.

only that I had mentioned it as one of the things to be done
to help protect anycasting the root zones, and you had asked
how this helps protect.  its now not part of the rest of
this thread.

---

From: Rob Payne <[email-masked]>
Date: Sat, 23 Nov 2002 16:42:01 -0500

> multiple signatures on the same file.

Let me see if I understand your proposal.  You want to turn the root
zone into a signed "hosts.txt" (RFC 952, 953), and how, exactly does
that scale this time around when it did not scale the last time?  More
distribution methods make for more attack vectors and more
opportunities for DOS against different groups.  Maybe it's time to
review section 2.1 of RFC 1034 to see the problems with that model.

Your previous message said:

> The root-zone protocol should promise that every piece of data will
> last for a month.

That data should be guaranteed to last a month from when, exactly?
From the time it was signed, or from when it downloaded?  The former
will mean that *everyone* will be attempting to grab this at the same
time (every thirty days from whenever this process starts), the latter
will mean that the data can *never* change.  The current situation is
that data is valid for a shorter period of time (1 TTL) and systems
can grab it at any time, meaning that an attack has to last for the
current (1/2 TTL) to create an outage that will effect most systems.

If we go to a set of static data, valid for a fixed time frame we
narrow the "window of opportunity" for attack/DOS to a much smaller
period (the first [time period] at the beginning of a 30 day cycle
when everyone is grabbing the root zone, thus putting heavy loading on
servers that are distributing the new information.)  How, exactly does
this provide for a system that is more resistant to attack?  It
actually makes a well planned attack (around the first [time period]
of the update cycle) more likely to create an effective DOS.

And, of course, this still ignores most of the reasons for DNSSEC.
Being able to get trustworthy data from entities with unknown motives
is not possible when the data comes to you without its covering
signatures.  The provider of my DNS service being able to check
signatures which they do not pass along with the data does not do
anything to provide me with usable data.

Nym-based names and bookmarks do not fix the problem.  Each time a key
is compromised, the name changes (the key changes and therefore the
fingerprint of the key which makes up the nym changes).  If there is
no method for a chain of trust check on DNS signature keys, owners of
hosts end up making a choice between invalidating all of the
"bookmarks" that other people have stored for their host, or
continuing to use the compromised key.

				 -rob

---

From: Rob Payne <[email-masked]>
Date: Sat, 23 Nov 2002 16:43:39 -0500

> uglier.  But isn't it better to keep things running when things are going 

It is not better, if "keeping things running" keeps the problem from
getting fixed.

				 -rob

---

From: "Alec H. Peterson" <[email-masked]>
Date: Sat, 23 Nov 2002 16:07:15 -0700

> It is not better, if "keeping things running" keeps the problem from

*sigh*

If people think I'm advocating implementing this instead of attacking DoS 
vulnerabilities at their source then obviously I'm not communicating very 
well.

Alec

---

From: "Alec H. Peterson" <[email-masked]>
Date: Sat, 23 Nov 2002 16:20:10 -0700

So let me re-state in no un-certain terms my goal here, so that nobody can 
imply anything that is not meant to be implied from my statements.

My proposal (essentially a second TTL that keeps records around longer in 
the event that authoritative servers are unable to answer) is _NOT_ meant 
to be any sort of 'solution' to DoS attacks.  I feel that it is still 
incredibally important for us to do everything that we can to secure the 
edge and keep these attacks from happening.

HOWEVER, we have been trying to do that for years, and yet the DoS attacks 
persist.  My proposal is intended to harden our infrastructure so that we 
can tolerate these attacks while they are still going on.  Certainly I 
would rather we secure the edge, but it is obvious that DoS attacks still 
occur.  I feel it is our duty to do everything we can to operate within the 
parameters of reality on the Internet today.

So, we have two options.  We can continue to say 'secure the edge' and hope 
that makes the problem go away.  Or we can continue to work on securing the 
edge while also hardening our existing infrastructure to deal with the 
issues we face here and now.

So, with those parameters in mind, I hope people now clearly understand my 
goal here.  If there has been any misunderstanding please let me know.

Alec

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Nov 2002 09:27:12 -0000

Rob Payne writes:
> You want to turn the root zone into a signed "hosts.txt" (RFC 952,
> 953), and how, exactly does that scale

I already answered that: ``Effects on load: Everybody will receive the
entire zone, rather than just the parts they need. On the other hand,
any sensible format would be much smaller than DNS packet format. More
importantly, the data will be cached much more effectively than it is
with the current root-zone protocol. Most importantly, the load will be
very widely distributed.''

The last factor is, as I said, the most important one. USENET wouldn't
notice if ten copies of the root zone---or ten thousand copies---were
sent out every day.

> it did not scale the last time

Nobody really tried to make it scale, but this is beside the point.
``Root zone'' does not mean ``complete list of Internet hosts.''

---

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Nov 2002 10:02:42 -0500

At 16:20 -0700 11/23/02, Alec H. Peterson wrote:
>My proposal (essentially a second TTL that keeps records around longer in the
>event that authoritative servers are unable to answer) is _NOT_ 
>meant to be any
>sort of 'solution' to DoS attacks.  I feel that it is still incredibally
>important for us to do everything that we can to secure the edge and 
>keep these
>attacks from happening.
>

The problem with the proposal is that it breaks one goal of the DNS. 
DNS is a distributed database and as such needs to maintaining 
coherency in the answers it gives.  The TTL is the main parameter 
that is available to allow caches (needed to alleviate high demand on 
authoritative servers and paths to them) to attempt to remain 
coherent.  By instructing caches to hold data any longer than the 
TTL, you are making it less likely the DNS can maintain coherency.

It is also important to note that the TTL is really the only way a 
zone, via an authoritative server, can inform remote caches of how 
often the zone expects to refresh the data.  Masters and slaves have 
the SOA parameters to govern zone transfer schedules.  The last 
parameter in the SOA is used for negative caching,  and just that, in 
caches.

If we were to add a second TTL (as in 'in emergency'), then a lot of 
other activity in DNS would be more complicated.  E.g., in 
considering key roll over, we are trying to determine how much time 
should elapse before removing a key.  The current calculation 
involves the TTL as part of an estimate as to when a key will 
completely disappear from the DNS.

That's the more pragmatic answer as to why addressing DOS by 
encouraging caches to hold data longer should be discouraged.  A more 
philosophical answer is that addressing security concerns should not 
overwhelm the main mission.  No answer to a vulnerability should 
alter DNS's core goals, and database coherency is one of the most 
important.

Since we often drop in to gross analogies when trying to dismiss an 
idea, I will include this one:

This would be like amputating your hand so that that you won't break a finger.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer