On Tue, 18 Jun 2002, Roger Cornelius wrote:

> Hi,
> 
> Apologies because this is only partially related to gnatbox.
> 
> We have two win2kserver machines on our network which insist on making
> DNS queries to DNS servers not assigned to us.  The other machines on
> our net are win98, win2kpro, and one unix box.  This problem occurs only
> with the 2 win2kserver machines.
> 
> One machine was previously configured as a domain controller with a name
> of abc.  abc is not our registered domain name, but abc.com does exist.
> abc is configured to use xyz (another internal machine) for DNS service.
> abc is not generally used for interactive use.  Somehow, abc discovered
> the DNS server IP addresses (the ones listed by whois) for abc.com and
> is using them for queries.

Is that for all or the majority of queries?  It so, that is a
mis-configuration of the Windows box.

> 
> All our machines are configured (via DHCP) to use xyz for DNS.  xyz is
> configured to forward any DNS request it can't resolve to the external
> DNS servers assigned by our ISP.  I can see from the logs that queries
> are being made to our assigned DNS servers.  None of the machines on our
> net seem to have any problem resolving addresses, even after I
> implemented the block below.  Additionally, xyz is, for some reason,
> making DNS requests to two other servers at iana.org.
> 
> I've configured gnatbox to allow DNS requests to the servers assigned to
> us by our ISP, and to block requests to any other server.  This is
> working without any apparent harm, but the Active Filters section of
> System Activity shows several thousand blocked requests daily.
> 
> I guess my questions are:  Is it common/acceptable for a site to make DNS
> queries to other than it's own assigned servers?  Should I worry about
> it?  Do I even need the block?

It is quite normal for DNS servers to make queries all over the place.  
By design, DNS is a distributed database, and recursive queries are
expected .  

For any given domain, like ".com"  for example, there are a set of master
servers that are authoritative for the ".com" domain.  (Those would be
probably be the unexpected IANA servers you see being queried.)  Those
servers know about EVERY domain registered under ".com", but just 
about all they know about each one is the IP address of that domain's 
authoritative DNS server(s).

Suppose you want to look up www.yahoo.com.  The master ".com"  servers do
not know the address of www.yahoo.com, or even the address of yahoo.com.  
All they know is the address of yahoo.com's DNS server(s).  So, your 
DNS server would query an Internet master server, find the IP for 
yahoo.com's DNS server, and query that server for the actual address.  
Sometimes it takes queries to several servers to resolve a name into an IP 
address.

Now, it does not make sense for every machine on the Internet to make all 
these queries every time, so two concepts are introduced to reduce the 
amount of traffic.  One is caching, and the other is forwarding.  

Caching is pretty straightforward - if a server answers a query once, it
will remember the answer for a set period of time, and during that time it
will deliver the answer from its cache rather then do the entire query
over the Internet.

Forwarding allows for one server to execute the multiple recursive
requests needed to resolve a domain name into an IP address.  Some DNS
resolver clients (I THINK Windows 95 and 98) are not capable of doing
recursive queries; they have to pass off the queries to a server that will
do that for them.

Putting all the pieces together, most likely your internal DNS servers
(like "xyz") are attempting to do recursive queries (which they should)  
and failing that, they fall back to the DNS servers your ISP has assigned,
which accepts forwarding queries and does the recursive query for you and
returns the result.

Generally, there are 3 or 4 reasons to run an internal DNS server: (1) To
resolve names in YOUR domain, (2) to cache external requests to reduce
traffic and improve response, (3) to increase reliability by not
relying so heavily on your ISP's DNS servers, (4) to increase security.

Most every DNS server has a list of the Master Internet Nameservers, so
you actually don't even need to use your ISP's DNS at all.  You can just
let your own servers do the all queries.  On my network I have 2 internal
DNS servers, and they are both set up to query the Internet master servers
directly.  In DHCP, I've configured each client to use those two servers
first, and if they both fail, THEN my ISP's server.

In general this is slightly more secure than going to my ISP's server
first, since their machine is a more likely target to be compromised than
my internal servers that aren't even visible from the Internet.

Also, if your DNS server is trying to do recursive queries and failing and 
then falling back to your ISP's server, you will probably notice some 
delays the FIRST time a domain is accessed.  After that, it should be 
cached by your internal server, so it'll be much quicker.  (You can test 
this by pointing your browser at some obscure place no one usually 
accesses.)  You should either turn off recursive queries on your machine, 
or remove the FW block let it do its job.

BTW, were you getting just a few queries to abc.com, or did it look like
most or all of them were going there?  If it was just a few, it might
simply mean that someone in your organization was looking at something at
abc.com.

I hope this helps!

Michael O'Quinn

> 
> Anyone have a clue on how to stop these boxes from doing this?
> 
> Apologies if this was too off-topic, convoluted, or over/under
> explained.  If I left out anything important, let me know and I'll
> provide it if I can.
> 
> Thanks for any help.
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
To subscribe to the digest version first unsubscribe, then
 e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archive of the last 1000 messages:
 http://www.mail-archive.com/[email protected]

Reply via email to