telnet do not dns lookup for round robin A record

[michele_34]

Hi all,
i have a GS80 with OSF1 V5.1 732 alpha OS, that is working well.
The resolv.conf is right and in fact i resolve the name.
One stragen problem occur with a record, that is in round robin: nslookup works and report all the A records, when i try to telnet to the same host the result is no host found.
Thansk for any help...

[Abdul Rahiman]

Just curious how does your /etc/svc.conf file look ?
Is the hosts entry in the svc.cinf file has bind as an option ?
It should look like,
hosts=local,bind,yp

If bind is not there, nslookup would still work, but other netwrok utilities son't resolve the host name.

regds,
Abdul.

[michele_34]

Hi,
this is my scv.conf

hosts=bind,local,yp

Nothing happens also with local before bind...

[Ralf Puchner]

first, it is very dangerous (or is stupid a better word?) using bind as first option! In case of a network problem bind will hang a while and processes requiring dns will be stuck too.

Important is what arp, name resolution and TTL really "think". So it seems to be important to be sure your "round robin" dns setup really works and is RFC compliant (be sure you understand difference between "compliant" and "works")

It is always helpful to offer more details like hostnames, IP's, bind setup on client/server etc.....

[michele_34]

Yes, it is dangerous (not stupid).
But, going on, i know the differences beetwen it *works* and it is *compliant*.
Bind 9.1 knows it too, all the other machine on the networks seem to know this differecens.
What nobody seems to know is this: why nslookup on that machine answer correctly, and telnet or ping, not?
Listen to me, it is not possible, like sometimes happen, that the telnet client is link to an old or bugged resolver lib?
You know? it is possible, like with other unices.

Michele

[Ralf Puchner]

michele,

we try to help you, but with generic non technical answers like "it works with other" we can not goon. So please tell us the information requested in my previous posting.

And if you are in hurry open a call within the HP support center. Be sure you have installed the original "bind" version on your client and all actual patchkits.

[michele_34]

Hi,
exactly i can answer anything, but i do not see any question other than these:

>Important is what arp, name resolution and TTL >really "think". So it seems to be important to >be sure your "round robin" dns setup really >works and is RFC compliant (be sure you >understand difference between "compliant" and >"works")

yes, it is rfc-compliant:

ng_lmt A ip1
ng_lmt A ip2

Bind is 9.1 on linux on another machine.
Resolv.conf see it, for any other ip, and using nslookup i found exactly what i need.
This result doesn't come with ping or telnet.

>It is always helpful to offer more details >like hostnames, IP's, bind setup on >client/server etc.....

on tru64 there is no bind installed, hostname and other seem to be unuseful, but correct my if i'm wrong.

Michele

[Ralf Puchner]

hostnames and ip adresses are always helpful, because not all "hostnames" or IP are really correct as I can see on the given named entries (ng_lmt is not rfc compliant and it is absolut ok to drop such names/domains. guessing it is time to study some more network documentations ;-)

Btw. round robin still works since 5.0 and 4.0f in Tru64. But not RFC compliant hostnames will be blocked by modern TCP implementations - maybe the reason why your "old" environments will work.

I'm missing the arp output of the host in question (basic communication is always the mac adress and telling us if the client really tries to connect). Another approach is to monitor the network packets getting the whole picture....

have you installed any patches for the unsupported 5.1 version or it is simple out of the box?

[michele_34]

Something is not correct, pheraphs is my bad english.
Rewind: ng_lmt is the host name of a normal FQDN.
Want you to know the complete FQDN?
I do not think it is impoortanta, by the way, ng_lmt.prod.lastminutetour.com A 192.168.1.101
ng_lmt.prod.lastminutetour.com A 192.168.1.102

Here it is.
It is fully compliant, or i loose my mind.
Fer the arp, i do not unrderstand becuase you need it, but here it is:

