Unable to telnet to port 53

[Karthik S S]

I have a HP-UX server and Windows 2003 AD server which are inside a firwall (PIX). Win2K3 is running DNS. From HP-UX if I use the Windows server as DNS server and do a nslookup for any host record, nslookup doesn't respond. But I am able to ping/telnet/ftp to the windows server. If I telnet to port 53 of the Windows server it keeps on trying but doesn't establish the connection. Other machines are able to telnet to the port 53 of the windows server. I checked the acl entries and learnt that tcp/udp are enabled for port 53. What could be the problem?

Pl. help.

Thanks,
Karthik S S

[Mark Grant]

Karthik,

It sounds terribly firewall like to me. Have you checked the firewall rules?

[Hoefnix]

Karthik,

Are the other servers/systems that work in the same network segment?
Both servers are inside the firewall you mention?

Still strange, are all the other server which you test using telnet 53 MS-systems or also UNIX systems?

I tested on our systems, A HP-UX systems gets a connect on port 53(using telnet) to a UNIX DNS server (for what its worth)


Regards,
Peter

[Karthik S S]

Mark,

Output of "show access-list"

access-list acl_out permit tcp any any eq ssh (hitcnt=0)
access-list acl_out deny ip any any (hitcnt=55770)
access-list acl_out permit tcp any any eq domain (hitcnt=0)
access-list acl_out permit udp any any eq domain (hitcnt=0)
my-fw(config)#

Pl. note that Windows server is on a different subnet than the unix box. HP-UX box has multiple interfaces one of them is configured in the subnet of the windows servers. I can telnet to port 53 of other DNS servers (hp-ux DNS, same subnet).

-Karthik S S

[Karthik S S]

Also when I telnet to port 53 of MS server I do not get any error messages logged in the syslog of the PIX firewall.

-Karthik S S

[Karthik S S]

These servers belong to different group in our company and I am not sure if some software based firewall is configuerd in addition to the PIX firewall (like ipchains). Since I am not doubting the PIX configuration which are the other areas I can look into?

-Karthik S S

[Hoefnix]

Karthik,

Did you try a traceroute to port 53?

traceroute -p 53

That might figure out if its a routing issue.

HTH,
Peter

[Mark Grant]

The fact that telnet doesn't even reach the server but other services do must be a firewall issue somewhere en route. "traceroute" would at least allow you to see where that firewall might be. Can you telnet from the windows server to the unix box?

[Jim Keeble]

You might also have a simple problem in the routing table for the HP host. Also, if the gateway for the particular route that leads to the DNS server does not respond to ping (ICMP Echo Request) by design for security reasons, you could be running into the "dead gateway detection" feature in HP-UX. If you are not permitted to ping the router, disable the feature with "ndd -set /dev/ip ip_ire_gw_probe 0". You do have to delete and re-add the route afterward to wake up the route again.

[Geoff Wild]

What's the output of:

netstat -an | grep 53

Oops - sorry - forgot MS :)

netstat -an

Something is blocking 53 somewhere to that server - On the Windows server - is there a level of security set that limits access to a certain group of servers? Similiar to allow_update in BIND?

From windowssecurity.com:

Knowing how to control zone transfers is tremendously significant while securing DNS servers in a Windows environment. Windows 2000 allows for the alteration of the access lists available for each individual zone controls and zone transfer. Zone transfers are responsible for the movement of all the records for a particular zone from a respective server to the other and it is particularly to note that the forward lookup zone should not be transferred to a DNS server that contains Windows 2000 domain information to any server outside the Windows 2000 domain. This can be done in the Zone transfer tab of the properties of the specific domain name in the DNS MMC.

If you like you can specify a list of IP address to witch you can allow zone transfers to. This option allows for granular control of zone transfers through a list of IP addresses and only IP addresses that are reflected on the list will be authorized candidates for possible zone transfers. This option increases DNS zone transfer security significantly and it is recommended practice that this option is used where possible as it reduces the chance of an unauthorized zone transfer. This option is activate in the Zone Transfer tab of the properties of the domain name in the DNS MMC. If you would like to enable the no zone transfer mode it is advisable if you are sure that your zones will not b transferred. This setting is extremely secure and does not pose a treat as there is no opportunity for the possibility of an impersonation or spoof of a clone zone transfer sever. This strategy is recommended for organizations like banks and military operations where a zone transfer can have catastrophic consequences.

