Problems with DSN client

[Daniel Sanabria]

running hp-ux 11.11 the rp3440 platform that is acting as a dns client is not able to connect to one of the domains.

Debugging a tcpdump capture I noticed the following behaviour:

-1 The client submit a Standard DNS query looking for a particular domain. This query is directed to the IP address of the nameserver declared on /etc/hosts with Transaction ID 0x07f0, Src port 51687 & Dst port 53.
- 2 Exactly a second later the client submit the same query with the same Transaction ID but Src port is 51689. At this point I haven’t received any responses back from the DNS server
- 3 Three seconds later a query response is send from the dns server with Transaction 0x07f0, Src port 53 & Dst port 51687.
- 4 the client receives the response from the server and submit an ICMP Destination Unreachable (Port Unreachable) pdu for that particular response (the dns response bytes are embeeded)

What’s going on here? I’m suspect that the client is closing the socket too quick and is not waiting for the response, when the response arrives is too late. What can I do to workaround this problem?

Below the resolv.conf and nsswitch.conf files in the client.

# cat /etc/resolv.conf
domain mars.pluton.com
nameserver 10.162.47.52
nameserver 10.162.47.53
retrans 500
retry 2

# cat /etc/nsswitch.conf
hosts: files [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] dns [NOTFOUND=return UNAVAIL=return]

[Todd Whitcher]

You have the retrans set to 500, which is in milliseconds so .5 seconds and retrans set to 2 so you send one query, .5 seconds later you send another one..and do this twice.

This is probably the issue, try removing it or setting it higher.

The default is 5000 milliseconds/5 seconds.

See the man page for resolv.conf for details.

Todd

[Daniel Sanabria]

I commented the retrans and retry entries but I'm still getting the exact same result ... the client tries a new query 1 second after the first one ...

[Steven E. Protter]

Shalom,

retrans 500
retry 2

I have never used these parameters, the defaults were always good enough.

Suggestions:
Try reversing the order of the nameservers.

See if these two clients respond to pings and check response with the nslookup command.

SEP

[Todd Whitcher]

Strange, the default is 5 seconds not 1 second. You may need to stop/start your application since it may have cached the resolver information.

Can you test w/ another application, try to capture a tcpdump of a inbound telnet, telnet will query dns for the remote host's IP/Name.

[Daniel Sanabria]

I deleted the retrans entry (I guess the default is in use) and reduce retry from 2 to 1 and now the DNS response is arriving in time and is accepted by the client.

However another problem appears after this change ... when starting a telnet session to the client host it takes too long for the login prompt to be presented in my terminal.

[Todd Whitcher]

Thats a typical telnet/login issue. The hang is probably ~ 60 seconds. Whats happening is that the telnet server "telnetd" is trying to do a reverse lookup on the remote telnet client via DNS. Its failing, after it fails telnetd will present the login prompt. The fix is to make sure that DNS has the reverse record for your telnet client.

You can test with the nsquery command.

# nsquery hosts hostname_of_telnet_client

# nsquery hosts ip_of_telnet_client

The telnetd daemons uses this info to populate the wtmp files, you cant disable this feature you have to fix DNS.

[Daniel Sanabria]

Thanks Todd ... but from where should I run the nsquery commands? from the host I telneting to?

[perumal_2]

Hi
I may need some more inputs to understand.
Have your checked the below.
#nslookup
Default Name Server:xxxxx.xxxxxxx.com
Address: xx.xxx.xx.xx
>anyhostname in your network
Doest it resolve the ip address of the host?.

If you dont get the Default name server and the name servers IP address after you enter the nslookup command, you have the difficulty of reaching the DNS server. Does the DNS server what you had used in your resolv.conf is behind a firewall/switch. Were those devices explicitly block the icmp echo requests, if so you may need to tune your ndd parameter ip_ire_gw_probe to '0'.

TQ
Perumal

[Todd Whitcher]

Hi Daniel

The telnet server side is doing the reverse lookup so you test nsquery from the server you are telneting into and test for the hostnaem/ip of the telnet client you are coming in from.