On 10 Aug 99, at 17:09, David Lang wrote:
> On Tue, 10 Aug 1999, Dave Gillett wrote:
>
> > 1. How does DoubleClick identify the "client DNS server"?
>
> the "client DNS server" is the machine making the DNs request to
> DoubleClick
Aha... Presumably, the latency metric is used to determine what IP address
is returned via DNS. Okay, that makes sense.
> > 5. A properly-functioning DNS server has to accept TCP connections on port
> > 53, even if zone transfers are disallowed. Why not use that mechanism?
>
> it is an option in the software (the option I am picking in setting up the
> Resonate software at my company), but it is not nessasary for the client's
> DNS server to allow connections from the internet. In my case the DNS
> server that internal desktops use does not accept connections from the
> internet. It can request info from the internet but will only respond to
> local IP addresses.
[Which presumably means that you're not going to respond to the echo port,
either....]
Are you running a client-only network, a special case that I hadn't
considered? No, wait -- you wouldn't be installing Resonate in that case.
I'm used to a "split DNS", where a DNS server in the DMZ handles inbound
requests looking for advertised servers, and acts as a sort of proxy for
outbound requests from the internal DNS server that local clients all refer
to. [I don't, off the top of my head, recall *all* of the arguments for this
approach.]
So the latency-measurement traffic from DoubleClick all tries to hit our
DMZ DNS server. In this case, TCP port 53 would get a connection without
setting off alarms; port 7 gets a timeout and a firewall alert (and an
unhappy security admin).
I can see, from your example, that port 53 is not always going to work for
latency measurement. I'd still give it better odds than port 7, though.
David G
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