When setting up your Router and Firewall Settings you can ensure that only specific IP addresses can query your DNS servers like your ISP DNS servers or a branch office that is connected via the internet. DNS traffic is transmitted on UDP and TCP port 53. This requires the firewall and router to have these ports open allowing clients and other servers to make use of DNS.

All client queries are transmitted on UDP port 53 and TCP port 53 is used for zone transfers. Traditionally zone transfers outside of the protected Network so TCP port 53 should be avoided. Zone transfer port namely TCP port 53 should be blocked at the Internal, External, Firewall, and DMZ routers. If the DNS is configured to allow reverse lookup zone transfers between the Internal and External DNS servers the Internal Router, Firewall, and DMZ router should allow connections on TCP port 53 between the Internal and External DNS only.

Securing the location of zone information that a DNS server uses is vital when ensuring organizations wellbeing on the internet it is recommended that the DNS server be converted to active directory integrated zone the advantages of this zone type offers are great and include the zone information being stored, replicated, and secured in the Active Directory.

If this feature is used an â Only secure updatesâ option is enabled for Dynamic Updates.

This option is recommended when allowing dynamic updates, which is a necessary feature for a Windows 2000 domain. Ensure that only the system and administrators have full control of the %SystemDirectory%\DNS directory and subfolders and that the all DNS servers have the registry secured. Secure the DNS servers registry by ensuring that HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\DNS is assigned to administrators and system to have full control.

Rgds..G

[Ralph Grothe]

Karthik,

as a far better tool for testing connections, and moving data (protocol etc.) than telnet I would use netcat.
It doesn't modify the data at all, and isn't susceptible to control sequences or timeouts like your telnet client.
You can get it from http://netcat.sourceforge.net/

You may also would like to test your firewalls with the notorious nmap tool.
http://www.insecure.org/nmap/

[Karthik S S]

I apologize for the late reply. Yesterday it was holiday for us :-) ...

Since the HP-UX box has multiple interfaces traecroute did not even try to reach the subnet where the Windows m/c is configured.

I also tried with the following syntax,

traceroute -s x.x.x.x y.y.y.y
traceroute -p 53 -s x.x.x.x y.y.y.y
traceroute -g x.x.x.x y.y.y.y

where x.x.x.x is the hp-ux interface that is configured in the subnet of the windows server. y.y.y.y is the IP of the windows box.

However I am able to ping/telnet to the windows host from hp-ux

Also from other windows and hp-ux boxes I am able to do a traceroute to port 53 to this windows DNS server.

Thanks,
Karthik S S

[Hoefnix]

Karthik,
You mentioned:
"Since the HP-UX box has multiple interfaces traecroute did not even try to reach the subnet where the Windows m/c is configured."

This is strange, did you try to force it with a route add command to force traffic over this interface and then run the traceroute again.

Can it be that there are multiple routes to this windows(DNS) machine and that you can telnet/ping over one route but this route does not let through your lookup request?

HTH,
Peter

[Karthik S S]

Peter,

Thanks for your reply ..

There already a route is configured for that particular subnet and that is the only available route to that subnet. ( I can see that from netstat -nr )

-Karthik S S

[Fred Ruffet]

Don't use traceroute, but ping -o. With multiple interface, traceroute can have problems because he always uses the same interface. ping -o gives info from returning ICMP, which is better ni this case.

[Hoefnix]

Karthik,

I do not know if it's a production system, but to test if you can do an nslookup from this HP system to the Windows DNS, try to disable the other NIC's so that the system only uses the NIC thats on the same subnet as the Windows DNS system. That way you exclude routing problems.

HTH,
Peter

[Karthik S S]

Hi Peter,

But it is a production system :-( .. I am just waiting for the planned down time ..

-Karthik S S

[Mark Grant]

Personally, I can't see how it can be a routing problem if all other services get through fine. If telnetting to the IP address on port 53 doesn't work either, that pretty much leaves you with something dropping connections to that port.