1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
|
<!--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:answerguy@ssc.com">answerguy@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/ssc.copying.html"
>Copyright ©</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="../../lg_toc45.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 ========================================================= -->
|
