LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/LG/issue45/tag/11.html

889 lines
33 KiB
HTML
Raw Permalink Blame History

<!--startcut ======================================================= -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.2M.l">
<TITLE>The Answer Guy 45: More "Can't Telnet Around My LAN" Problems</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
LINK="#3366FF" VLINK="#A000A0">
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<center>
<H1><A NAME="answer">
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
border="0" align="middle">
<font color="#B03060">The Answer Guy</font>
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
border="0" align="middle">
</A></H1>
<BR>
<H4>By James T. Dennis,
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
LinuxCare,
<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A>
</H4>
</center>
<p><hr><p>
<!-- endcut ======================================================= -->
<!-- begin 11 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
height="50" width="60" alt="(?) " border="0"
>More "Can't Telnet Around My LAN" Problems</H3>
<p><strong>From Bobby Mathew on Thu, 22 Jul 1999
</strong></p>
<!-- ::
More "Can't Telnet Around My LAN" Problems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: -->
<P><STRONG>
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 ?
</STRONG></P>
<P><STRONG>
bob
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
It sounds like you don't have reasonable DNS or other name
services properly configured.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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
<A HREF="http://www.redhat.com/">Red Hat</A> will
have a utility called "TCP Wrappers" (<tt>tcpd</tt>) installed and
configured to protect your system from some relatively
common forms of attack.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Let's say the connection is coming from <tt>123.45.6.78</tt> --- tcpd
will look that up in the reverse DNS system (actually
looking up <tt>78.6.45.123.in-addr.arpa</tt> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Let's say that the hostmaster of <tt>123.45.6.*</tt> configured his
copy of named to return the name "<tt>mybad.mit.edu</tt>" 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 <EM>claims</EM> that this is an MIT address.
That response <EM>probably</EM> came from a caching server, which
<EM>probably</EM> got it from an authoritative server for the
<tt>123.45.6.*</tt> or <tt>123.46.*.*</tt> or <tt>123.*.*.*</tt> PTR zone, which
<EM>probably</EM> was uncompromised and <EM>probably</EM> was under the
control of the proper hostmaster for that zone. This
doesn't imply that the any <tt>123.*.*.*</tt> addresses were ever
delegated to MIT.
</BLOCKQUOTE>
<BLOCKQUOTE>
So tcpd now does a forward lookup asking for any IP addresses
that are assigned to mybad.mit.edu. That response will
<EM>probably</EM> 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <TT>/etc/hosts.allow</TT>
and <TT>/etc/hosts.deny</TT>. Those two files allow you to accept,
deny, or specially handle requests according to where they
are (or <EM>seem</EM> to be) coming from, which service they are
requesting and which interface/IP alias they are accessing.
</BLOCKQUOTE>
<BLOCKQUOTE>
I've described this "double reverse lookup" process before
(although not usually in such detail).
</BLOCKQUOTE>
<BLOCKQUOTE>
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
<TT>/etc/inetd.conf</TT> file.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
The question then becomes: "How do you provide
name services for your LAN?"
</BLOCKQUOTE>
<BLOCKQUOTE>
One way would be to use static files. On UNIX and Linux
systems you can add entries to your <TT>/etc/hosts</TT> files
on each system. This would contain entries like:
</BLOCKQUOTE>
<blockquote><pre>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
</pre></blockquote>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
If you put the IP addresses and names (any names) of your
client systems into the <TT>/etc/hosts</TT> file on your Linux
box it will immediately solve the reverse DNS problems.
</BLOCKQUOTE>
<BLOCKQUOTE>
Actually this assumes that your <TT>/etc/nsswitch.conf</TT> is
properly configured. That should look a bit like:
</BLOCKQUOTE>
<blockquote><pre># /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
</pre></blockquote>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <TT>/etc/hosts</TT> files, and the user accounts were found in
the <TT>/etc/passwd</TT> file, and the groups were in the <TT>/etc/group</TT>,
etc. Under UNIX and Linux these files are still respected
and very widely used (especially for users and groups).
</BLOCKQUOTE>
<BLOCKQUOTE>
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
<TT>/etc/hosts</TT> file (like MX records which specify alternative
locations to forward mail for a system that doesn't have
its own smtpd running).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
(Later Sun implemented a more advanced version of the NIS
protocols called NIS+).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <TT>/etc/passwd</TT> and <TT>/etc/group</TT> through
DNS using a particular type of record. It's the most
obscure and rare of the existing naming services that I'll
mention.
</BLOCKQUOTE>
<BLOCKQUOTE>
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
<TT>/etc/nsswitch.conf</TT>. (I think that would have been
introduced in Solaris 2.x by Sun and emulated by HP-UX, AIX
and others shortly thereafter).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <TT>/etc/hosts.conf</TT> file to give you
limited control over the resolving process.
</BLOCKQUOTE>
<BLOCKQUOTE>
With the adoption of GNU glibc version 2.x (which is Linux
libc version 6.x) Linux distributions gained support for
<TT>/etc/nsswitch.conf</TT> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
In all of these cases the DNS resolver further relies on an
<TT>/etc/resolv.conf</TT> (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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
You can also configure your own DNS service for your
network.
</BLOCKQUOTE>
<BLOCKQUOTE>
This gets to be a much more complex discussion.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
BIND nameservers can be used for caching, and they can
concurrently be primary to some domains, secondary to
others.
</BLOCKQUOTE>
<BLOCKQUOTE>
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?
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Most of your system are probably using RFC1918 "Private
Network" IP addresses (<tt>10.*.*.*</tt>, <tt>172.16.*.*</tt> through
<tt>172.31.*.*</tt>, or </tt>192.168.*.*</tt>) 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
In these cases you cannot publish those host names and their
IP addresses through your public DNS records.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
So, what do you do?
</BLOCKQUOTE>
<BLOCKQUOTE>
This is where you configure your system to use "split DNS."
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
You can read more about why this is the case at:
</BLOCKQUOTE>
<BLOCKQUOTE><DL><DT>
Creating a split DNS environment
<DD><A HREF="http://www.acmebw.com/askmrdns/00408.htm"
>http://www.acmebw.com/askmrdns/00408.htm</A>
</DL></BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Here's an example of a configuration file (similar to
the one I use for my domain):
</BLOCKQUOTE>
<blockquote><pre>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; };
};
</pre></blockquote>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<BLOCKQUOTE>
master/localhost:
</BLOCKQUOTE>
<blockquote><pre>$ORIGIN localhost.
@ IN SOA @ root.localhost. (
2 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS @
IN A 127.0.0.1
</pre></blockquote>
<BLOCKQUOTE>
master/127.0.0:
</BLOCKQUOTE>
<blockquote><pre>$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.
</pre></blockquote>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
Here's a set of sample zone file excerpts from
my domain:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
master/starshine.org
</BlockQuote></BLOCKQUOTE>
<blockquote><pre> @ 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.
</pre></blockquote>
<BLOCKQUOTE>
master/192.168.64
</BLOCKQUOTE>
<blockquote><pre>$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.
</pre></blockquote>
<BLOCKQUOTE>
... etc.
</BLOCKQUOTE>
<BLOCKQUOTE>
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!).
</BLOCKQUOTE>
<BLOCKQUOTE>
For more information you could read the "cricket book"
whole book on DNS/BIND (*)
</BLOCKQUOTE>
<BLOCKQUOTE><ul><li>
(DNS and BIND, 3rd Edition
<A HREF="http://www.oreilly.com/catalog/dns3/noframes.html"
>http://www.oreilly.com/catalog/dns3/noframes.html</A>)
</ul></BLOCKQUOTE>
<BLOCKQUOTE>
You can also can peruse the DNS Resources Directory
(<A HREF="http://www.dns.net/dnsrd"
>http://www.dns.net/dnsrd</A>) web site, and you could
visit the Internet Software Consortium at:
<A HREF="http://www.isc.org"
>http://www.isc.org</A>. ISC is headed up by Paul Vixie,
who has been the principle programmer and maintainer of
BIND for about 20 years.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<!-- sig -->
<!-- end 11 -->
<hr width="40%" align="center">
<!-- begin 12 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
height="50" width="60" alt="(?) " border="0"
>Thanks</H3>
<p><strong>From Bobby Mathew on Fri, 23 Jul 1999
</strong></p>
<P><STRONG>
Dear Jim,
</STRONG></P>
<P><STRONG>
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.
</STRONG></P>
<P><STRONG>
Thanks a ton for sharing your expertise and your time.
I will try it out and get back to you.....
</STRONG></P>
<P><STRONG>
God Bless you
<BR>bobby
</STRONG></P>
<!-- end 12 -->
<!--startcut ======================================================= -->
<P> <hr> <P>
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
>Copyright &copy;</a> 1999, James T. Dennis
<BR>Published in <I>The Linux Gazette</I> Issue 45 September 1999</H5>
<H6 ALIGN="center">HTML transformation by
<A HREF="mailto:star@starshine.org">Heather Stern</a> of
Starshine Technical Services,
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
</H6>
<P> <hr> <P>
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
<TABLE WIDTH="98%"><TR VALIGN="center" ALIGN="center">
<TD ROWSPAN="2" COLSPAN="2" WIDTH="42%"><A
HREF="../lg_answer45.html"
><IMG SRC="../../gx/dennis/answernew.gif"
ALT="[ Answer Guy Index ]"></A></td>
<TD WIDTH="14%"><A HREF="1.html">1</A></TD>
<TD WIDTH="14%"><A HREF="2.html">2</A></TD>
<TD WIDTH="14%"><A HREF="3.html">3</A></TD>
<TD WIDTH="14%"><A HREF="4.html">4</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="14%"><A HREF="5.html">5</A></TD>
<TD WIDTH="14%"><A HREF="6.html">6</A></TD>
<TD WIDTH="14%"><A HREF="7.html">7</A></TD>
<TD WIDTH="14%"><A HREF="8.html">8</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD><A HREF="9.html" >9</A></TD>
<TD><A HREF="10.html">10</A></TD>
<TD><A HREF="11.html">11</A></TD>
<TD><A HREF="12.html">12</A></TD>
<TD><A HREF="13.html">13</A></TD>
</TR></TABLE>
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
<P> <hr> <P>
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<A HREF="../index.html"
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
<A HREF="/index.html"
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
<A HREF="../lg_bytes45.html"
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
<A HREF="../lg_tips45.html"
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
</BODY></HTML>
<!--endcut ========================================================= -->
Reference in New Issue View Git Blame Copy Permalink