RFC: workaround for unwanted dynamic updates

[Nate Campi]

On Thu, Dec 13, 2001 at 02:53:30PM -0800, Doug Barton wrote:
> 
> 	Prior to my implementing this fix it was not uncommon to get hit
> with 20 failed dynamic update requests per second. The overhead of
> processing those requests was just shredding the server. At its best that
> server was doing 40 queries per second, currently (without the dynamic
> updates overhead) it's doing 3 times that many qps.

Do you really get shredded by 40 queries per second, or even three times
that? Check out http://www.campin.net/DNS/index.html for some stats
from a couple nights ago on a couple of my servers. My little Sun Netra
at the top handles over two thousand queries a second from mail servers 
(any, a and mx queries for outside domains), sometimes for long periods
The load average gets up a little over 1.0 during such times, and this 
is on a single processor box (I'm going to build them their own caching 
nameserver for their mail cluster, BTW).

I just uploaded some other graphs, one that's an up to date query graph,
and one that's a load average graph for that same host. 

http://www.campin.net/DNS/stats.gif and
http://www.campin.net/DNS/load.gif

You can see that two thousand queries a second brings my load average to
around 1.0. This is for outside data, recursion.

All this makes me wonder if you don't need better hardware. Maybe you
run other software on the box that is loading it as well.

> 	My purpose in writing is twofold. First, to offer this as a
> potential solution for others that are in my position; with apologies to
> anyone who might have already suggested this in a thread that I missed.
> Second, is to throw the topic open for discussion to see if there might be
> a downside that I missed in my testing. Before deploying this I did test
> with a win 2k machine to try and make sure I wasn't breaking anything. The
> potential downside seems small given that the updates already were not
> succeeding. I'm aware that the MNAME field is not generally used by
> anything other than dynamic updates, although some ccTLD registries
> (especially .fr) do check to see if this field matches the primary name
> server... although I still don't understand why. :) To avoid that issue,
> I'm not changing my .fr zone file template, although I've changed the
> others. I've been using the bogus MNAME for a week now, so far no
> customer, or any other kind of complaints related to this issue.

Check out the mname for lycos.com - and what it resolves to. Let someone
send their dynamic updates to that, or even better try to attack it!

I've had my mname this way for about a month, with no ill effects
noticed.
-- 
Nate Campi | Terra Lycos DNS | SF UNIX Operations | (415) 276-8678

The Strong Lusethropic Principle states: "The more idiot proof the
software, the more it encourages the user to be careless and not
think. Therefore, idiot-proof software actually encourages,
contributes, and actually CAUSES lusers to be stupid."  
. 
The Weak Lusethropic Principle states: "As more idiot-proof software
becomes available, more idiots are able to use computers. Idiot-proof
software did not make or cause computer lusers; it simple allowed
lusers to use computers where they could not before."