Subject: RE: DNS Server DoS Attacks

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

--On Saturday, November 23, 2002 13:33 -0700 "John M. Brown" 
<[email-masked]> wrote:

>
> 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?

>
> SO how does this caching change handle a zone going away ?  If I remove
> 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?

>
> 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 ??

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.

>
> 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.

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

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: "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: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: 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