packets to DNS port 53 from W2K AD server from olmost random source ports

  • Thread starter Thread starter Aram Kanjic
  • Start date Start date
A

Aram Kanjic

Hello!
We have two locations with diferent windows domains
connected with two routers over ISDN. One domain is NT
domain (domain A) and the other is a W2K domain (domain
B). Both domains are a single server domains. On the
domain B we have Active Directory integrated DNS on the
same server. The problem is that every two minutes domain
B call's domain A. After the first look at the router log
we saw that the packets that start the dial up com from
domain server B from diferent UDP ports from range 3000 -
5000 with a destination of server of the domain A to the
ports 53 and 1724. The server A is olso a proxy server.
We tried to block trafik on the routers for the ports we
don't need, but there are just to many of them. Is there
some other way out of our problem? We are olmost sure (
as we can be) that we dont have software which could
generate the traffic. We scaned all computers with Norton
antivirus and with ad-avare.
 
In
Aram Kanjic said:
Hello!
We have two locations with diferent windows domains
connected with two routers over ISDN. One domain is NT
domain (domain A) and the other is a W2K domain (domain
B). Both domains are a single server domains. On the
domain B we have Active Directory integrated DNS on the
same server. The problem is that every two minutes domain
B call's domain A. After the first look at the router log
we saw that the packets that start the dial up com from
domain server B from diferent UDP ports from range 3000 -
5000 with a destination of server of the domain A to the
ports 53 and 1724. The server A is olso a proxy server.
We tried to block trafik on the routers for the ports we
don't need, but there are just to many of them. Is there
some other way out of our problem? We are olmost sure (
as we can be) that we dont have software which could
generate the traffic. We scaned all computers with Norton
antivirus and with ad-avare.
Click to expand...

Are you running DNS on the NT4?
If you will put a secondary zone for the AD domain on the NT4 box it should
reduce the calls. The NT4 must be at least SP4 to do this IIRC.
You will need 53 UDP and TCP for zone transfers.
 
Actually that's normal when it comes to the response port from a client to a
server using Windows. That can be forced to 53 by using the registry on the
DNS server. Here's more info on it:

SendPort for DNS:
http://www.microsoft.com/windows200...2000/techinfo/reskit/en-us/regentry/95408.asp

Also, look at this for exactly how to do it. Look for the section on the
SendOnNonDnsPort key:
198410 - Microsoft DNS Server Registry Parameters, Part 3 of 3:
http://support.microsoft.com/?id=198410

If it doesn't work as advertised, check this and may also want to do some
packet captures:
260186 - SendPort DNS Registry Key Does Not Work as Expected:
http://support.microsoft.com/?id=260186


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
AK> After the first look at the router log we saw that the
AK> packets that start the dial up com from domain server B
AK> from diferent UDP ports from range 3000 - 5000 with a
AK> destination of server of the domain A to the [port] 53 [...]

Something, possibly the DNS server but possibly not, on the machine "B" is
sending DNS queries to the machine "A". Look at the queries with a packet
dumping tool to determine what lookups are being performed. This will allow
you to determine their probable origin, whether it is feasible to eliminate
them, and (if it is) how to do so.

AK> We tried to block trafik on the routers for the ports [...]

Analyse the problem (to find out what it actually is) _before_ trying to
implement a solution.

AK> We are olmost sure (as we can be) that we dont have software
AK> which could generate the traffic.

You are wrong. For starters: You _have a DNS server running_.
 
Back
Top