rosso-mc0 (1.0.0.162) at 42-00-00-00-00-02 stale
zeus.prod.lastminutetour.com (192.168.1.39) at 00-01-02-05-21-72
ha1.prod.lastminutetour.com (192.168.1.40) at 00-01-02-05-21-72
saturno1.prod.lastminutetour.com (192.168.1.45) at 00-01-02-b0-6d-ee
saturno2.prod.lastminutetour.com (192.168.1.46) at 00-01-02-b0-6d-48
saturno4.prod.lastminutetour.com (192.168.1.48) at 00-01-02-56-b0-8e
serverlmt1.prod.lastminutetour.com (192.168.1.79) at 00-50-8b-62-61-57
serverlmt2.prod.lastminutetour.com (192.168.1.80) at 00-50-8b-f9-97-7a
dracula.prod.lastminutetour.com (192.168.1.101) at 08-00-20-a0-f2-62
carmilla.prod.lastminutetour.com (192.168.1.102) at 08-00-20-cb-27-07
giglio.prod.lastminutetour.com (192.168.1.150) at 08-00-20-a0-f2-62
rosso.prod.lastminutetour.com (192.168.1.162) at 02-02-a5-6b-ec-6b
adslrestelli.prod.lastminutetour.com (192.168.1.240) at 00-0a-8a-41-19-ed
epic1.prod.lastminutetour.com (192.168.1.241) at 00-00-5e-00-01-f1

Last, the OS was installed in 2001, and no other patches from that date are installed on.
I think that some libraries or the telnet (if it is linked statically) are bugged, and the answer from bind is not understood.
There are some patches for net utilities like telnet and ping ?

[Ralf Puchner]

ng_lmt is not a RFC compliant hostname and will be blocked by resolv.conf. "_" are not allowed within hostnames except for netbios names (problem leads from nt admins not knowing the difference between netbios/tcpip)

[michele_34]

Sure.
What a solution to avoid this strictly control that happens only for telnet and ping?
nslookup works right.
Exist some patches or some upgrade for telnet ?

Thanks

[Ralf Puchner]

If not using hostnames which are RFC compliant will lead to other problems with different other services (e.g. BOOTP will crash etc.) and to a unsupported configuration and machine! (important if mission critical)

So please have a look into the RFC 952 telling you what is allowed, learn the differences between netbios and TCP/IP and change the hostnames. And if you change the hostnames, change the resolv.conf using local first instead of bind because all requests must be fullfilled by the dns server also for localhost and the machine name itself - so "stupid" IS the right word) - a 30sec. timeframe in case of a network outage is the price and local login will not be possible....

nslookup asks the dns-server directly (simple query tool), but resolv.conf will block such addresses.

There is a statement "options allow_special { \_ }" for resolv.conf but this is only a workaround - be sure you understand "it is not supported to use such names" (PERIOD) and you loose support in case of a problem with your network (so if you love your job change the hostname).

Btw. MAC-addresses are the basics of communication on the network, so arp is important. Your arp table contain for .102 the name carmilla not the ng_lm so where is this name coming from? Cluster? If so I don't think your setup is really correct, because traffic will be channeled between members and round-robin is absolut useless here because round-robin will be done by cluster software automatically.

[Ralf Puchner]

in the output of arp you can see rosso-mc with IP adress 1.x.x.x!

It is not allowed to use non private regions for memory channels within a cluster! Please use 10.x.x.x instead. If using 192.168.x.x for the public net within a cluster be sure you configured the cluster properly to advertise "private networks".

If the memory channel adapter is not on the local machine there is a configuration problem on the cluster using the adapter (mc adapters adresses are not allowed outside of a cluster).

Maybe it is time to open a call within the HP support center and ask for technical assistant checking your clusters and machine for other wired configurations/issues or have a look into the documentation

So the "buggy" software you always told will be reduced to lack of knowledge and experience - maybe time to return to windows? ;-)

[michele_34]

Tru64 is not so bad, windows i do not know.
For the buggy software, i confirm, resolver that do not understand _ is buggy.

Michele

[Ralf Puchner]

In short, underscores in hostnames in the DNS are not permitted by the internet protocol standards. Systems which are RFC952 compliant will block such names. Windows, Solaris and a hand of Linuxdistributions will not follow the standard due to limited implementations. So sideeffects and problems will occure depending on the used software.

Read, learn and correct all your configurations. I don't know if your company depend on the used IT infrastructur, if not you can ignore all suggestions...