DNS - connection limit (without any extra hardware)

On Sun, 10 Dec 2006, Petri Helenius wrote:

>> Virtual patching.
>
> How do I virtual patch the machine in ireland which
attacked my mail server 
> just a few minutes ago?

You don't patch the machine in Ireland, but once your
"virtual patching 
box" identifies a hostile system and identifies what it
is infected with, 
it can then do the virtual patching on your end so that all
subsequent 
pkts entering from that machine in Ireland are cleaned and
no longer 
hostile.

-Hank

On Sun, 10 Dec 2006, Hank Nussbacher wrote:
> 
> On Sun, 10 Dec 2006, Petri Helenius wrote:
> 
> >> Virtual patching.
> >
> > How do I virtual patch the machine in ireland
which attacked my mail server 
> > just a few minutes ago?
> 
> You don't patch the machine in Ireland, but once your
"virtual patching 
> box" identifies a hostile system and identifies
what it is infected with, 
> it can then do the virtual patching on your end so that
all subsequent 
> pkts entering from that machine in Ireland are cleaned
and no longer 
> hostile.

I don't follow. Three monkies? Hitchhiker's Guide towel?

	Gadi.

> -Hank
> 

Hank Nussbacher wrote:
> On Sun, 10 Dec 2006, Petri Helenius wrote:
>
>>> Virtual patching.
>>
>> How do I virtual patch the machine in ireland which
attacked my mail 
>> server just a few minutes ago?
>
> You don't patch the machine in Ireland, but once your
"virtual 
> patching box" identifies a hostile system and
identifies what it is 
> infected with, it can then do the virtual patching on
your end so that 
> all subsequent pkts entering from that machine in
Ireland are cleaned 
> and no longer hostile.
Does it reset the evil bit too?

Pete

On Sun, 10 Dec 2006, Daniel Golding wrote:

> Folks should also look at some of the DNS appliances (I
know, this is "extra 
> hardware"). Although the usually run BIND, they
tend to be fairly optimized 
> and have extra management functionality that may help
with the rate limiting 
> (if not, its probably a feature request that the
vendors would entertain 
> rapidly, as there's some pretty intense competition).
Some folks to talk to - 
> Infoblox and Bluecat.

I'm not sure what you mean by "optimized" here,
but I suspect that 
the only part optimized is the user interface for
configuring 
per-client policies that still do not scale, but I would be
glad to 
be proven wrong.

> If you have really large DNS rate requirements, I'd 
> consider talking to Nominum.

I agree with you there; but that's sort of a given 

matto

--mattsnark.net------------------------------------------&l
t;darwin><
   Moral indignation is a technique to endow the idiot with
dignity.
                                                 - Marshall
McLuhan

On Monday 11 December 2006 16:15, you wrote:
> > I use to slave "." which can save time
on recursive DNS servers when they 
have
> >a lot of dross to answer (assuming it is totally
random dross).
>
> I'm not sure to understand your solution.
> You configure your name-server as a slave-root-server?

Yes. Most of the root server traffic is answering queries
with "NXDOMAIN" for 
non-existant top level domains, if you slave root on your
recursive servers, 
your recursive servers can answer those queries directly
(from the 120KB root 
zone file), rather than relying on negative caching, and a
round trip to the 
root servers, for every new non-existant domain.

The drawback is you provide the answer with the authority
bit set, which isn't 
what the world's DNS clients should expect, but DNS clients
don't care about 
that one bit (sorry).

If the root zone file changed quickly it might also cause
other problems!

Paul V was very cautious about it as a method of running a
DNS server, but if 
the recursive servers are being barraged with queries for
(different) 
non-existent top level domains I think it is probably
preferable to the 
servers being flattened (and/or passing that load onto the
root name 
servers).

If the queries are for existing, or the same, domains each
time, it won't 
provide significant improvement.

I suppose any server issuing more than 2000 or so queries a
day to the root 
servers would potentially save bandwidth, and provide a more
responsive 
experience for the end user. But one also has to handle the
case of the root 
zone potentially expiring, not something I ever allowed to
happen, but then 
I'm not the average DNS administrator.

I've used this technique extensively myself in the past with
no issues, but 
I'm not using it operationally at the moment. Since the load
average on our 
DNS server is 0.00 to two decimal places I doubt it would
make a lot of 
difference, and we host websites, and email, not randomly
misconfigured, 
home, or business user PCs. So mostly we do lookups in
in-addr.arpa, a 
depressingly large proportion of which fail, or look-ups for
a small set of 
servers we forward email to (most of which exist, or I
delete the forward).

On Mon, 11 Dec 2006, Simon Waters wrote:

> Yes. Most of the root server traffic is answering
queries with
> "NXDOMAIN" for non-existant top level
domains, if you slave root 
> on your recursive servers, your recursive servers can
answer those 
> queries directly (from the 120KB root zone file),
rather than 
> relying on negative caching, and a round trip to the
root 
> servers, for every new non-existant domain.

That would require configuring my caching server with
authoritative 
zones, and it seems prevailing wisdom (at least with BIND 
configurations?) is to keep the peanut butter seperate from
the 
chocolate, no matter how great they taste together, to the
best
of my knowledge.

matto

--mattsnark.net------------------------------------------&l
t;darwin><
   Moral indignation is a technique to endow the idiot with
dignity.
                                                 - Marshall
McLuhan

In article <Pine.LNX.4.64.0612111613480.26126pants.snark.net> you write:
>
>On Mon, 11 Dec 2006, Simon Waters wrote:
>
>> Yes. Most of the root server traffic is answering
queries with
>> "NXDOMAIN" for non-existant top level
domains, if you slave root 
>> on your recursive servers, your recursive servers
can answer those 
>> queries directly (from the 120KB root zone file),
rather than 
>> relying on negative caching, and a round trip to
the root 
>> servers, for every new non-existant domain.
>
>That would require configuring my caching server with
authoritative 
>zones, and it seems prevailing wisdom (at least with
BIND 
>configurations?) is to keep the peanut butter seperate
from the 
>chocolate, no matter how great they taste together, to
the best
>of my knowledge.
>
>matto

	No.  The wisdom is to not make your authoritative servers
	caches.  This is not the same as not making your caches
	authoritative for certain zones.  Just don't have the
caches
	listed in the NS RRsets.  Note:  You will need to configure
	your master server(s) to notify the caches for the zone
	that slave as the automatic mechanisms won't discover them.

	Mark

>--mattsnark.net------------------------------------------&l
t;darwin><
>   Moral indignation is a technique to endow the idiot
with dignity.
>                                                 -
Marshall McLuhan

On Dec 8, 2006, at 9:56 AM, Petri Helenius wrote:
> Has anyone figured out a remote but lawful way to
repair zombie  
> machines?

Having remote power control over all of our customer's
equipment.

Though the customer might not consider that a
"repair", I do 

-- 
Jo Rhett
senior geek
Silicon Valley Colocation