The Answer Guy
More "Can't Telnet Around My LAN" ProblemsFrom Bobby Mathew on Thu, 22 Jul 1999
I have a lan of 20 machines with one NT server and remaining Win95 clients and today I just added my LINUX Server. After Installation of the RedHat 5.2 LINUX I have trouble telnetting to the machine from any other machine on the lan. I am able to ping the ip address of the LINUX server from the nodes and visa versa but not able to ping its name. When I try telnet from the Win95 clients by specifying the ip it says connected but nothing appears...no username..no password nothing...... I am a newbie to LINUX and so it is kind of frustrating experience not knowing what to do. Please can you help ?
bob
It sounds like you don't have reasonable DNS or other name services properly configured.
Being unable to ping a machine by its name requires that the client (the running running the ping command) be able to translate that name into an IP address (called "resolving" in the vernacular). This is usually done via the DNS system (using the named program from the BIND --- Berkeley Internet Naming Daemon --- package).
If you can do normal web browsing of Internet web pages, ping Internet hosts by name etc --- then you do have the resolvers on your Win '95 and NT systems configured reasonably for that purpose.
When you try to telnet to the Linux box by its IP address then your client is able to establish the connection. However a standard Linux distribution such as Red Hat will have a utility called "TCP Wrappers" (tcpd) installed and configured to protect your system from some relatively common forms of attack.
tcpd will attempt to perform a "Double reverse lookup" to match the source IP address of any telnet, rlogin, rsh or similar (inetd launched, or "dynamic" TCP service) to a fully qualified domain/host name (FQDN) and back. First it performs a reverse lookup.
Let's say the connection is coming from 123.45.6.78 --- tcpd will look that up in the reverse DNS system (actually looking up 78.6.45.123.in-addr.arpa for crufty historical reasons). If it got a reply from that (this IP address example is obviously for pedogogical use --- it doesn't seem to actually be in use on the Internet) it will do a forward lookup on the alleged name.
Let's say that the hostmaster of 123.45.6.* configured his copy of named to return the name "mybad.mit.edu" for his ...78 address. It would be naive to assume that this was actually an MIT address from that piece of info. All we know is that some claims that this is an MIT address. That response probably came from a caching server, which probably got it from an authoritative server for the 123.45.6.* or 123.46.*.* or 123.*.*.* PTR zone, which probably was uncompromised and probably was under the control of the proper hostmaster for that zone. This doesn't imply that the any 123.*.*.* addresses were ever delegated to MIT.
So tcpd now does a forward lookup asking for any IP addresses that are assigned to mybad.mit.edu. That response will probably be legitimate (subject to the same issues as the reverse lookup). It should contain a list of all IP addresses that are assigned to that hostname. Note that there is no one-to-one correspondence between FQDN/host names and IP addresses. Any host can have multiple interfaces each with its own IP addresses. A host can also have a different name for each of it's interfaces and it can have multiple IP addresses on any interface (a technique called IP aliasing, which used to be used extensively for web server "virtual hosting" before the widespread support for HTTP 1.1 virtual hosting).
So, if tcpd finds the original IP address of the connecting client among the list of addresses returned by the reverse lookup then it logs the name and processes the connection according to the access rules listed in the /etc/hosts.allow and /etc/hosts.deny. Those two files allow you to accept, deny, or specially handle requests according to where they are (or seem to be) coming from, which service they are requesting and which interface/IP alias they are accessing.
I've described this "double reverse lookup" process before (although not usually in such detail).
The key point for you is that this can cause a very long delay when you are trying access a Linux box via telnet and most any other service that's listed in the /etc/inetd.conf file.
This delay will also affect NFS mounts off of a Linux server because the most command portmapper on Linux systems is apparently derived from one written by Wietse Venema (the author of TCP Wrappers) and is linked with the libwrap --- a programming library which implements the same checks and access control semantics as tcpd.
So, the problem is that you don't have name services correctly configured for your LAN. Even if you properly configured your forward (name to IP address) mapping, you'd have this problem if you didn't ensure that the reverse mappings were consistent with them.
If you waited for several minutes you'd probably find that the telnet would work. Once you logged it, everything would work at normal speeds. This only affects the behaviour on initial connections. The fact that ping works as you expect suggests that your addressing and routing is fine. The Linux kernel handles ping (and other ICMP) directly --- so tcpd doesn't protect you for (nor otherwise interfere with) these packets.
The web server, mail daemon (sendmail, smtpd), and named (DNS/BIND) processes on your Linux systems generally are not dynamically launched. They usually are not linked with libwrap either. Therefore they are some common services which are usually unaffected by this problem.
The question then becomes: "How do you provide name services for your LAN?"
One way would be to use static files. On UNIX and Linux systems you can add entries to your /etc/hosts files on each system. This would contain entries like:
127.0.0.1 localhost localhost.localdomain 192.168.2.192 win1.example.org win1 192.168.2.193 win2.example.org win2 192.168.2.194 wnt1.example.org wnt1
I've heard that there's a HOSTS file facility that can be enabled in Win '9x (presumably through a registry entry). I don't know where the file would be located and I can't guarantee that is uses the same syntax as a UNIX hosts file. It would be similar to their LMHOSTS files (which are for old IBM LAN Manager implementations of their SMB file sharing protocol).
If you put the IP addresses and names (any names) of your client systems into the /etc/hosts file on your Linux box it will immediately solve the reverse DNS problems.
Actually this assumes that your /etc/nsswitch.conf is properly configured. That should look a bit like:
# /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # # nisplus or nis+ Use NIS+ (NIS version 3) # nis or yp Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # [NOTFOUND=return] Stop searching if not found so far # passwd: files [NOTFOUND=return] nisplus nis shadow: files [NOTFOUND=return] nisplus nis group: files [NOTFOUND=return] nisplus nis hosts: files dns [NOTFOUND=return] nisplus nis services: files [NOTFOUND=return] nisplus networks: files [NOTFOUND=return] nisplus protocols: files [NOTFOUND=return] nisplus rpc: files [NOTFOUND=return] nisplus ethers: files [NOTFOUND=return] nisplus netmasks: files [NOTFOUND=return] nisplus bootparams: files [NOTFOUND=return] nisplus netgroup: nisplus publickey: nisplus automount: files [NOTFOUND=return] nisplus aliases: db files [NOTFOUND=return] nisplus
Since you're using Red Hat 5.2 or later you should have one of these files (though their default settings are wrong for most sites --- files should generally be preferred over DNS or any other source; if you bothered to edit a name into a file the system should respect that).
The settings I've shown here insert an optional action to stop trying to resolve most of these mappings without bothering to try NIS and NIS+ (since I don't use those in my domain).
I realize you may be a bit confused at this point (I'm rambling again). Basically all this NSS stuff has to do with how a modern Linux system's "resolver" works.
The resolution of names into IP addresses, services, and even account and group names into UIDs and GIDs (the numeric objects which the kernel and filesystems use to manage ownership and permissions) are all done through libraries (think DLLs since you're from an MS Windows background).
There are various mechanisms for performing these mappings. Originally it was all done through simple text files. Thus the host name to IP address mapping was done by searching the /etc/hosts files, and the user accounts were found in the /etc/passwd file, and the groups were in the /etc/group, etc. Under UNIX and Linux these files are still respected and very widely used (especially for users and groups).
DNS was added to provide a host name to IP address service that was scalable to the needs of the Internet. This also provided for some facilities that were not possible in the /etc/hosts file (like MX records which specify alternative locations to forward mail for a system that doesn't have its own smtpd running).
Then Sun introduced its "Yellow Pages" (YP) service for distributing user, group, host and other sorts of information over a network. Apparently British Telecom prevailed in some legal wrangling, forcing Sun to officially rename YP to NIS (Network Information System). This is vaguely analogous to Novell's NDS (Netware Directory Services), LDAP (lightweight directory acces protocol) and to the "Active Directory" vaporware that Microsoft is promising to deliver in NT 5.x ... err ... Windows 2000 ... err ... Windows "Consumer" or whenever.
(Later Sun implemented a more advanced version of the NIS protocols called NIS+).
MIT developed and used (uses?) a naming/directory service called "Hesiod" (as part of their Athena project if I understood it correctly). This is essentially a way of distributing lines from /etc/passwd and /etc/group through DNS using a particular type of record. It's the most obscure and rare of the existing naming services that I'll mention.
In the bad old days the sysadmin had no control over what order the various naming and directory services were queried. The big commercial versions of UNIX provide a "Names Services Switch" configuration file named /etc/nsswitch.conf. (I think that would have been introduced in Solaris 2.x by Sun and emulated by HP-UX, AIX and others shortly thereafter).
In older versions of Linux (those relying on libc version 5.x) there were different versions of the libraries with and without support for files, DNS, NIS and NIS+. The version of libc that supported NIS was often referred to as the "NYS libc." You could use the /etc/hosts.conf file to give you limited control over the resolving process.
With the adoption of GNU glibc version 2.x (which is Linux libc version 6.x) Linux distributions gained support for /etc/nsswitch.conf and a fully modular NSS infrastructure. files, db, DNS, and NIS support is provided with most distributions. NIS+, LDAP, Hesiod, NDS and even custom and as yet undeveloped naming services can be plugged in and supported without recompiling any of the software that ships with a typical Linux system.
Through the magic of dynamic linking this modular NSS will also be supported by all programs that conform to the standard glibc APIs for their name services request.
In all of these cases the DNS resolver further relies on an /etc/resolv.conf (NOTE: no 'e' on the end of that!). That's where the resolver libraries find pointer to "nearby" name servers. (Actually the libraries and code don't care if your name servers are "nearby" or not. However, your sysadmin and others might be understandably irritated if you configure you system to send packets to Bangladesh for every name lookup that it performs).
That finally brings us back to your situation. You can use just files through your network. With only 20 or 30 hosts that generally isn't too cumbersome. It's a bit of a hassle to add new hosts or change them around (you have make sure that all of the files get changed). That's the whole reason all these other naming services were developed.
You can also configure your own DNS service for your network.
This gets to be a much more complex discussion.
Let's say that you have an Internet domain registered with the InterNIC. That requires that you register primary and secondary nameservers with them. These days many smaller domains (such as yours) are served by their ISPs nameservers. ISPs that provide name services generally should have co-operative agreements with other ISPs or Internet sites so that each provides secondary services for the others.
This is all managed automatically by the BIND software --- once it's properly configured then it will automatically synchronize secondaries to primaries (using zone transfers).
It is also common for network administrators to run "caching" nameservers. These aren't configured as primary or secondary authorites for any domain. However they can have DNS requests directed to them and they will respond from their cache if they have recieved an authoritative answer recently enough. The DNS protocols include plenty of information regarding the acceptable caching periods for any given record. So they can be configured by the hostmasters of each domain.
BIND nameservers can be used for caching, and they can concurrently be primary to some domains, secondary to others.
So, why don't you just give a list of your machines to your ISP and one of their admins put all their names and IP addresses into your zones for you?
If you are a typical small site on the Internet these days you don't use IANA assigned addresses for all of your system. You might have a dedicated connection to the Internet. Perhaps you have an ISN line or even a modem that's configured for dial-on-demand. Your ISP has probably only devoted a few IP addresses to you. If you have a publiclly accessible web site it might be "virtual hosted" at your ISPs site on one of their servers. The same might be true of your FTP server and your e-mail might be served to you through some POP mailbox hack.
Most of your system are probably using RFC1918 "Private Network" IP addresses (10.*.*.*, 172.16.*.* through 172.31.*.*, or 192.168.*.*) and be accessing the Internet through IP masquerading (as provided by the Linux kernel or most modern routers) or through applications proxies (such as SOCKS).
In these cases you cannot publish those host names and their IP addresses through your public DNS records.
Even if you do have "real IP addresses" (which I refer to as DRIPs --- directly routable IP addresses) you might not want to publish them. You really only need to publish the names and addresses of those systems which interact directly with the Internet (public web servers, mail exchange hubs, routers, proxy hosts, etc).
You want your LAN nodes to "see" one set of names and addresses in addition to allowing them to see the Internet name space. As your network gets larger you don't want to have to manually synchronize alll those hosts files (and you might not want to even hack up Win '95 to force it to work with them in the first place).
So, what do you do?
This is where you configure your system to use "split DNS."
Basically you point your client systems to a nameserver that you set up (on your Linux system would be the natural choice). This is their primary nameserver. It is configured to be authoritative to your domain but it is NOT registered as an authoritative name server with the InterNIC. In other words your domain services have a "split" personality.
Your internal systems look to one system for all name requests while the outside world looks to some other server (probably one maintained by your ISP or one of your ISP's secondaries).
This sounds much more complicated in discussion than it turns out to be in practice. If you maintain a "flat" domain namespace (you don't create named subdomains within your organization) then running "split DNS" is fairly easy.
If you delegate subdomain zones to their own servers (departmental or regional, for example) then you'll have an added complication. Typically you'd have to ensure that each of internal authoritative name servers is a secondary for each of the "other" subdomains.
In other words, let's you're running the foo.not domain. You decide to create subdomains for finance, engineering, and IS and call them: fin.foo.not, eng.foo.not, and is.foo.not. You can just maintain a set of zone files for all of these on the same primary (internal) server. However, you might want to delegate these zone --- give the sysadmin/hostmaster of the engineering group his/her own internal DNS server. In order for split DNS to work, and for the fin.foo.not and is.foo.not DNS servers to find hosts in the eng.foo.not subdomain --- the name servers for fin. and is. must be configured as secondaries to eng.
You can read more about why this is the case at:
- Creating a split DNS environment
- http://www.acmebw.com/askmrdns/00408.htm
However, it is relatively rare to have this problem. You probably are only running a small organization, and maintaining all of your domain in a single zone delegation is probably feasible. In that case here's what you can do:
You can easily run a copy of named on your Linux box. It's included with all major Linux distributions. (Just install the BIND package from your Red Hat CD).
Red Hat 5.2 and later ship with BIND 8.x (there was a major change in the configuration file format between BIND 4.9x and 8.x --- as well as jump in the version numbering).
Once you've installed BIND all you have to do is to prepare a configuration file and a set of zone files for you forward and (especially) reverse zones.
Here's an example of a configuration file (similar to the one I use for my domain):
options {
directory "/var/named";
dump-file "/var/tmp/named_dump.db";
pid-file "/var/run/named.pid";
statistics-file "/var/tmp/named.stats";
memstatistics-file "/var/tmp/named.memstats";
check-names master warn;
datasize 20M;
forwarders { 209.157.85.7; 209.157.85.2; 123.45.6.7;};
};
zone "." {
type hint;
file "named.root";
};
zone "localhost" {
type master;
file "master/localhost";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "master/127.0.0";
allow-update { none; };
allow-transfer { any; };
};
acl "internal" {
{ 192.168.64.0/24; };
};
zone "starshine.org" {
type master;
file "master/starshine.org";
check-names fail;
allow-update { none; };
allow-transfer { any; }; // just allow the secondaries
allow-query { any; };
zone "64.168.192.in-addr.arpa" {
type master;
file "master/192.168.64";
allow-update { none; };
allow-transfer { internal; localnets; localhost; };
};
This configuration file refers to the starshine.org and 192.168.64 files in the "master/" directory. There are also localhost and 127.0.0 files under the master/ directory. Here are copies of those two:
master/localhost:
$ORIGIN localhost.
@ IN SOA @ root.localhost. (
2 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS @
IN A 127.0.0.1
master/127.0.0:
$ORIGIN 0.0.127.in-addr.arpa.
@ IN SOA localhost. root.localhost. (
2 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS localhost.
1 IN PTR localhost.
Those two should be the same for every DNS server. (I won't get into the history surrounding this --- just take it as a quirk).
Here's a set of sample zone file excerpts from my domain:
master/starshine.org
@ IN SOA ns1.starshine.org. hostmaster.starshine.org. (
1999071603 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
1W ; expire, seconds
1D ) ; minimum, seconds
IN NS ns1.starshine.org.
IN NS ns2.idiom.com.
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
IN MX 30 www.starshine.org.
IN MX 90 mx.myisp.net.
IN TXT "Starshine Technical Services"
IN A 209.157.85.7
flowpoint IN CNAME gw.starshine.org.
gw IN A 209.157.85.1
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
pulsar IN A 209.157.85.2
ntp IN CNAME ntp.starshine.org.
mx IN A 209.157.85.7
mail IN A 209.157.85.17
www IN A 209.157.85.7
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
ftp IN A 192.168.64.3
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
staging IN A 192.168.64.4
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
lasfs IN A 192.168.64.5
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
antares IN A 192.168.64.11
IN MX 20 mx.starshine.org.
ant IN CNAME antares.starshine.org.
betelgeuse IN A 192.168.64.12
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
bet IN CNAME betelgeuse.starshine.org.
canopus IN A 192.168.64.13
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
can IN CNAME canopus.starshine.org.
venus IN A 192.168.64.14
IN MX 10 antares.in.starshine.org.
IN MX 20 mx.starshine.org.
startop IN CNAME venus.starshine.org.
quit IN CNAME use-exit-to-quit-nslookup.
master/192.168.64
$ORIGIN 64.168.192.in-addr.arpa. @ IN SOA 64.168.192.in-addr.arpa. hostmaster.starshine.org. ( 4 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum @ IN NS ns1.starshine.org. @ IN NS ns1.idiom.com. 1 IN PTR antares.starshine.org. 2 IN PTR betelgeuse.starshine.org. 3 IN PTR canopus.starshine.org. 4 IN PTR deneb.starshine.org. 5 IN PTR eridani.starshine.org. 6 IN PTR fomalhaut.starshine.org. 18 IN PTR rigel.starshine.org. 19 IN PTR spica.starshine.org. 22 IN PTR vega.starshine.org. 33 IN PTR andromeda.starshine.org. 97 IN PTR mercury.starshine.org. 98 IN PTR venus.starshine.org. 99 IN PTR earth.starshine.org. 100 IN PTR mars.starshine.org. 101 IN PTR jupiter.starshine.org. 102 IN PTR saturn.starshine.org. 103 IN PTR neptune.starshine.org. 104 IN PTR uranus.starshine.org. 105 IN PTR pluto.starshine.org. 106 IN PTR luna.starshine.org. 107 IN PTR deimos.starshine.org. 108 IN PTR phobos.starshine.org. 109 IN PTR titan.starshine.org. 110 IN PTR europa.starshine.org. 111 IN PTR io.starshine.org. 112 IN PTR ceres.starshine.org.
... etc.
So you could take these as samples (though you'll have to edit in various values). Every hostmaster I know uses a set of templates for all of their files. Occasionally someone needs to build one "from scratch" but most of us maintain our zones in "monkey-mode" (as in "monkey see; monkey do!).
For more information you could read the "cricket book" whole book on DNS/BIND (*)
- (DNS and BIND, 3rd Edition http://www.oreilly.com/catalog/dns3/noframes.html)
You can also can peruse the DNS Resources Directory (http://www.dns.net/dnsrd) web site, and you could visit the Internet Software Consortium at: http://www.isc.org. ISC is headed up by Paul Vixie, who has been the principle programmer and maintainer of BIND for about 20 years.
Hope that helps. Sorry such a simple question leads to such a long answer. I've been meaning to write up something on split DNS for awhile.
Incidentally the examples I showed were for the internal systems. The publicly accessible servers and any hosts with "real" IP addresses would have entries in a different set of zone files which would be stored on a publicly access DNS server. Keeping the two sets of zone files relatively in sync is one of the principle disadvantages of split DNS. There are systems out there that generate zone (and reverse zone) files from simple text tables and/or as reports from a database. I don't know of any that specifically support zone "splitting" (though it would be a simple feature to add).
In my case I'd only have about three or four entries in my public DNS and I don't maintain a reverse DNS zone for it directly (my ISP offers a web form (CGI) driven means to allow me to submit changes to my reverse names to his zone. That is a complex issue that I won't cover this time around.
ThanksFrom Bobby Mathew on Fri, 23 Jul 1999
Dear Jim,
I am so really impressed by your explanation of my problem. I am also grateful for your initiative to help out. I had given up on the problem after recieving no response for so long. But your email has encouraged me to venture into LINUX a little more deeply. I am a novice to LINUX and so very hesitant to venture far. Thanks a lot for your detailed explanation. Though I must admit that most of it went over me but neverthless your email has certainly inspired and enlightened me to go back to see if I can correct the problem.
Thanks a ton for sharing your expertise and your time. I will try it out and get back to you.....
God Bless you
bobby
![[ Answer Guy Index ]](../../gx/dennis/answernew.gif) |
1 | 2 | 3 | 4 | |
| 5 | 6 | 7 | 8 | ||
| 9 | 10 | 11 | 12 | 13 | |
![[ Table Of Contents ]](../../gx/indexnew.gif)
![[ Front Page ]](../../gx/homenew.gif)
![[ Previous Section ]](../../gx/back2.gif)
![[ Next Section ]](../../gx/fwd.gif)