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
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
|
Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
Path: vixie!news1.digital.com!uunet!in1.uu.net!usc!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
From: cdp@njit.edu (Chris Peckham)
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
Message-ID: <cptd-faq-2-810621452@njit.edu>
Followup-To: comp.protocols.tcp-ip.domains
Originator: cdp2582@hertz.njit.edu
Keywords: BIND,DOMAIN,DNS
Sender: news@njit.edu
Supersedes: <cptd-faq-2-807632375@njit.edu>
Nntp-Posting-Host: hertz.njit.edu
X-Posting-Frequency: posted on the 1st of each month
Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
References: <cptd-faq-1-810621452@njit.edu>
Date: Sat, 9 Sep 1995 04:38:21 GMT
Approved: news-answers-request@MIT.EDU
Expires: Sat 14 Oct 95 00:37:32 EDT
Lines: 1110
Xref: vixie comp.protocols.tcp-ip.domains:6019 comp.answers:13882 news.answers:49919
Posted-By: auto-faq 3.1.1.2
Archive-name: internet/tcp-ip/domains-faq/part2
Revision: 1.5 1995/05/12 18:50:41
This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>.
The latest version may always be found for anonymous ftp from
ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ
If you can contribute any answers for items in the TODO section, please do
so by sending e-mail to domain-faq@njit.edu ! If you know of any items that
are not included and you feel that they should be, send the relevant
information to domain-faq@njit.edu.
------------------------------
Date: Fri May 12 14:41:47 EDT 1995
Subject: Table of Contents
Table of Contents
=================
Part 1
------
0. TO DO
1. INTRODUCTION / MISCELLANEOUS
1.1 What is this newsgroup ?
1.2 More information
1.3 What is BIND and where is the latest version of BIND ?
1.4 How can I find the route between systems ?
1.5 Finding the hostname if you have the tcp-ip address
1.6 How to register a domain name
1.7 Change of Domain name
1.8 How memory and CPU does DNS use ?
1.9 Other things to consider when planning your servers
1.10 Proper way to get NS and reverse IP records into DNS
1.11 How to get my address assign from NIC?
1.12 Is there a block of private IP addresses I can use?
1.13 Cache failed lookups
1.14 What does an NS record really do ?
1.15 DNS ports
1.16 Obtaining the latest cache file
2. UTILITIES
2.1 Utilities to administer DNS zone files
2.2 DIG - Domain Internet Groper
2.3 DNS packet analyzer
2.4 host
2.5 Programming with DNS
2.6 A source of information relating to DNS
3. DEFINITIONS
3.1 TCP/IP Host Naming Conventions
3.2 Slaves and servers with forwarders
3.3 When is a server authoritative?
3.4 Underscore in host-/domain names
3.5 Lame delegation
3.6 What does opt-class field do?
3.7 Top level domains
3.8 Classes of networks
3.9 What is CIDR ?
3.10 What is the rule for glue ?
Part 2
------
4. CONFIGURATION
4.1 Changing a Secondary server to a Primary
4.2 How do I subnet a Class B Address ?
4.3 Subnetted domain name service
4.4 Recommended format/style of DNS files
4.5 DNS on a system not connected to the Internet
4.6 Multiple Domain configuration
4.7 wildcard MX records
4.8 How to identify a wildcard MX record
4.9 Why are fully qualified domain names recommended ?
4.10 Distributing load using named
4.11 Order of returned records
4.12 resolv.conf
4.13 Delegating authority
4.14 DNS instead of NIS on a Sun OS 4.1.x system
5. PROBLEMS
5.1 No address for root server
5.2 Error - No Root Nameservers for Class XX
5.3 Bind 4.9.x and MX querying?
5.4 Some root nameservers don't know localhost
5.5 MX records and CNAMES and separate A records for MX targets
5.6 NS is a CNAME
5.7 Nameserver forgets own A record
5.8 General problems (core dumps !)
5.9 malloc and DECstations
6. ACKNOWLEDGEMENTS
------------------------------
Date: Fri Dec 2 15:31:06 EST 1994
Subject: Q4.1 - Changing a Secondary server to a Primary
Q: Do I need to do anything special when I change a server from a secondary
to a primary ?
A: For 4.8.3, it's prudent to kill and restart following any changes to
named.boot.
In BIND 4.9.3, you only have to kill and restart named if you change
a primary zone to a secondary or v-v, or if you delete a zone and
remain authoritative for its parent. Every other case should be
taken care of by a HUP. (Ed. note: 4.9.3b9 may still require you to
kill and restart the server due to some bugs in the HUP code).
You will also need to update the server information on the root servers.
You can do this by filing a new domain registration form to inform
InterNIC of the change. They will then update the root server's SOA
records. This process usually takes 10-12 business days after they
receive the request.
-------------------------------
Date: Fri Apr 28 13:34:52 EDT 1995
Subject: Q4.2 - How do I subnet a Class B Address ?
Q: I just received a Class B internet address and I am wondering where to
get an RFC or other information on how to properly to the TCP/IP
sub-netting.
A: That you need to subnet at all is something of a misconception. You
can also think of a class B network as giving you 65,534 individual
hosts, and such a network will work. You can also configure your
class B as 16,384 networks of 2 hosts each. That's obviously not
very practical, but it needs to be made clear that you are not
constrained by the size of an octet (remember that many older
devices would not work in a network configured in this manner).
So, the question is: why do you need to subnet? One reason is that
it is easier to manage a subnetted network, and in fact, you can
delegate the responsibility for address space management to local
administrators on the various subnets. Also, IP based problems will
end up localized rather than affecting your entire network.
If your network is a large backbone with numerous segments
individually branching off the backbone, that too suggests
subnetting.
Subnetting can also be used to improve routing conditions.
You may wish to partition your network to disallow certain protocols
on certain segments of your net. You can, for example, restrict IP or
IPX to certain segments only by adding a router routing high level
protocols, and across the router you may have to subnet.
Finally, as far as how many subnets you need depends on the answer to
the above question. As far as subnet masks are concerned, the mask
can be anything from 255.0.0.0 to 255.255.255.252. You'll probably be
looking at 9 or 10 bits for the subnet (last octet 128 or 192
respectively). RFC1219 discusses the issue of subnetting very well
and leaves the network administrator with a large amount of flexibility
for future growth.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.3 -Subnetted domain name service
Q: After doing some reading (DNS and BIND, Albitz&Liu), I don't really
find any examples of handling subnetted class C networks as separate
DNS domains.
A: This is possible, just messy. You need to delegate down to the
fourth octet, so you will have one domain per IP address ! Here is
how you can subdelegate a in-addr.arpa address for non-byte aligned
subnet masks:
Take as an example the net 192.1.1.x, and example subnet mask
255.255.255.240.
We first define the domain for the class C net,
$origin 1.1.192.in-addr.arpa
@ SOA (usual stuff)
@ ns some.nameserver
ns some.other.nameserver
; delegate a subdomain
one ns one.nameserver
ns some.nameserver
; delegate another
two ns two.nameserver
ns some.nameserver
; CNAME pointers to subdomain one
0 CNAME 0.one
1 CNAME 1.one
; through
15 CNAME 15.one
; CNAME pointers to subdomain two
16 CNAME 16.two
17 CNAME 17.two
31 CNAME 31.two
; CNAME as many as required.
Now, in the delegated nameserver, one.nameserver
$origin one.1.1.192.in-addr.arpa
@ SOA (usual stuff)
NS one.nameserver
NS some.nameserver ; secondary for us
0 PTR onenet.one.domain
1 PTR onehost.one.domain
; through
15 PTR lasthost.one.domain
And similar for the two.1.1.192.in-addr.arpa delegated domain.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.4 - Recommended format/style of DNS files
Q: Are there any suggestions for how to layout DNS configuration files
(both forward and reverse)?
A: This answer is quoted from an article posted by Paul Vixie:
I've gone back and forth on the question of whether the BOG should
include a section on this topic. I know what I myself prefer, but
I'm wary of ramming my own stylistic preferences down the throat of
every BOG reader. But since you ask :-)...
Create /var/named. If your system is too old to have a /var, either
create one or use /usr/local/adm/named instead. Put your named.boot
in it, and make /etc/named.boot a symlink to it. If your system
doesn't have symlinks, you're S-O-L (but you knew that). In
named.boot, put a "directory" directive that specifies your actual
BIND working directory:
directory /var/named
All relative pathnames used in "primary", "secondary", and "cache"
directives will be evaluated relative to this directory. Create two
subdirectories, /var/named/pri and /var/named/sec. Whenever you add
a "primary" directive to your named.boot, use "pri/WHATEVER" as the
path name. And then put the primary zone file into "pri/WHATEVER".
Likewise when you add "secondary" directives, use "sec/WHATEVER" and
BIND (really named-xfer) will create the files in that
subdirectory.
(Variations: (1) make a midlevel directory "zones" and put "pri" and
"sec" into it; (2) if you tend to pick up a lot of secondaries from
a few hosts, group them together in their own subdirectories --
something like /var/named/zones/uucp if you're a UUCP Project name
server.)
For your forward files, name them after the zone. dec.com becomes
"/var/named/zones/pri/dec.com". For your reverse files, name them
after the network number. 0.1.16.in-addr.arpa becomes
"/var/named/zones/pri/16.1.0".
When creating or maintaining primary zone files, try to use the same
SOA values everywhere, except for the serial number which varies per
zone. Put a $ORIGIN directive at the top of the primary zone file,
not because its needed (it's not since the default origin is the
zone named in the "primary" directive) but because it make it easier
to remember what you're working on when you have a lot of primary
zones. Put some comments up there indicating contact information
for the real owner if you're proxying. Use RCS and put the "Id"
in a ";" comment near the top of the zone file.
The SOA and other top level information should all be listed
together. But don't put IN on every line, it defaults nicely. For
example:
==============
@ IN SOA gw.home.vix.com. postmaster.vix.com. (
1994082501 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 mins)
604800 ; expire (7 days)
3600 ) ; minimum (1 hour)
NS gw.home.vix.com.
NS ns.uu.net.
NS uucp-gw-1.pa.dec.com.
NS uucp-gw-2.pa.dec.com.
MX 10 gw.home.vix.com.
MX 20 uucp-gw-1.pa.dec.com.
MX 20 uucp-gw-1.pa.dec.com.
==============
I don't necessarily recommend those SOA values. Not every zone is
as volatile as the example shown. I do recommend that serial number
format; it's in date format with a 2-digit per-day revision number.
This format will last us until 2147 A.D. at which point I expect a
better solution will have been found :-). (Note that it would last
until 4294 A.D. except that there are some old BINDs out there that
use a signed quantity for representing serial number interally; I
suppose that as long as none of these are still running after 2047
A.D., that we can use the above serial number format until 4294
A.D., at which point a better solution will HAVE to be found.)
You'll note that I use a tab stop for "IN" even though I never again
specify it. This leaves room for names longer than 7 bytes without
messing up the columns. You might also note that I've put the MX
priority and destination in the same tab stop; this is because both
are part of the RRdata and both are very different from MX which is
an RRtype. Some folks seem to prefer to group "MX" and the priority
together in one tab stop. While this looks neat it's very confusing
to newcomers and for them it violates the law of least
astonishment.
If you have a multi-level zone (one which contains names that have
dots in them), you can use additional $ORIGIN statements but I
recommend against it since there is no "back" operator. That is,
given the above example you can add:
=============
$ORIGIN home
gw A 192.5.5.1
=============
The problem with this is that subsequent RR's had better be
somewhere under the "home.vix.com" name or else the $ORIGIN that
introduces them will have to use a fully qualified name. FQDN
$ORIGIN's aren't bad and I won't be mad if you use them.
Unqualified ones as shown above are real trouble. I usually stay
away from them and just put the whole name in:
=============
gw.home A 192.5.5.1
=============
In your reverse zones, you're usually in some good luck because the
owner name is usually a single short token or sometimes two.
=============
$ORIGIN 5.5.192.in-addr.arpa.
@ IN SOA ...
NS ...
1 PTR gw.home.vix.com.
=========================================
$ORIGIN 1.16.in-addr.arpa.
@ IN SOA ...
NS ...
2.0 PTR gatekeeper.dec.com.
=============
It is usually pretty hard to keep your forward and reverse zones in
synch. You can avoid that whole problem by just using "h2n" (see
the ORA book, DNS and BIND, and its sample toolkit, included in the
BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
command there to find this -- I never can remember where it's at).
"h2n" and many tools like it can just read your old /etc/hosts file
and churn it into DNS zone files. (May I recommend
contrib/decwrl/mkdb.pl from the BIND distribution?) However, if you
(like me) prefer to edit these things by hand, you need to follow
the simple convention of making all of your holes consistent. If
you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
your forward file you will have something like
=============
...
gw.home A 192.5.5.1
;avail A 192.5.5.2
pc.home A 192.5.5.3
=============
and in your reverse file you will have something like
=============
...
1 PTR gw.home.vix.com.
;2 PTR avail
3 PTR pc.home.vix.com.
=============
This convention will allow you to keep your sanity and make fewer
errors. Any kind of automation (h2n, mkdb, or your own
perl/tcl/awk/python tools) will help you maintain a consistent
universe even if it's also a complex one. Editing by hand doesn't
have to be deadly but you MUST take care.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.5 - DNS on a system not connected to the Internet
Q: How do I use DNS on a system that is not connected to the Internet or
set BIND up with an internal root server ?
A: You need to create your own root domain name server until you connect
to the internet. Your roots need to delegate to mydomain.com and any
in-addr.arpa subdomains you might have, and that's about it. As
soon as you're connected, rip out the fake roots and use the real
ones.
It does not actually have to be another server pretending to be the root.
You can set up the name server so that it is primary for each domain
above you and leave them empty (i.e. you are foo.bar.com - claim to be
primary for bar.com and com)
Q: What if you connect intermittently and want DNS to work when you are
connected, and "fail" when you are not ?
A: You can point the resolver at the name server at the remote site and
if the connection (SLIP/PPP) isn't up, the resolver doesn't have a
route to the remote server and since there's only one name server in
resolv.conf, the resolver quickly backs off the using /etc/hosts.
No problem. You could do the same with multiple name server and a
resolver that did configurable /etc/hosts fallback.
------------------------------
Date: Fri Dec 2 15:40:49 EST 1994
Subject: Q4.6 -Multiple Domain configuration
Q: I have seen sites that seem to have multiple domain names pointing to the
same destination. I would like to implement this and have found no
information explaining how to do it. What I would like to do is:
ftp ftp.biff.com connects user to -> ftp.biff.com
ftp ftp.fred.com connects user to -> ftp.biff.com
ftp ftp.bowser.com connects user to -> ftp.biff.com
A: This is done through CNAME records:
ftp.bowser.com. IN CNAME ftp.biff.com.
You can also do the same thing with multiple A records.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.7 - wildcard MX records
Q: Does BIND not understand wildcard MX records such as the following?
*.foo.com MX 0 mail.foo.com.
A: Explicit RR's at one level of specificity will, by design, "block" a
wildcard at a lesser level of specificity. I suspect that you have
an RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the
application of your "*.foo.com" wildcard. The initial MX query is
thus failing (NOERROR but an answer count of 0), and the backup
query finds the A RR for "bar.foo.com" and uses it to deliver the
mail directly (which is what you DIDN'T want it to do). Adding an
explicit MX RR for the host is therefore the right way to handle
this situation.
See RFC 1034, Section 4.3.3 ("Wildcards") for more information on
this "blocking" behavior, along with an illustrative example. See
also RFC 974 for an explanation of standard mailer behavior in the
face of an "empty" response to one's MX query.
Basically, what it boils down to is, there is no point in trying to
use a wildcard MX for a host which is otherwise listed in the DNS.
It just doesn't work.
------------------------------
Date: Thu Dec 1 11:10:39 EST 1994
Subject: Q4.8 - How to identify a wildcard MX record
Q: How do you identify a wildcard MX record ?
A: You don't really need to "identify" a wildcard MX RR. The precedence
for u@dom is:
exact match MX
exact match A
wildcard MX
One way to implement this is to query for ("dom",IN,MX) and if the
answer name that comes back is "*." something, you know it's a
wildcard, therefore you know there is no exact match MX, and you
therefore query for ("dom",IN,A) and if you get something, use it.
if you don't, use the previous wildcard response.
RFC 974 explains this pretty well.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.9 - Why are fully qualified domain names recommended ?
Q: Why are fully qualified domain names recommended ?
A: The documentation for BIND 4.9.2 says that the hostname should be set
to the full domain style name (i.e host.our.domain rather than
host). What advantages are there in this, and are there any adverse
consequences if we don't?
A: Paul Vixie likes to do it :-) He lists a few reasons -
* Sendmail can be configured to just use Dj$w rather than
Dj$w.mumble where "mumble" is something you have to edit in by
hand. Granted, most people use "mumble" elsewhere in their config
files ("tack on local domain", etc) but why should it be a
requirement ?
* The real reason is that not doing it violates a very useful invariant:
gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
If you take an address and go "backwards" through the PTR's with
it, you'll get a FQDN, and if you push that back through the A
RR's, you get the same address. Or you should. Many multi-homed
hosts violate this uncaringly.
If you take a non-FQDN hostname and push it "forwards" through the
A RR's, you get an address which, if you push it through the
PTR's, comes back as a FQDN which is not the same as the hostname
you started with. Consider the fact that, absent NIS/YP, there is
no "domainname" command analogous to the "hostname" command.
(NIS/YP's doesn't count, of course, since it's
sometimes-but-only-rarely the same as the Internet domain or
subdomain above a given host's name.) The "domain" keyword in
resolv.conf doesn't specify the parent domain of the current host;
it specifies the default domain of queries initiated on the
current host, which can be a very different thing. (As of RFC
1535 and BIND 4.9.2's compliance with it, most people use "search"
in resolv.conf, which overrides "domain", anyway.)
What this means is that there is NO authoritative way to
programmatically discover your host's FQDN unless it is set in the
hostname, or unless every application is willing to grovel the
"netstat -in" tables, find what it hopes is the primary address,
and do a PTR query on it.
FQDN /bin/hostnames are, intuitively or not, the simplest way to go.
------------------------------
Date: Wed Mar 1 11:04:43 EST 1995
Subject: Q4.10 - Distributing load using named
Q: If you attempt to distribute the load on a system using named, won't
the first response be cached, and then later queries use the cached
value? (This would be for requests that come through the same
server.)
A: Yes. So it can be useful to use a lower TTL on records where this is
important. You can use values like 300 or 500 seconds.
If your local caching server has ROUND_ROBIN, it does not matter
what the authoritative servers have -- every response from the cache
is rotated.
But if it doesn't, and the authoritative server site is depending on
this feature (or the old "shuffle-A") to do load balancing, then if
one doesn't use small TTLs, one could conceivably end up with a
really nasty situation, e.g., hundreds of workstations at a branch
campus pounding on the same front end at the authoritative server's
site during class registration.
Not nice.
A: Paul Vixie has an example of the ROUND_ROBIN code in action. Here is
something that he wrote regarding his example:
>I want users to be distributed evenly among those 3 hosts.
Believe it or not :-), BIND offers an ugly way to do this. I offer
for your collective amusement the following snippet from the
ugly.vix.com zone file:
hydra cname hydra1
cname hydra2
cname hydra3
hydra1 a 10.1.0.1
a 10.1.0.2
a 10.1.0.3
hydra2 a 10.2.0.1
a 10.2.0.2
a 10.2.0.3
hydra3 a 10.3.0.1
a 10.3.0.2
a 10.3.0.3
Note that having multiple CNAME RR's at a given name is
meaningless according to the DNS RFCs but BIND doesn't mind (in
fact it doesn't even complain). If you call
gethostbyname("hydra.ugly.vix.com") (try it!) you will get
results like the following. Note that there are two round robin
rotations going on: one at ("hydra",CNAME) and one at each
("hydra1",A) et al. I used a layer of CNAME's above the layer of
A's to keep the response size down. If you don't have nine
addresses you probably don't care and would just use a pile of
CNAME's pointing directly at real host names.
{hydra.ugly.vix.com}
name: hydra2.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.2.0.2 10.2.0.3 10.2.0.1
{hydra.ugly.vix.com}
name: hydra3.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.3.0.2 10.3.0.3 10.3.0.1
{hydra.ugly.vix.com}
name: hydra1.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.1.0.2 10.1.0.3 10.1.0.1
{hydra.ugly.vix.com}
name: hydra2.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.2.0.3 10.2.0.1 10.2.0.2
{hydra.ugly.vix.com}
name: hydra3.ugly.vix.com
aliases: hydra.ugly.vix.com
addresses: 10.3.0.3 10.3.0.1 10.3.0.2
------------------------------
Date: Sun Dec 4 22:12:32 EST 1994
Subject: Q4.11 - Order of returned records
Q: Is there any way to tell named to return records, specifically
address records, in the order in which they are listed in the
database?
It would appear that named consistently applies a sorting algorithm
to address records which seems to be virtually guaranteed to be
pessimal for our routers, which have many A records.
A: Sorting, is the *resolver's* responsibility. RFC 1123:
6.1.3.4 Multihomed Hosts
When the host name-to-address function encounters a host
with multiple addresses, it SHOULD rank or sort the
addresses using knowledge of the immediately connected
network number(s) and any other applicable performance or
history information.
DISCUSSION:
The different addresses of a multihomed host generally
imply different Internet paths, and some paths may be
preferable to others in performance, reliability, or
administrative restrictions. There is no general way
for the domain system to determine the best path. A
recommended approach is to base this decision on local
configuration information set by the system
administrator.
In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf
can be used to configure this.
------------------------------
Date: Fri Feb 10 15:46:17 EST 1995
Subject: Q4.12 - resolv.conf
Q: Why should I use "real" IP addresses in /etc/resolv.conf and not 0.0.0.0
or 127.0.0.1.
A: Paul Vixie writes on the issue of the contents of resolv.conf:
It's historical. Some kernels can't unbind a UDP socket's source
address, and some resolver versions (notably not including BIND
4.9.2 or 4.9.3's) try to do this. The result can be wide area
network traffic with 127.0.0.1 as the source address. Rather than
giving out a long and detailed map of version/vendor combinations of
kernels/BINDs that have/don't this problem, I just tell folks not to
use 127.0.0.1 at all.
0.0.0.0 is just an alias for the first interface address assigned
after a system boot, and if that interface is a up-and-down point to
point link (PPP, SLIP, whatever), there's no guarantee that you'll
be able to reach yourself via 0.0.0.0 during the entire lifetime of
any system instance. On most kernels you can finesse this by adding
static routes to 127.0.0.1 for each of your interface addresses, but
some kernels don't like that trick and rather than give a detailed
map of which ones work and which ones don't, I just globally
recommend against 0.0.0.0.
If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
kernel and resolver, then feel free to use them. If you don't know
for sure that it is safe, don't use them. I never use them (except
on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
127.0.0.1 since I ifconfig my lo0 before any other interface). The
operational advantage to using a real IP address rather than an
wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
otherwise share identical copies of your resolv.conf on all the
systems on any given subnet, not all of which will be servers.
A: The problem was with older versions of the resolver (4.8.X). If you
listed 127.0.0.1 as the first entry in resolv.conf, and for whatever
reason the local name server wasn't running and the resolver fell
back to the second name server listed, it would send queries to the
name server with the source IP address set to 127.0.0.1 (as it was
set when the resolver was trying to send to 127.0.0.1--you use the
loopback address to send to the loopback address).
------------------------------
Date: Mon Jan 2 13:50:13 EST 1995
Subject: Q4.13 - Delegating authority
Q: How do I delegate authority for domains within my domain ?
A: When you start having a very big domain that can be broken into logical
and separate entities that can look after their own DNS information,
you will probably want to do this. Maintain a central area for the
things that everyone needs to see and delegate the authority for the
other parts of the organization so that they can manage themselves.
Another essential piece of information is that every domain that
exists must have it NS records associated with it. These NS records
denote the name servers that are queried for information about that
zone. For your zone to be recognized by the outside world, the
server responsible for the zone above you must have created a NS
record for your machine in your domain. For example, putting the
computer club onto the network and giving them control over their
own part of the domain space we have the following.
The machine authorative for gu.uwa.edu.au is mackerel and the machine
authorative for ucc.gu.uwa.edu.au is marlin.
in mackerel's data for gu.uwa.edu.au we have the following
@ IN SOA ...
IN A 130.95.100.3
IN MX mackerel.gu.uwa.edu.au.
IN MX uniwa.uwa.edu.au.
marlin IN A 130.95.100.4
ucc IN NS marlin.gu.uwa.edu.au.
IN NS mackerel.gu.uwa.edu.au.
Marlin is also given an IP in our domain as a convenience. If they
blow up their name serving there is less that can go wrong because
people can still see that machine which is a start. You could place
"marlin.ucc" in the first column and leave the machine totally
inside the ucc domain as well.
The second NS line is because mackerel will be acting as secondary name
server for the ucc.gu domain. Do not include this line if you are not
authorative for the information included in the sub-domain.
------------------------------
Date: Wed Mar 1 11:45:00 EST 1995
Subject: Q4.14 - DNS instead of NIS on a Sun OS 4.1.x system
Q: I would appreciate any comments on whether running bind 4.9.x will
enable sendmail, ftp, telnet and other TCP/IP services to bypass
NIS and connect directly to named.
A: How to do this is documented quite well in the comp.sys.sun.admin FAQ in
questions one and two. You can get them from:
ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/sun-faq.general
http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq
as well as from rtfm.mit.edu in the usual place, etc.
------------------------------
Date: Mon Jan 2 13:49:43 EST 1995
Subject: Q5.1 - No address for root server
Q: I've been getting the following messages lately from bind-4.9.2..
ns_req: no address for root server
We are behind a firewall and have the following for our named.cache file -
; list of servers
. 99999999 IN NS POBOX.FOOBAR.COM.
99999999 IN NS FOOHOST.FOOBAR.COM.
foobar.com. 99999999 IN NS pobox.foobar.com.
A: You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets the
correct list of root servers from it, then tries again and fails
because of your firewall.
You will need a 'forwarder' definition, to ensure that all requests
are forwarded to a host which can penetrate the firewall. And
it is unwise to put phony data into 'named.cache'.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q5.2 - Error - No Root Nameservers for Class XX
Q: I've received errors before about "No root nameservers for class XX"
but they've been because of network connectivity problems.
I believe that Class 1 is Internet Class data.
And I think I heard someone say that Class 4 is Hesiod??
Does anyone know what the various Class numbers are?
A: From RFC 1700:
DOMAIN NAME SYSTEM PARAMETERS
The Internet Domain Naming System (DOMAIN) includes several
parameters. These are documented in [RFC1034] and [RFC1035]. The
CLASS parameter is listed here. The per CLASS parameters are
defined in separate RFCs as indicated.
Domain System Parameters:
Decimal Name References
-------- ---- ----------
0 Reserved [PM1]
1 Internet (IN) [RFC1034,PM1]
2 Unassigned [PM1]
3 Chaos (CH) [PM1]
4 Hesoid (HS) [PM1]
5-65534 Unassigned [PM1]
65535 Reserved [PM1]
DNS information for RFC 1700 was taken from
ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters
Hesiod is class 4, and there are no official root nameservers for class
4, so you can safely declare yourself one if you like. You might want
to put up a packet filter so that no one outside your network is capable
of making Hesiod queries of your machines, if you define yourself to be
a root nameserver for class 4.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q5.3 - Bind 4.9.x and MX querying?
Q: If I query a 4.9.x DNS server for MX records, a list of the MX records
as well as a list of the authorative nameservers is returned. Why ?
A: Bind 4.9.2 returns the list of nameserver that are authorative
for a domain in the response packet, along with their IP
addresses in the additional section.
------------------------------
Date: Sat Sep 9 00:36:01 EDT 1995
Subject: Q5.4 - Some root nameservers don't know localhost
Q: Do I need to define an A record for localhost ?
Where is the A record for 127.0.0.1 defined? I see where
the PTR record is defined pointing to localhost, but can't find
where the A record is. And is the A record supposed to be
localhost.MY_DOMAIN or just localhost ?
A: Somewhere deep in the BOG (BIND Operations Guide) that came with
4.9.3 (section 5.4.3), it says that you define this yourself
(if need be) in the same zone files as your "real" IP addresses
for your domain. Quoting the BOG:
... As implied by this PTR
record, there should be a ``localhost.my.dom.ain''
A record (with address 127.0.0.1) in every domain
that contains hosts. ``localhost.'' will lose its
trailing dot when 1.0.0.127.in-addr.arpa is queried
for;...
The sample files in the BIND distribution show you what needs to be
done (see the BOG).
Some HP boxen (especially those running HP OpenView) will also need
"loopback" defined with this IP address. You may set it as a CNAME
record pointing to the "localhost." record.
------------------------------
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q5.5 - MX records and CNAMES and separate A records for MX targets
Q: The O'Reilly "DNS and Bind" book warns against using non-canonical
names in MX records, however, this warning is given in the context
of mail hubs that MX to each other for backup purposes. I don't see
how this applies to mail spokes. RFC 974 has a similar warning, but
I can not see where it specifically prohibits using an alias in an
MX record.
A: Without the restrictions in the RFC, a MTA must request the A records
for every MX listed to determine if it is in the MX list then reduce
the list. This introduces many more lookups than would other wise be
required. If you are behind a 1200 bps link YOU DON'T WANT TO DO
THIS. The addresses associated with CNAMES are not passed as
additional data so you will force additional traffic to result even
if you are running a caching server locally.
There is also the problem of how does the MTA find all of it's
IP addresses. This is not straight forward. You have to be able
to do this is you allow CNAMEs (or extra A's) as MX targets.
The letter of the law is that an MX record should point to an A record.
There is no "real" reason to use CNAMEs for MX targets or separate
As for nameservers any more. CNAMEs for services other than mail
should be used because there is no specified method for locating the
desired server yet.
People don't care what the names of MX targets are. They're
invisible to the process anyway. If you have mail for "mary"
redirected to "sue" is totally irrelevant. Having CNAMEs as the
targets of MX's just needlessly complicates things, and is more work
for the resolver.
Having separate A's for nameservers like "ns.your.domain" is
pointless too, since again nobody cares what the name of your
nameserver is, since that too is invisible to the process. If you
move your nameserver from "mary.your.domain" to "sue.your.domain"
nobody need care except you and your parent domain administrator
(and the InterNIC). Even less so for mail servers, since only you
are affected.
Q: Given the example -
hello in cname realname
mailx in mx 0 hello
Now, while reading the operating manual of bind it clearly states
that this is *not* valid. These two statements clearly contradict
each other. Is there some later rfc than 974 that overrides what is
said in there with respect to MX and CNAMEs? Anyone have the
reference handy?
A: This isn't what the BOG says at all. See below. You can have a CNAME
that points to some other RR type; in fact, all CNAMEs have to point
to other names (Canonical ones, hence the C in CNAME). What you
can't have is an MX that points to a CNAME. MX RR's that point to
names which have only CNAME RR's will not work in many cases, and
RFC 974 intimates that it's a bad idea:
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
Here's the relevant BOG snippet:
aliases {ttl} addr-class CNAME Canonical name
ucbmonet IN CNAME monet
The Canonical Name resource record, CNAME, speci-
fies an alias or nickname for the official, or
canonical, host name. This record should be the
only one associated with the alias name. All other
resource records should be associated with the
canonical name, not with the nickname. Any
resource records that include a domain name as
their value (e.g., NS or MX) must list the canoni-
cal name, not the nickname.
------------------------------
Date: Wed Mar 1 11:14:10 EST 1995
Subject: Q5.6 - NS is a CNAME
Q: Can I do this ? Is it legal ?
@ SOA (.........)
NS ns.host.this.domain.
NS second.host.another.domain.
ns CNAME third
third IN A xxx.xxx.xxx.xxx
A: No. Only one RR type is allowed to refer, in its data field, to a
CNAME, and that's CNAME itself. So CNAMEs can refer to CNAMEs but
NSs and MXs cannot.
BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than
simply failing as pre-4.9 servers did. Here's a current example:
Dec 7 00:52:18 gw named[17561]: \
"foobar.com IN NS" points to a CNAME (foobar.foobar.com)
Here is the reason why:
Nameservers are not required to include CNAME records in the
Additional Info section returned after a query. It's partly an
implementation decision and partly a part of the spec. The
algorithm described in RFC 1034 (pp24,25; info also in RFC 1035,
section 3.3.11, p 18) says 'Put whatever addresses are available
into the additional section, using glue RRs [if necessary]'.
Since NS records are speced to contain only primary names of
hosts, not CNAMEs, then there's no reason for algorithm to
mention them. If, on the other hand, it's decided to allow CNAMEs
in NS records (and indeed in other records) then there's no
reason that CNAME records might not be included along with A
records. The Additional Info section is intended for any
information that might be useful but which isn't strictly the
answer to the DNS query processed. It's an implementation
decision in as much as some servers used to follow CNAMEs in
NS references.
------------------------------
Date: Fri Dec 2 16:17:31 EST 1994
Subject: Q5.7 - Nameserver forgets own A record
Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.
Periodically, the nameserver will seem to "forget" its own A record,
although the other information stays intact. One theory I had was
that somehow a site that the nameserver was secondary for was
"corrupting" the A record somehow.
A: This is invariably due to not removing ALL of the cached zones
when you moved to 4.9.X. Remove ALL cached zones and restart
your nameservers.
You get "ignoreds" because the primaries for the relevant zones are
running old versions of BIND which pass out more glue than is
required. named-xfer trims off this extra glue.
------------------------------
Date: Sun Dec 4 22:21:22 EST 1994
Subject: Q5.8 - General problems (core dumps !)
Q: I am running bind 4.9.3b9p1 on a DEC alpha OSF/1 V3.0 and have had it
core dump while in debug mode. The last lines printed to named.run
were [...]
A: Paul Vixie says:
I'm always interested in hearing about cases where BIND dumps core.
However, I need a stack trace. Compile with -g and not -O (unless
you are using gcc and know what you are doing) and then when it
dumps core, get into dbx or gdb using the executable and the core
file and use "bt" to get a stack trace. Send it to me
<paul@vix.com> along with specific circumstances leading to or
surrounding the crash (test data, tail of the debug log, tail of the
syslog... whatever matters) and ideally you should save your core
dump for a day or so in case I have questions you can answer via
gdb/dbx.
------------------------------
Date: Mon Jan 2 14:19:22 EST 1995
Subject: Q5.9 - malloc and DECstations
We have replaced malloc on our DECstations with a malloc that is more
compact in memory usage, and this helped the operation of bind a lot.
The source is now available for anonymous ftp from
ftp://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz
------------------------------
Date: Fri Apr 28 13:56:32 EDT 1995
Subject: Q6 - Acknowledgements
Listed in e-mail address alphabetical order, the following people have
contributed to this FAQ:
Benoit.Grange@inria.fr (Benoit.Grange)
D.T.Shield@csc.liv.ac.uk (Dave Shield)
adam@comptech.demon.co.uk (Adam Goodfellow)
andras@is.co.za (Andras Salamon)
barmar@nic.near.net (Barry Margolin)
barr@pop.psu.edu (David Barr)
bj@herbison.com (B.J. Herbison)
bje@cbr.fidonet.org (Ben Elliston)
brad@birch.ims.disa.mil (Brad Knowles)
ckd@kei.com (Christopher Davis)
cdp@hertz.njit.edu (Chris Peckham)
cricket@hp.com (Cricket Liu)
cudep@csv.warwick.ac.uk (Ian 'Vato' Dickinson [ID17])
dparter@cs.wisc.edu (David Parter)
e07@nikhef.nl (Eric Wassenaar)
fwp@CC.MsState.Edu (Frank Peters)
gah@cco.caltech.edu (Glen A. Herrmannsfeldt)
glenn@popco.com (Glenn Fleishman)
harvey@indyvax.iupui.edu (James Harvey)
hubert@cac.washington.edu (Steve Hubert)
jmalcolm@uunet.uu.net (Joseph Malcolm)
jhawk@panix.com (John Hawkinson)
kevin@cfc.com (Kevin Darcy)
lamont@abstractsoft.com (Sean T. Lamont)
lavondes@tidtest.total.fr (Michel Lavondes)
mark@ucsalf.ac.uk (Mark Powell)
marka@syd.dms.CSIRO.AU (Mark Andrews)
mathias@unicorn.swi.com.sg (Mathias Koerber)
mjo@iao.ford.com (Mike O'Connor)
nick@flapjack.ieunet.ie (Nick Hilliard)
patrick@oes.amdahl.com (Patrick J. Horgan)
ph10@cus.cam.ac.uk (Philip Hazel)
rv@seins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
shields@tembel.org (Michael Shields)
tanner@george.arc.nasa.gov (Rob Tanner)
vixie@vix.com (Paul A Vixie)
wag@swl.msd.ray.com (William Gianopoulos {84718})
whg@inel.gov (Bill Gray)
wolf@pasteur.fr (Christophe Wolfhugel)
Thank you !
|