DNS and reverse lookup?

[Michael Elleby III]

I have two servers, an acting primary DNS and secondary for my domain. If I take down the secondary server named daemon, it causes remote telnet issue with clients (UNIX/PC, etc) trying to login to UNIX servers in the domain, and vice versa, If I take down the primary, it causes the same problem.

Any suggestions? The only thing I can think of is that I don't have another primary statement in my named.boot file so that the machine can do successful reverse lookups for the subnet that ALL machines are on.

[Sachin Patel]

Hi Michael,
When you shutdown named on secondary you have problem on client logging in to another unix server or another client. if this is correct then
1. Check your /etc/resolv.conf file on client
2. add both servers IP in it so it looks like this
domain mydomain.com
nameserver ip-of-master
nameserver ip-of-secondary1
nameserver ip-of-secondary2

What does it do? if first nameserver is not available then after 90sec it query second nameserver then third. Maximum three nameserver is allowed.

This should resolv your problem. If not post your output of
client1#>nslookup servername
client1#>nslookup server-ip

Sachin

[John Bolene]

Sounds like you have a cross-mix of entries in the DNS client arena. Some are looking for services on the promary, some on the secondary.

If one or the other is not available, then a timeout (which can be up to 90 seconds) will happen for the client that tries for that server first. Once the timeout is satisfied, the client should then use the other machine. The timeout is the killer.

Make sure all the clients are pointed to one machine with the other as backup. Tell them there will be a slowdown if you have to take that machine down.

[Bill Thorsteinson]

If the client is looking only at the secondary, it will
fail when you take the secondary down. The
client can be the nameserver used by the windows
clients.

If the DNS security is different between the primary
and secondary, then you may not be able to use
the primary to resolve addresses. Check the named
configuration file on each machine for acces control lists.

If you have the dig command try the command
dig yourdomain.com
to see what it lists as nameservers. There should be
at least two entries one for each of your servers.

Some DNS admins recommend a tightly secured
master with all user access via secondaries (at least 2).

[Harinath N]

Hi Michael,

If name resolution problem starts only when any one of the named services(primary/secondary) going down, then you can probably check for the similarity of the named data in both primary and secondary servers.

Ensure that as when you are modifying the DNS database in the primary server, its getting updated in secondary server and also vice versa. Its always recommended to carry out changes in the master server.

Inspite of it, if the problem continues, check for the correct /etc/resolv.conf entries in all systems as mentioned by Sachin.

Hope this will help a bit.

Regards,
N.Harinath.

[James R. Ferguson]

Michael:

I think Technical Knowledge Base document #NR0500KBRC00002433 provides what you seek:

/begin_quote/

PROBLEM
How can the timeout and retransmit default for a dns query be changed?

RESOLUTION
To change the timeout and retransmit default for a dns query:

1. Install the applicable patch:

PHCO_20098 (HP-UX 10.20 - libc:y2k:year2000:cumulative)

PHCO_20493 (HP-UX 11.0 - libc:10.20:compatibility)

Note: These patches, as with any patches, may be superseded ...

2. Edit /etc/resolv.conf by adding the retry and retrans parameters.

retrans is specified in milli-seconds. For example, to configure the system to only do two retries and to retransmit in 3 seconds, edit the file in the following manner:

domain mydomain.com
nameserver ip_of_nameserver1
nameserver ip_of_nameserver2
retry 2
retrans 3000

Note: nslookup is not a valid test to prove that these parameters make a difference with name resolution. Instead, use getip, or an application that makes calls using gethostbyname.

For example: telnet, ftp, or ping.

/end_quote/

...JRF...

[Michael Elleby III]

Okay guys, here's the deal, I was able to 'recreate my dns environment' on 2 development servers. Basically, whether the DNS client is on the same subnet or not, if either server (primary or secondary) has it's named daemon killed, it causes the timing issue with telnet, eventually, I get to login. rlogin will not work, and I guess that's because the client that I am using is not 'trusted'.

So as it stands, if I take down either dns server, it causes the telnet hang and disallow of rlogin.

Any suggestions?

[Kevin Wright]

That really cannot be if your /etc/resolv.conf is configured like the above posters have said.
Try to telnet with primary first in resolv.conf, and secondary second..then kill named on the secondary server..this will NOT affect the telnet request.
then to test, kill named on primary, restart named on secondary..this is where your retry retrans variables come into play..as was stated..your telnet could have a 90second delay..
If you still are experiences telnet problems when ONLY the second server listed in resolv.conf's named process is killed..I would like to know what version of Bind you are using.

[Karen Elrod]

We had a similar problem. Check to see if the domain has been added to the in-addr-arpa record on each dns server.

[Ansett Australia Unix]

Michael.

There are so many points of issue here.
The telentd, by default, on HP will try to resolve the IP of the connecting PC. If it can't it will eventually time out and continue to connect the PC. If there are several issues to resolving names on the server a telnet client may time out on the PC.
If the PC's resolv.conf has too many failures ontop of some time outs on the server they will combine to time out the telnet client.
I would suggest a primary DNS server that only secondaries connect to. At least two, pref three, secondaries that all computers use, including the primary dns server. Reverse lookups for all computers or stopping the telnetd from trying to resolve IP's to names should help.
If you could pass on your named.boot and resolv.conf of server and PC's it would help.

[Michael Elleby III]

Kevin-

Killing named on primary or secondary affected the telnet request and the rlogin request.

Version of Bind is 4.9.7

Here is the named.boot info:

named.boot on the primary:

;
; type domain source file
;


directory /usr/local/dns ; running directory for named

primary 0.0.127.IN-ADDR.ARPA db.127.0.0
primary bcs.bls.com db.bcs
primary 48.73.90.IN-ADDR.ARPA db.90.73.48
cache . db.cache


named.boot on the secondary:

;
; type domain source file
;


directory /etc ; running directory for named

primary 0.0.127.IN-ADDR.ARPA db.127.0.0
secondary bcs.bls.com db.bcs
secondary 48.73.90.IN-ADDR.ARPA db.90.73.48
cache . db.cache

[Sachin Patel · Accepted solution]

Hi Michael,
First in your secondary I will suggest you will change directory from /etc to /etc/domain or anything you want but in separate directory
.
Second in your named.boot on secondary server

; type domain source host backup file
secondary bcs.bls.com ip-of-primary db.bcs
secondary 48.73.90.IN-ADDR.ARPA ip-of-primary db.90.73.48

Killing named on anyof the server will not affect telnet or rlogin. But better way is to use
#sig_named restart (this will reread the dns map)

Sachin

[Michael Elleby III]

Hello Sachin-

Apparently, when I placed the IP address of the primary back in the named.boot file of the secondary dns server, this seemed to make things work.

It's funny, because I had this info in this file previously, and had taken it out.

What may have had something to do with it is the patch I installed on both dns servers (PHNE_23274) as recommended by HP, since I had opened a call on this problem.

But regardless, thanx for all of your help.. Now I have to determine which item was the actual fix.. The patch or the 'putting back' of the entries in the named.boot file on the secondary.

Mike-

[Sachin Patel]

Hi Michael,
May be both. when you had entry in you named.boot you didn't had patch. And when you add patch, you didn't had entry in named.boot.

But I am glad that it is working.

Sachin