[no subject]

[Mike Lewinski <mike () ROCKYNET COM>]

Abe,

Thanks for the update.

> The activity you describe is a result of our global load balancer. When a
> client behind your DNS server makes a request to one of our customer's
> sites, our load balancer has all of our sites send out an rtt packet to

^^

I count a total of  20 packets from that site alone in just 10 seconds,
without even looking hard through my logs for a period of density.

I'm curious to know how this is going to work with people who are dropping
1024. Our DNS server has a "deny unless permitted" confguration. If my
action is to drop the packet silently, to them it must look like we're not
even on the map.

Believe it or not someone recently gave me a similiar response as to why
they were querying us for "version.bind". I think that they must have
stopped that- I haven't seen it in a while, and I'm sure it generated lots
of inquiries/complaints.

If this is what they claim it is, I'd say it's poorly written to be hitting
us so often, and to be assuming that their packets will make it even
through... I notice that one of the features listed at Cisco's web site is
as follows:

"Enhanced Server Verification with Multiple Port Connect Test
 Prior to this enhancement, DistributedDirector could evaluate server status
by performing a TCP connect test to a single port. The Enhanced Server
Verification with Multiple Port Connect Test feature allows multiple connect
ports to be specified. If any one of the connect tests fail, the server is
considered down."

It's not clear to me if this test is going to the requested web host, or to
our DNS servers or both. It does seem dumb that a client who just sent a
request would be considered "down", but I can also see how many firewalls
will always be in conflict with a system like this. A good configuration
will drop virtually anything sent from the remote server that's not a
response to the original query, and since it's UDP there's nothing for the
remote "load balancer" to measure latency against. If they ping or send tcp
packets they'll trigger IDS/firewall rules. And they can't assume that the
client is really a server, because incoming DNS requests could be similarly
blackholed.

Heh, this thing wants to portscan us, plus check that the webserver it's
sending the client to is actually up. Probably DNS resolution takes so long
that the "client" is sitting there repeatedly hitting the refresh button and
bitching at their ISP (who's servers are being packet flooded by load
balancers at the moment....)

Mike