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
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
|
Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
From: cdp2582@hertz.njit.edu (Chris Peckham)
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
Message-ID: <cptd-faq-1-849940949@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-1-847336183@njit.edu>
Nntp-Posting-Host: hertz.njit.edu
X-Posting-Frequency: posted during the first week 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
Date: Sat, 7 Dec 1996 06:42:36 GMT
Approved: news-answers-request@MIT.EDU
Expires: Sat 11 Jan 97 02:42:29 EDT
Lines: 1582
Xref: vixie comp.protocols.tcp-ip.domains:12904 comp.answers:22440 news.answers:85682
Posted-By: auto-faq 3.1.1.2
Archive-name: internet/tcp-ip/domains-faq/part1
Revision: 1.14 1996/12/07 06:42:05
Note that this posting has been split into two parts because of its size.
$Id: FAQ.1of2,v 1.1 1998/05/22 02:45:42 millert Exp $
A new version of this document appears monthly. If this copy is more
than a month old it may be out of date.
This FAQ is edited and maintained by Chris Peckham, <cdp@pfmc.net>. The
most recently posted version may be found for anonymous ftp from
rtfm.mit.edu : /pub/usenet/news.answers/internet/tcp-ip/domains-faq
It is also available in HTML from
http://www.users.pfmc.net/~cdp/cptd-faq/.
If you can contribute any answers for items in the TODO section, please do
so by sending e-mail to <domain-faq@pfmc.net> ! If you know of any items
that are not included and you feel that they should be, send the
relevant information to <domain-faq@pfmc.net>.
===============================================================================
Index
Section 1. TO DO / UPDATES
Q1.1 Contributions needed
Q1.2 UPDATES / Changes since last posting
Section 2. INTRODUCTION / MISCELLANEOUS
Q2.1 What is this newsgroup ?
Q2.2 More information
Q2.3 What is BIND ?
Q2.4 What is the difference between BIND and DNS ?
Q2.5 Where is the latest version of BIND located ?
Q2.6 How can I find the path taken between two systems/domains ?
Q2.7 How do you find the hostname given the TCP-IP address ?
Q2.8 How do I register a domain ?
Q2.9 How can I change the IP address of our server ?
Q2.10 Issues when changing your domain name
Q2.11 How memory and CPU does DNS use ?
Q2.12 Other things to consider when planning your servers
Q2.13 Proper way to get NS and reverse IP records into DNS
Q2.14 How do I get my address assigned from the NIC ?
Q2.15 Is there a block of private IP addresses I can use?
Q2.16 Does BIND cache negative answers (failed DNS lookups) ?
Q2.17 What does an NS record really do ?
Q2.18 DNS ports
Q2.19 What is the cache file
Q2.20 Obtaining the latest cache file
Q2.21 Selecting a nameserver/root cache
Q2.22 InterNIC and domain names
Section 3. UTILITIES
Q3.1 Utilities to administer DNS zone files
Q3.2 DIG - Domain Internet Groper
Q3.3 DNS packet analyser
Q3.4 host
Q3.5 How can I use DNS information in my program?
Q3.6 A source of information relating to DNS
Section 4. DEFINITIONS
Q4.1 TCP/IP Host Naming Conventions
Q4.2 What are slaves and forwarders ?
Q4.3 When is a server authoritative?
Q4.4 My server does not consider itself authoritative !
Q4.5 NS records don't configure servers as authoritative ?
Q4.6 underscore in host-/domainnames
Q4.7 What is lame delegation ?
Q4.8 How can I see if the server is "lame" ?
Q4.9 What does opt-class field in a zone file do?
Q4.10 Top level domains
Q4.11 Classes of networks
Q4.12 What is CIDR ?
Q4.13 What is the rule for glue ?
Section 5. CONFIGURATION
Q5.1 Changing a Secondary server to a Primary server ?
Q5.2 Moving a Primary server to another server
Q5.3 How do I subnet a Class B Address ?
Q5.4 Subnetted domain name service
Q5.5 Recommended format/style of DNS files
Q5.6 DNS on a system not connected to the Internet
Q5.7 Multiple Domain configuration
Q5.8 wildcard MX records
Q5.9 How do you identify a wildcard MX record ?
Q5.10 Why are fully qualified domain names recommended ?
Q5.11 Distributing load using named
Q5.12 Order of returned records
Q5.13 resolv.conf
Q5.14 How do I delegate authority for sub-domains ?
Q5.15 DNS instead of NIS on a Sun OS 4.1.x system
Q5.16 Patches to add functionality to BIND
Q5.17 How to serve multiple domains from one server
Section 6. PROBLEMS
Q6.1 No address for root server
Q6.2 Error - No Root Nameservers for Class XX
Q6.3 Bind 4.9.x and MX querying?
Q6.4 Do I need to define an A record for localhost ?
Q6.5 MX records, CNAMES and A records for MX targets
Q6.6 Can an NS record point to a CNAME ?
Q6.7 Nameserver forgets own A record
Q6.8 General problems (core dumps !)
Q6.9 malloc and DECstations
Q6.10 Can't resolve names without a "."
Q6.11 Err/TO errors being reported
Q6.12 Why does swapping kill BIND ?
Section 7. ACKNOWLEDGEMENTS
Q7.1 How is this FAQ generated ?
Q7.2 What formats are available ?
Q7.3 Contributors
===============================================================================
Section 1. TO DO / UPDATES
Q1.1 Contributions needed
Q1.2 UPDATES / Changes since last posting
-----------------------------------------------------------------------------
Question 1.1. Contributions needed
Date: Fri Dec 6 00:40:00 EST 1996
* Expand the slave/forward section
-----------------------------------------------------------------------------
Question 1.2. UPDATES / Changes since last posting
Date: Fri Dec 6 00:40:00 EST 1996
* The FAQ is now maintained in BFNN (Bizzare format with No Name). This
allows me to create ASCII, HTML, and GNU info (postscript coming soon)
from one source file.
* References to 4.9.4 changed to 4.9.5.
* memory/CPU usage question - removed uunet map reference. Not there...
* Minor edits of information and questions for new format.
* How do I delegate authority for sub-domains ? - edited answer
===============================================================================
Section 2. INTRODUCTION / MISCELLANEOUS
Q2.1 What is this newsgroup ?
Q2.2 More information
Q2.3 What is BIND ?
Q2.4 What is the difference between BIND and DNS ?
Q2.5 Where is the latest version of BIND located ?
Q2.6 How can I find the path taken between two systems/domains ?
Q2.7 How do you find the hostname given the TCP-IP address ?
Q2.8 How do I register a domain ?
Q2.9 How can I change the IP address of our server ?
Q2.10 Issues when changing your domain name
Q2.11 How memory and CPU does DNS use ?
Q2.12 Other things to consider when planning your servers
Q2.13 Proper way to get NS and reverse IP records into DNS
Q2.14 How do I get my address assigned from the NIC ?
Q2.15 Is there a block of private IP addresses I can use?
Q2.16 Does BIND cache negative answers (failed DNS lookups) ?
Q2.17 What does an NS record really do ?
Q2.18 DNS ports
Q2.19 What is the cache file
Q2.20 Obtaining the latest cache file
Q2.21 Selecting a nameserver/root cache
Q2.22 InterNIC and domain names
-----------------------------------------------------------------------------
Question 2.1. What is this newsgroup ?
Date: Thu Dec 1 11:08:28 EST 1994
comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion on
issues relating to the Domain Name System (DNS).
This newsgroup is not for issues directly relating to IP routing and
addressing. Issues of that nature should be directed towards
comp.protocols.tcp-ip.
-----------------------------------------------------------------------------
Question 2.2. More information
Date: Fri Dec 6 00:41:03 EST 1996
You can find more information concerning DNS in the following places:
* The BOG (BIND Operations Guide) - in the BIND distribution
* The FAQ included with BIND 4.9.5 in doc/misc/FAQ
* DNS and BIND by Albitz and Liu (an O'Reilly & Associates Nutshell
handbook)
* A number of RFCs (920, 974, 1032, 1034, 1101, 1123, 1178, 1183, 1348,
1535, 1536, 1537, 1591, 1706, 1712, 1713, 1912, 1918)
* The DNS Resources Directory (DNSRD) http://www.dns.net/dnsrd/
* If you are having troubles relating to sendmail and DNS, you may wish to
refer to the USEnet newsgroup comp.mail.sendmail and/or the FAQ for that
newsgroup which may be found for anonymous ftp at rtfm.mit.edu :
/pub/usenet/news.answers/mail/sendmail-faq
* Information concerning some frequently asked questions relating to the
Internet (i.e., what is the InterNIC, what is an RFC, what is the IETF,
etc) may be found for anonymous ftp from ds.internic.net : /fyi/fyi4.txt
A version may also be obtained with the URL
gopher://ds.internic.net/00/fyi/fyi4.txt.
* Information on performing an initial installation of BIND may be found
using the DNS Resources Directory at
http://www.dns.net/dnsrd/docs/basic.txt
* Three other USEnet newsgroups:
* comp.protocols.dns.bind
* comp.protocols.dns.ops
* comp.protocols.dns.std
-----------------------------------------------------------------------------
Question 2.3. What is BIND ?
Date: Tue Sep 10 23:15:58 EDT 1996
From the BOG Introduction -
The Berkeley Internet Name Domain (BIND) implements an Internet name
server for the BSD operating system. The BIND consists of a server (or
``daemon'') and a resolver library. A name server is a network
service that enables clients to name resources or objects and share this
information with other objects in the network. This in effect is a
distributed data base system for objects in a computer network. BIND
is fully integrated into BSD (4.3 and later releases) network programs
for use in storing and retrieving host names and address. The system
administrator can configure the system to use BIND as a replacement to
the older host table lookup of information in the network hosts file
/etc/hosts. The default configuration for BSD uses BIND.
-----------------------------------------------------------------------------
Question 2.4. What is the difference between BIND and DNS ?
Date: Tue Sep 10 23:15:58 EDT 1996
(text provided by Andras Salamon) DNS is the Domain Name System, a set of
protocols for a distributed database that was originally designed to
replace /etc/hosts files. DNS is most commonly used by applications to
translate domain names of hosts to IP addresses. A client of the DNS is
called a resolver; resolvers are typically located in the application
layer of the networking software of each TCP/IP capable machine. Users
typically do not interact directly with the resolver. Resolvers query the
DNS by directing queries at name servers that contain parts of the
distributed database that is accessed by using the DNS protocols. In
common usage, `the DNS' usually refers just to the data in the database.
BIND (Berkeley Internet Name Domain) is an implementation of DNS, both
server and client. Development of BIND is funded by the Internet Software
Consortium and is coordinated by Paul Vixie. BIND has been ported to
Windows NT and VMS, but is most often found on Unix. BIND source code is
freely available and very complex; most of the development on the DNS
protocols is based on this code; and most Unix vendors ship BIND-derived
DNS implementations. As a result, the BIND name server is the most widely
used name server on the Internet. In common usage, `BIND' usually refers
to the name server that is part of the BIND distribution, and sometimes to
name servers in general (whether BIND-derived or not).
-----------------------------------------------------------------------------
Question 2.5. Where is the latest version of BIND located ?
Fri Dec 6 00:23:19 EST 1996
This information may be found at http://www.vix.com/isc/bind.html
At this time, BIND version of 4.9.5 may be found for anonymous ftp from
ftp.vix.com : /pub/bind/release/4.9.5/bind-4.9.5-REL.tar.gz
Other sites that officially mirror the BIND distribution are
* bind.fit.qut.edu.au : /pub/bind
* ftp.funet.fi : /pub/unix/tcpip/dns/bind
* ftp.univ-lyon1.fr : /pub/mirrors/unix/bind
* ftp.oleane.net : /pub/mirrors/unix/bind
* ftp.ucr.ac.cr : /pub/Unix/dns/bind
* ftp.luth.se : /pub/unix/dns/bind/beta
You may need GNU zip, Larry Wall's patch program (if there are any patch
files), and a C compiler to get BIND running from the above mentioned
source.
GNU zip is available for anonymous ftp from
prep.ai.mit.edu : /pub/gnu/gzip-1.2.4.tar
patch is available for anonymous ftp from
prep.ai.mit.edu : /pub/gnu/patch-2.1.tar.gz
A version of BIND for Windows NT is available for anonymous ftp from
ftp.vix.com : /pub/bind/release/4.9.5/contrib/ntdns495relbin.zip
and
ftp.vix.com : /pub/bind/release/4.9.5/contrib/ntbind495rel.zip
-----------------------------------------------------------------------------
Question 2.6. How can I find the path taken between two systems/domains ?
Date: Fri Dec 6 00:10:31 EST 1996
On a Unix system, use traceroute. If it is not available to you, you may
obtain the source source for 'traceroute', compile it and install it on
your system.
One version of this program with additional functionality may be found for
anonymous ftp from
ftp.nikhef.nl : /pub/network/traceroute.tar.Z
Another version may be found for anonymous ftp from
ftp.psc.edu : /pub/net_tools/traceroute.tar
-----------------------------------------------------------------------------
Question 2.7. How do you find the hostname given the TCP-IP address ?
Date: Thu Dec 1 09:55:24 EST 1994
For an address a.b.c.d you can always do:
% nslookup
> set q=ptr
> d.c.b.a.in-addr.arpa.
Most newer version of nslookup (since 4.8.3) will recognize an address, so
you can just say:
% nslookup a.b.c.d
DiG will work like this also:
% dig -x a.b.c.d
host from the contrib/host from the bind distribution may also be used.
-----------------------------------------------------------------------------
Question 2.8. How do I register a domain ?
Date: Wed Sep 4 23:59:42 EDT 1996
You can talk to your Internet Service Provider (ISP). They can submit the
registration for you. If you are not going to be directly connected, they
should be able to offer MX records for your domain for mail delivery (so
that mail sent to the new domain will be sent to your "standard" account).
In the case where the registration is done by the organization itself, it
still makes the whole process much easier if the ISP is approached for
secondary servers _before_ the InterNIC is approached for registration.
For information about making the registration yourself, look to the
InterNIC (or other similar organization).
* anonymout ftp from internic.net : /templates
* gopher://rs.internic.net/
* http://rs.internic.net/reg/reg-forms.html
* http://www.ripe.net/
You will need at least two domain name servers when you register your
domain. Many ISP's are willing to provide primary and/or secondary name
service for their customers.
Please note that the InterNIC is now charging a fee for domain names in
the "COM", "ORG", and "NET". More information may be found from the
Internic at
http://rs.internic.net/domain-info/fee-policy.html
Many times, registration of a domain name can be initiated by sending
e-mail to the zone contact. You can obtain the contact in the SOA record
for the country, or in a whois server:
$ nslookup -type=SOA fr.
origin = ns1.nic.fr
mail addr = nic.nic.fr
...
The mail address to contact in this case is 'nic@nic.fr' (you must
substitute an '@' for the first dot in the mail addr field).
An alternate method to obtain the e-mail address of the national NIC is
the 'whois' server at InterNIC.
You may be requested to make your request to another email address or
using a certain information template/application.
-----------------------------------------------------------------------------
Question 2.9. How can I change the IP address of our server ?
Date: Sun May 5 22:46:28 EDT 1996
(From Mark Andrews) Before the move.
* Ensure you are running a modern nameserver. BIND 4.9.3-REL + Patch1 is a
good choice.
* Inform all your secondaries that you are going to change. Have them
install both the current and new addresses in their named.boot's.
* Drop the ttl of the A's associated with the nameserver to something
small (5 min is usually good).
* Drop the refesh and retry times of the zone containing the forward
records for the server.
* Configure the new reverse zone before the move and make sure it is
operational.
* On the day of the move add the new A record(s) for the server. Don't
forget to have these added to parent domains. You will look like you are
multihomed with one interface dead.
Move the machine after gracefully terminating any other services it is
offering. Then,
* Fixup the A's, ttl, refresh and retry counters. (If you are running an
all server EDIT out all references to the old addresses in the cache
files).
* Inform all the secondaries the move is complete.
* Inform the parents of all zones you are primary of the new NS/A pairs
for the relevent zones.
* Inform all the administators of zones you are secondaring that the
machine has moved.
* For good measure update the serial no for all zones you are primary for.
This will flush out old A's.
-----------------------------------------------------------------------------
Question 2.10. Issues when changing your domain name
Date: Sun Nov 27 23:32:41 EST 1994
If you are changing your domain name from abc.foobar.com to foobar.net,
the forward zones are easy and there are a number of ways to do it. One
way is the following:
Have a single db file for the 2 domains, and have a single machine be the
primary server for both abc.foobar.com and foobar.net.
To resolve the host foo in both domains, use a single zone file which
merely uses this for the host:
foo IN A 1.2.3.4
Use a "@" wherever the domain would be used ie for the SOA:
@ IN SOA (...
Then use this pair of lines in your named.boot:
primary abc.foobar.com db.foobar
primary foobar.net db.foobar
The reverse zones should either contain PTRs to both names, or to
whichever name you believe to be canonical currently.
-----------------------------------------------------------------------------
Question 2.11. How memory and CPU does DNS use ?
Date: Fri Dec 6 01:07:56 EST 1996
It can use quite a bit ! The main thing that BIND needs is memory. It
uses very little CPU or network bandwidth. The main considerations to
keep in mind when planning are:
* How many zones do you have and how large are they ?
* How many clients do you expect to serve and how active are they ?
As an example, here is a snapshot of memory usage from CSIRO Division of
Mathematics and Statistics, Australia
Named takes several days to stabalize its memory usage.
Our main server stabalises at ~10Mb. It takes about 3 days to
reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.
As another example, here is the configuration of ns.uu.net (from late
1994):
ns.uu.net only does nameservice. It is running a version of BIND
4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
that Sun OS will reserve swap for each fork, even if it is not needed)
running Sun OS 4.1.3_U1.
Joseph Malcolm, of Alternet, states that named generally hovers at
5-10% of the CPU, except after a reload, when it eats it all.
-----------------------------------------------------------------------------
Question 2.12. Other things to consider when planning your servers
Date: Mon Jan 2 14:24:51 EST 1995
When making the plans to set up your servers, you may want to also
consider the following issues:
A) Server O/S limitations/capacities (which tend to be widely
divergent from vendor to vendor)
B) Client resolver behavior (even more widely divergent)
C) Expected query response time
D) Redundancy
E) Desired speed of change propagation
F) Network bandwidth availability
G) Number of zones/subdomain-levels desired
H) Richness of data stored (redundant MX records? HINFO records?)
I) Ease of administration desired
J) Network topology (impacts reverse-zone volume)
Assuming a best-possible case for the factors above, particularly (A), (B),
(C), (F), (G) & (H), it would be possible to run a 1000-node domain
using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM
by today's standards, e.g. 4 or 8 Meg. However, this configuration would
be slow, unreliable, and would provide no functionality beyond your basic
address-to-name and name-to-address mappings.
Beyond that baseline case, depending on what factors listed above,
you may want look at other strategies, such splitting up the DNS
traffic among several machines strategically located, possibly larger ones,
and/or subdividing your domain itself. There are many options, tradeoffs,
and DNS architectural paradigms from which to choose.
-----------------------------------------------------------------------------
Question 2.13. Proper way to get NS and reverse IP records into DNS
Date: Mon Jan 2 13:03:53 EST 1995
Reverse domain registration is separate from forward domain registration.
Blocks of network addresses have been delegated by the InterNIC. Check if
your network a.b.c.0 is in such a block by using nslookup:
nslookup -type=soa c.b.a.in-addr.arpa.
nslookup -type=soa b.a.in-addr.arpa.
nslookup -type=soa a.in-addr.arpa.
One of the above should give you the information you are looking for (the
others will return with an error something like `*** No start of authority
(SOA) records available for ...') This will give you the email address of
the person to whom you should address your change request.
If none of these works, your network probably has not been delegated by
the InterNIC and you need to contact them directly.
CIDR has meant that the registration is delegated, but registration of
in-addr.arpa has always been separate from forward zones - and for good
reason - in that the forward and reverse zones may have different
policies, contents etc, may be served by a different set of nameservers,
and exist at different times (usually only at point of creation). There
isn't a one-to-one mapping between the two, so merging the registration
would probably cause more problems than people forgetting/not-knowing that
they had to register in-addr.arpa zones separately. For example, there
are organizations that have hundreds of networks and two or more domains,
with a sprinkling of machines from each network in each of the domains.
-----------------------------------------------------------------------------
Question 2.14. How do I get my address assigned from the NIC ?
Date: Fri Dec 6 01:11:34 EST 1996
You should probably ask your Internet provider to give you an address.
These days, addresses are being distributed through the providers, so that
they can assign adjacent blocks of addresses to sites that go through the
same provider, to permit more efficient routing on the backbones.
Unless you have thousands of hosts, you probably won't be able to get a
class B these days. Instead, you can get a series of class C networks.
Large requests will be queried, so be ready to provide a network plan if
you ask for more than 16 class C networks.
If you can't do this through your Internet provider, you can look for a
subnet registration form on rs.internic.net. See the answer in this FAQ
to the question "How do I register a domain" for a URL to these forms.
-----------------------------------------------------------------------------
Question 2.15. Is there a block of private IP addresses I can use?
Date: Sun May 5 23:02:49 EDT 1996
Yes there is. Please refer to RFC 1918:
1918 Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. de Groot, & E. Lear. February 1996.
(Format: TXT=22270 bytes)
RFC 1918 documents the allocation of the following addresses for use by
``private internets'':
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
-----------------------------------------------------------------------------
Question 2.16. Does BIND cache negative answers (failed DNS lookups) ?
Date: Mon Jan 2 13:55:50 EST 1995
Yes, BIND 4.9.3 and more recent versions will cache negative answers.
-----------------------------------------------------------------------------
Question 2.17. What does an NS record really do ?
Date: Wed Sep 4 22:52:18 EDT 1996
The NS records in your zone data file pointing to the zone's name servers
(as opposed to the servers of delegated subdomains) don't do much.
They're essentially unused, though they are returned in the authority
section of reply packets from your name servers.
However, the NS records in the zone file of the parent domain are used to
find the right servers to query for the zone in question. These records
are more important than the records in the zone itself.
-----------------------------------------------------------------------------
Question 2.18. DNS ports
Date: Fri Feb 10 15:40:10 EST 1995
The following table shows what TCP/UDP ports DNS uses to send and receive
queries:
Prot Src Dst Use
udp 53 53 Queries between servers (eg, recursive queries)
Replies to above
tcp 53 53 Queries with long replies between servers, zone
transfers Replies to above
udp >1023 53 Client queries (sendmail, nslookup, etc ...)
udp 53 >1023 Replies to above
tcp >1023 53 Client queries with long replies
tcp 53 >1023 Replies to above
Note: >1023 is for non-priv ports on Un*x clients. On other client
types, the limit may be more or less.
Another point to keep in mind when designing filters for DNS is that a DNS
server uses port 53 both as the source and destination for it's queries.
So, a client queries an initial server from an unreserved port number to
UDP port 53. If the server needs to query another server to get the
required info, it sends a UDP query to that server with both source and
destination ports set to 53. The response is then sent with the same
src=53 dest=53 to the first server which then responds to the original
client from port 53 to the original source port number.
The point of all this is that putting in filters to only allow UDP between
a high port and port 53 will not work correctly, you must also allow the
port 53 to port 53 UDP to get through.
Also, ALL versions of BIND use TCP for queries in some cases. The
original query is tried using UDP. If the response is longer than the
allocated buffer, the resolver will retry the query using a TCP
connection. If you block access to TCP port 53 as suggested above, you
may find that some things don't work.
Newer version of BIND allow you to configure a list of IP addresses from
which to allow zone transfers. This mechanism can be used to prevent
people from outside downloading your entire namespace.
-----------------------------------------------------------------------------
Question 2.19. What is the cache file
Date: Fri Dec 6 01:15:22 EST 1996
From the "Name Server Operations Guide"
6.3. Cache Initialization
6.3.1. root.cache
The name server needs to know the servers that
are the authoritative name servers for the root
domain of the network. To do this we have to prime
the name server's cache with the addresses of these
higher authorities. The location of this file is
specified in the boot file. ...
-----------------------------------------------------------------------------
Question 2.20. Obtaining the latest cache file
Date: Fri Dec 6 01:15:22 EST 1996
If you have a version of dig running, you may obtain the information with
the command
dig @a.root-servers.net. . ns
A perl script to handle some possible problems when using this method
from behind a firewall and that can also be used to periodically obtain
the latest cache file was posted to comp.protocols.tcp-ip.domains during
early October, 1996. It was posted with the subject "Keeping db.cache
current". It is available at
http://www.users.pfmc.net/~cdp/cptd-faq/current_db_cache.txt.
The latest cache file may also be obtained from the InterNIC via ftp or
gopher:
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
-----------------------------------------------------------------------------
Question 2.21. Selecting a nameserver/root cache
Date: Mon Aug 5 22:54:11 EDT 1996
Exactly how is the a root server selected from the root cache? Does the
resolver attempt to pick the closest host or is it random or is it via
sortlist-type workings? If the root server selected is not available (for
whatever reason), will the the query fail instead of attempting another
root server in the list ?
Every recursive BIND name server (that is, one which is willing to go out
and find something for you if you ask it something it doesn't know) will
remember the measured round trip time to each server it sends queries to.
If it has a choice of several servers for some domain (like "." for
example) it will use the one whose measured RTT is lowest.
Since the measured RTT of all NS RRs starts at zero (0), every one gets
tried one time. Once all have responded, all RTT's will be nonzero, and
the "fastest server" will get all queries henceforth, until it slows down
for some reason.
To promote dispersion and good recordkeeping, BIND will penalize the RTT
by a little bit each time a server is reused, and it will penalize the RTT
a _lot_ if it ever has to retransmit a query. For a server to stay "#1",
it has to keep on answering quickly and consistently.
Note that this is something BIND does that the DNS Specification does not
mention at all. So other servers, those not based on BIND, might behave
very differently.
-----------------------------------------------------------------------------
Question 2.22. InterNIC and domain names
Date: Sun Jun 2 11:23:49 EDT 1996
The current InterNIC policy on what to do if someone wants to use a domain
name that is already in use may be found at
rs.internic.net : /policy/internic/internic-domain-4.txt
or
http://rs.internic.net/domain-info/internic-domain-4.html.
The following information was submitted by Carl Oppedahl
<oppedahl@patents.com> :
If the jealous party happens to have a trademark registration, it is quite
likely that the domain name owner will lose the domain name, even if they
aren't infringing the trademark. This presents a substantial risk of loss
of a domain name on only 30 days' notice. Anyone who is the manager of an
Internet-connected site should be aware of this risk and should plan for
it.
See "How do I protect myself from loss of my domain name?" at
http://www.patents.com/weblaw.sht#domloss.
For an example of an ISP's battle to keep its domain name, see
http://www.patents.com/nsi.sht.
A compendium of information on the subject may be found at
http://www.law.georgetown.edu/lc/internic/domain1.html.
===============================================================================
Section 3. UTILITIES
Q3.1 Utilities to administer DNS zone files
Q3.2 DIG - Domain Internet Groper
Q3.3 DNS packet analyser
Q3.4 host
Q3.5 How can I use DNS information in my program?
Q3.6 A source of information relating to DNS
-----------------------------------------------------------------------------
Question 3.1. Utilities to administer DNS zone files
Date: Wed Sep 4 22:53:53 EDT 1996
There are a few utilities available to ease the administration of zone
files in the DNS.
Two common ones are h2n and makezones. Both are perl scripts. h2n is
used to convert host tables into zone data files. It is available for
anonymous ftp from
ftp.uu.net : /published/oreilly/nutshell/dnsbind/dns.tar.Z
makezones works from a single file that looks like a forward zone file,
with some additional syntax for special cases. It is included in the
current BIND distribution. The newest version is always available for
anonymous ftp from
ftp.cus.cam.ac.uk : /pub/software/programs/DNS/makezones
More information may be found using the DNS Resources Directory
http://www.dns.net/dnsrd/.
-----------------------------------------------------------------------------
Question 3.2. DIG - Domain Internet Groper
Date: Thu Dec 1 11:09:11 EST 1994
The latest and greatest, official, accept-no-substitutes version of the
Domain Internet Groper (DiG) is the one that comes with BIND. Get the
latest kit.
-----------------------------------------------------------------------------
Question 3.3. DNS packet analyser
Date: Wed Sep 4 23:43:57 EDT 1996
There is a free ethernet analyser called Ethload available for PC's
running DOS. The latest filename is ETHLD104.ZIP. It understands lots of
protocols including TCP/UDP. It'll look inside there and display
DNS/BOOTP/ICMP packets etc. (Ed. note: something nice for someone to add
to tcpdump ;^) ). Depending on the ethernet controller it's given it'll
perform slightly differently. It handles NDIS/Novell/Packet drivers. It
works best with Novell's promiscuous mode drivers. A SimTel mirror site
should have the program available for anonymous ftp. One is
ftp.coast.net : /SimTel/msdos/lan/ethld104.zip
-----------------------------------------------------------------------------
Question 3.4. host
Date: Sun Dec 4 21:15:38 EST 1994
A section from the host man page:
host looks for information about Internet hosts and domain
names. It gets this information from a set of intercon-
nected servers that are spread across the world. The infor-
mation is stored in the form of "resource records" belonging
to hierarchically organized "zones".
By default, the program simply converts between host names
and Internet addresses. However, with the -t, -a and -v
options, it can be used to find all of the information about
domain names that is maintained by the domain nameserver
system. The information printed consists of various fields
of the associated resource records that were retrieved.
The arguments can be either host names (domain names) or
numeric Internet addresses.
'host' is compatible with both BIND 4.9 and BIND 4.8
'host' may be found in contrib/host in the BIND distribution. The latest
version always available for anonymous ftp from
ftp.nikhef.nl : /pub/network/host.tar.Z
It may also be found for anonymous ftp from
ftp.uu.net : /networking/ip/dns/host.tar.Z
-----------------------------------------------------------------------------
Question 3.5. How can I use DNS information in my program?
Date: Fri Feb 10 15:25:11 EST 1995
It depends on precisely what you want to do:
* Consider whether you need to write a program at all. It may well be
easier to write a shell program (e.g. using awk or perl) to parse the
output of dig, host or nslookup.
* If all you need is names and addresses, there will probably be system
routines 'gethostbyname' and 'gethostbyaddr' to provide this
information.
* If you need more details, then there are system routines (res_query and
res_search) to assist with making and sending DNS queries. However,
these do not include a routine to parse the resulting answer (although
routines to assist in this task are provided). There is a separate
library available that will take a DNS response and unpick it into its
constituent parts, returning a C structure that can be used by the
program. The source for this library is available for anonymous ftp at
hpux.csc.liv.ac.uk : /hpux/Networking/Admin/resparse-1.2
-----------------------------------------------------------------------------
Question 3.6. A source of information relating to DNS
Date: Tue Nov 5 23:42:21 EST 1996
You may find utilities and tools to help you manage your zone files
(including WWW front-ends) in the "tools" section of the DNS resources
directory:
http://www.dns.net/dnsrd/tools.html
There are also a number of IP management tools available. Data
Communications had an article on the subject in Sept/Oct of 1996. The
tools mentioned in the article and a few others may be found at the
following sites:
* IP Address management, http://www.accugraph.com
* IP-Track, http://www.on.com
* NetID, http://www.isotro.com
* QIP, http://www.quadritek.com
* UName-It, http://www.esm.com
===============================================================================
Section 4. DEFINITIONS
Q4.1 TCP/IP Host Naming Conventions
Q4.2 What are slaves and forwarders ?
Q4.3 When is a server authoritative?
Q4.4 My server does not consider itself authoritative !
Q4.5 NS records don't configure servers as authoritative ?
Q4.6 underscore in host-/domainnames
Q4.7 What is lame delegation ?
Q4.8 How can I see if the server is "lame" ?
Q4.9 What does opt-class field in a zone file do?
Q4.10 Top level domains
Q4.11 Classes of networks
Q4.12 What is CIDR ?
Q4.13 What is the rule for glue ?
-----------------------------------------------------------------------------
Question 4.1. TCP/IP Host Naming Conventions
Date: Mon Aug 5 22:49:46 EDT 1996
One guide that may be used when naming hosts is RFC 1178, "Choosing a Name
for Your Computer", which is available via anonymous FTP from
ftp.internic.net : /rfc/rfc1178.txt
RFCs (Request For Comments) are specifications and guidelines for how many
aspects of TCP/IP and the Internet (should) work. Most RFCs are fairly
technical documents, and some have semantics that are hotly contested in
the newsgroups. But a few, like RFC 1178, are actually good to read for
someone who's just starting along a TCP/IP path.
-----------------------------------------------------------------------------
Question 4.2. What are slaves and forwarders ?
Date: Thu Dec 1 10:32:43 EST 1994
"forwarders" is a list of NS records that are _prepended_ to a list of NS
records to query if the data is not available locally. This allows a rich
cache of records to be built up at a centralized location. This is good
for sites that have sporadic or very slow connections to the Internet.
(demand dial-up, for example) It's also just a good idea for very large
distributed sites to increase the chance that you don't have to go off to
the Internet to get an IP address. (sometimes for addresses across the
street!)
"slave" modifies this to say to replace the list of NS records with the
forwarders entry, instead of prepending to it. This is for firewalled
environments, where the nameserver can't directly get out to the Internet
at all.
"slave" is meaningless (and invalid, in late-model BINDs) without
"forwarders". "forwarders" is an entry in named.boot, and therefore
applies only to the nameserver (not to resolvers).
-----------------------------------------------------------------------------
Question 4.3. When is a server authoritative?
Date: Mon Jan 2 13:15:13 EST 1995
In the case of BIND:
* The server contains current data in files for the zone in question (Data
must be current for secondaries, as defined in the SOA)
* The server is told that it is authoritative for the zone, by a 'primary'
or 'secondary' keyword in /etc/named.boot.
* The server does an error-free load of the zone.
-----------------------------------------------------------------------------
Question 4.4. My server does not consider itself authoritative !
Date: Mon Jan 2 13:15:13 EST 1995
The question was:
What if I have set up a DNS where there is an SOA record for
the domain, but the server still does not consider itself
authoritative. (when using nslookup and set server=the correct machine.)
It seems that something is not matching up somewhere. I suspect
that this is because the service provider has not given us control
over the IP numbers in our own domain, and so while the machine listed
has an A record for an address, there is no corresponding PTR record.
With the answer:
That's possible too, but is unrelated to the first question.
You need to be delegated a zone before outside people will start
talking to your server. However, a server can still be authoritative
for a zone even though it hasn't been delegated authority (it's just
that only the people who use that as their server will see the data).
A server may consider itself non-authoritative even though it's a
primary if there is a syntax error in the zone (see the list in the
previous question).
-----------------------------------------------------------------------------
Question 4.5. NS records don't configure servers as authoritative ?
Date: Fri Dec 6 16:13:34 EST 1996
Nope, delegation is a separate issue from authoritativeness. You can
still be authoritative, but not delegated. (you can also be delegated,
but not authoritative -- that's a "lame delegation")
-----------------------------------------------------------------------------
Question 4.6. underscore in host-/domainnames
Date: Mon Aug 5 22:39:02 EDT 1996
The question is "Are underscores are allowed in host- or domainnames" ?
RFC 1033 allows them.
RFC 1035 doesn't.
RFC 1123 doesn't.
dnswalk complains about them.
Which RFC is the final authority these days?
Actually RFC 1035 deals with names of machines or names of mail domains.
i.e "_" is not permitted in a hostname or on the RHS of the "@" in
local@domain.
Underscore is permitted where ever the domain is NOT one of these types
of addresses.
In general the DNS mostly contains hostnames and mail domainnames. This
will change as new resource record types for authenticating DNS queries
start to appear.
The latest version of 'host' checks for illegal characters in A/MX record
names and the NS/MX target names.
After saying all of that, remember that RFC 1123 is a Required Internet
Standard (per RFC 1720), and RFC 1033 isn't. Even RFC 1035 isn't a
required standard. Therefore, RFC 1123 wins, no contest.
From RFC 1123, Section 2.1
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
And described by Dave Barr in RFC1912:
Allowable characters in a label for a host name are only ASCII
letters, digits, and the `-' character. Labels may not be all
numbers, but may have a leading digit (e.g., 3com.com). Labels must
end and begin only with a letter or digit. See [RFC 1035] and [RFC
1123]. (Labels were initially restricted in [RFC 1035] to start with
a letter, and some older hosts still reportedly have problems with
the relaxation in [RFC 1123].) Note there are some Internet
hostnames which violate this rule (411.org, 1776.com).
Finally, one more piece of information (From Paul Vixie):
RFC 1034 says only that domain names have characters in them, though it
says so with enough fancy and indirection that it's hard to tell exactly.
Generally, for second level domains (i.e., something you would get from
InterNIC or from the US Domain Registrar and probably other ISO 3166
country code TLDs), RFC 952 is thought to apply. RFC 952 was about host
names rather than domain names, but the rules seemed good enough.
<domainname> ::= <hname>
<hname> ::= <name>*["."<name>]
<name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
There has been a recent update on this subject which may be found in
ftp.internic.net : /internet-drafts/draft-andrews-dns-hostnames-03.txt.
-----------------------------------------------------------------------------
Question 4.7. What is lame delegation ?
Date: Mon Aug 5 22:45:02 EDT 1996
Two things are required for a lame delegation:
* A nameserver X is delegated as authoritative for a zone.
* Nameserver X is not performing nameservice for that zone.
Try to think of a lame delegation as a long-term condition, brought about
by a misconfiguration somewhere. Bryan Beecher's 1992 LISA paper on lame
delegations is good to read on this. The problem really lies in
misconfigured nameservers, not "lameness" brought about by transient
outages. The latter is common on the Internet and hard to avoid, while
the former is correctable.
In order to be performing nameservice for a zone, it must have (presumed
correct) data for that zone, and it must be answering authoritatively to
resolver queries for that zone. (The AA bit is set in the flags section)
The "classic" lame delegation case is when nameserver X is delegated as
authoritative for domain Y, yet when you ask Y about X, it returns
non-authoritative data.
Here's an example that shows what happens most often (using dig, dnswalk,
and doc to find).
Let's say the domain bogus.com gets registered at the NIC and they have
listed 2 primary name servers, both from their *upstream* provider:
bogus.com IN NS ns.bogus.com
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com
So the root servers have this info. But when the admins at bogus.com
actually set up their zone files they put something like:
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com
So your name server may have the nameserver info cached (which it may have
gotten from the root). The root says "go ask ns.bogus.com" since they are
authoritative
This is usually from stuff being registered at the NIC (either nic.ddn.mil
or rs.internic.net), and then updated later, but the folks who make the
updates later never let the folks at the NIC know about it.
-----------------------------------------------------------------------------
Question 4.8. How can I see if the server is "lame" ?
Date: Mon Aug 5 22:45:02 EDT 1996
Go to the authoritative servers one level up, and ask them who they think
is authoritative, and then go ask each one of those delegees if they think
that they themselves are authoritative. If any responds "no", then you
know who the lame delegation is, and who is delegating lamely to them.
You can then send off a message to the administrators of the level above.
The 'lamers' script from Byran Beecher really takes care of all this for
you. It parses the lame delegation notices from BIND's syslog and
summarizes them for you. It may be found in the contrib section of the
latest BIND distribution. The latest version is available for anonymous
ftp from
terminator.cc.umich.edu : /dns/lame-delegations/
If you want to actively check for lame delegations, you can use 'doc'
and 'dnswalk'. You can check things manually with 'dig'.
The InterNIC recently announced a new lame delegation that will be in
effect on 01 October, 1996. Here is a summary:
* After receipt/processing of a name registration template, and at random
intervals thereafter, the InterNIC will perform a DNS query via UDP
Port 53 on domain names for an SOA response for the name being
registered.
* If the query of the domain name returns a non-authoritative response
from all the listed name servers, the query will be repeated four times
over the next 30 days at random intervals approximately 7 days apart,
with notification to all listed whois and nameserver contacts of the
possible pending deletion. If at least one server answers correctly,
but one or more are lame, FYI notifications will be sent to all contacts
and checking will be discontinued. Additionally, e-mail notices will be
provided to the contact for the name servers holding the delegation to
alert them to the "lame" condition. Notifications will state explicitly
the consequences of not correcting the "lame" condition and will be
assigned a descriptive subject as follows:
Subject: Lame Delegation Notice: DOMAIN_NAME
The notification will include a timestamp for when the query was
performed.
* If, following 30 days, the name servers still provide no SOA response,
the name will be placed in a "hold" status and the DNS information will
no longer be propagated. The administrative contact will be notified by
postal mail and all whois contacts will be notified by e-mail, with
instructions for taking corrective action.
* Following 60 days in a "hold" status, the name will be deleted and made
available for reregistration. Notification of the final deletion will
be sent to the name server and domain name contacts listed in the NIC
database.
-----------------------------------------------------------------------------
Question 4.9. What does opt-class field in a zone file do?
Date: Thu Dec 1 11:10:39 EST 1994
This field is the address class. From the BOG -
...is the address class; currently, only one class
is supported: IN for internet addresses and other
internet information. Limited support is included for
the HS class, which is for MIT/Athena ``Hesiod''
information.
-----------------------------------------------------------------------------
Question 4.10. Top level domains
Date: Fri Dec 6 15:13:35 EST 1996
A section from RFC 1591:
2. The Top Level Structure of the Domain Names
In the Domain Name System (DNS) naming of computers there is a
hierarchy of names. The root of system is unnamed. There are a set
of what are called "top-level domain names" (TLDs). These are the
generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
letter country codes from ISO-3166. It is extremely unlikely that
any other TLDs will be created.
-----
[ Ed note: the ISO-3166 country codes may be found for anonymous ftp
from:
* ftp.isi.edu : /in-notes/iana/assignments/country-codes
* ftp.ripe.net : /iso3166-codes
]
[ Ed note: Since the Internic started charging for registration services,
(and for other reasons) there are a number of groups that want to offer
an alternative to registering a domain under a "standard" TLD. More
information on some of these options may be found at:
* http://www.alternic.net/
* http://www.eu.org/
* http://www.ml.org/mljoin.html
You may participate in one of the discussions on iTLD proposals at
* To sign up: http://www.newdom.com/lists
* Old postings: http://www.newdom.com/archive
]
-----
...
Under each TLD may be created a hierarchy of names. Generally, under
the generic TLDs the structure is very flat. That is, many
organizations are registered directly under the TLD, and any further
structure is up to the individual organizations.
In the country TLDs, there is a wide variation in the structure, in
some countries the structure is very flat, in others there is
substantial structural organization. In some country domains the
second levels are generic categories (such as, AC, CO, GO, and RE),
in others they are based on political geography, and in still others,
organization names are listed directly under the country code. The
organization for the US country domain is described in RFC 1480.
Each of the generic TLDs was created for a general category of
organizations. The country code domains (for example, FR, NL, KR,
US) are each organized by an administrator for that country. These
administrators may further delegate the management of portions of the
naming tree. These administrators are performing a public service on
behalf of the Internet community. Descriptions of the generic
domains and the US country domain follow.
Of these generic domains, five are international in nature, and two
are restricted to use by entities in the United States.
World Wide Generic Domains:
COM - This domain is intended for commercial entities, that is
companies. This domain has grown very large and there is
concern about the administrative load and system performance if
the current growth pattern is continued. Consideration is
being taken to subdivide the COM domain and only allow future
commercial registrations in the subdomains.
EDU - This domain was originally intended for all educational
institutions. Many Universities, colleges, schools,
educational service organizations, and educational consortia
have registered here. More recently a decision has been taken
to limit further registrations to 4 year colleges and
universities. Schools and 2-year colleges will be registered
in the country domains (see US Domain, especially K12 and CC,
below).
NET - This domain is intended to hold only the computers of network
providers, that is the NIC and NOC computers, the
administrative computers, and the network node computers. The
customers of the network provider would have domain names of
their own (not in the NET TLD).
ORG - This domain is intended as the miscellaneous TLD for
organizations that didn't fit anywhere else. Some non-
government organizations may fit here.
INT - This domain is for organizations established by international
treaties, or international databases.
United States Only Generic Domains:
GOV - This domain was originally intended for any kind of government
office or agency. More recently a decision was taken to
register only agencies of the US Federal government in this
domain. State and local agencies are registered in the country
domains (see US Domain, below).
MIL - This domain is used by the US military.
Example country code Domain:
US - As an example of a country domain, the US domain provides for
the registration of all kinds of entities in the United States
on the basis of political geography, that is, a hierarchy of
<entity-name>.<locality>.<state-code>.US. For example,
"IBM.Armonk.NY.US". In addition, branches of the US domain are
provided within each state for schools (K12), community
colleges (CC), technical schools (TEC), state government
agencies (STATE), councils of governments (COG),libraries
(LIB), museums (MUS), and several other generic types of
entities (see RFC 1480 for details).
A section from RFC 1480:
2. NAMING STRUCTURE
The US Domain hierarchy is based on political geography. The
basic name space under US is the state name space, then the
"locality" name space, (like a city, or county) then
organization or computer name and so on.
For example:
BERKELEY.CA.US
PORTLAND.WA.US
There is of course no problem with running out of names.
The things that are named are individual computers.
If you register now in one city and then move, the database can
be updated with a new name in your new city, and a pointer can
be set up from your old name to your new name. This type of
pointer is called a CNAME record.
The use of unregistered names is not effective and causes problems
for other users. Inventing your own name and using it without
registering is not a good idea.
In addition to strictly geographically names, some special names
are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC,
CITY, and COUNTY. Several new name spaces have been created,
DNI, GEN, and TEC, and a minor change under the "locality" name
space was made to the existing CITY and COUNTY subdomains by
abbreviating them to CI and CO. A detailed description
follows.
Below US, Parallel to States:
-----------------------------
"FED" - This branch may be used for agencies of the federal
government. For example: <org-name>.<city>.FED.US
"DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was
created directly under the top-level US. This branch is to be used
for distributed national institutes; organizations that span state,
regional, and other organizational boundaries; that are national in
scope, and have distributed facilities. For example:
<org-name>.DNI.US.
Name Space Within States:
------------------------
"locality" - cities, counties, parishes, and townships. Subdomains
under the "locality" would be like CI.<city>.<state>.US,
CO.<county>.<state>.US, or businesses. For example:
Petville.Marvista.CA.US.
"CI" - This branch is used for city government agencies and is a
subdomain under the "locality" name (like Los Angeles). For example:
Fire-Dept.CI.Los-Angeles.CA.US.
"CO" - This branch is used for county government agencies and is a
subdomain under the "locality" name (like Los Angeles). For example:
Fire-Dept.CO.San-Diego.CA.US.
"K12" - This branch may be used for public school districts. A
special name "PVT" can be used in the place of a school district name
for private schools. For example: <school-name>.K12.<state>.US and
<school-name>.PVT.K12.<state>.US.
"CC" - COMMUNITY COLLEGES - This branch was established for all state
wide community colleges. For example: <school-name>.CC.<state>.US.
"TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was
established for technical and vocational schools and colleges. For
example: <school-name>.TEC.<state>.US.
"LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may
be used for libraries only. For example: <lib-name>.LIB.<state>.US.
"STATE" - This branch may be used for state government agencies. For
example: <org-name>.STATE.<state>.US.
"GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things
that don't fit easily into any other structure listed -- things that
might fit in to something like ORG at the top-level. It is best not
to use the same keywords (ORG, EDU, COM, etc.) that are used at the
top-level to avoid confusion. GEN would be used for such things as,
state-wide organizations, clubs, or domain parks. For example:
<org-name>.GEN.<state-code>.US.
The application form for the US domain may be found:
* for anonymous ftp from internic.net : /templates/us-domain-template.txt
* http://www.isi.edu/us-domain/
The application form for the EDU, COM, NET, ORG, and GOV domains may be
found for anonymous ftp from:
internic.net : /templates/domain-template.txt
-----------------------------------------------------------------------------
Question 4.11. Classes of networks
Date: Wed Sep 4 22:59:27 EDT 1996
The usage of 'classes of networks' (class A, B, C) are historical and have
been replaced by CIDR blocks on the Internet. That being said...
An Internet Protocol (IP) address is 32 bit in length, divided into two
or three parts (the network address, the subnet address (if present), and
the host address. The subnet addresses are only present if the network
has been divided into subnetworks. The length of the network, subnet, and
host field are all variable.
There are five different network classes. The leftmost bits indicate the
class of the network.
# of # of
bits in bits in
network host
Class field field Internet Protocol address in binary Ranges
============================================================================
A 7 24 0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH 1-127.x.x.x
B 14 16 10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH 128-191.x.x.x
C 22 8 110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH 192-223.x.x.x
D NOTE 1 1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 224-239.x.x.x
E NOTE 2 11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 240-247.x.x.x
where N represents part of the network address and H represents part of
the host address. When the subnet address is defined, the needed bits
are assigned from the host address space.
NOTE 1: Reserved for multicast groups - RFC 1112
NOTE 2: Reserved for future use
127.0.0.1 is reserved for local loopback.
-----------------------------------------------------------------------------
Question 4.12. What is CIDR ?
Date: Tue Nov 5 23:47:29 EST 1996
CIDR is "Classless Inter-Domain Routing (CIDR). From RFC 1517:
...Classless Inter-Domain Routing (CIDR) attempts to deal with
these problems by defining a mechanism to slow the growth of
routing tables and reduce the need to allocate new IP network
numbers.
Much more information may be obtained in RFCs 1467, 1517, 1518, 1520;
with primary reference 1519.
Also please see the CIDR FAQ at
* http://www.ibm.net.il/~hank/cidr.html
* http://www.rain.net/faqs/cidr.faq.html
* http://www.lab.unisource.ch/services/internet/direct/cidr.html
-----------------------------------------------------------------------------
Question 4.13. What is the rule for glue ?
Date: Fri Apr 28 13:31:24 EDT 1995
A glue record is an A record for a name that appears on the right-hand
side of a NS record. So, if you have this:
sub.foobar.com. IN NS dns.sub.foobar.com.
dns.sub.foobar.com. IN A 1.2.3.4
then the second record is a glue record (for the NS record above it).
You need glue records when -- and only when -- you are delegating
authority to a nameserver that "lives" in the domain you are delegating
*and* you aren't a secondary server for that domain.
In other words, in the example above, you need to add an A record for
dns.sub.foobar.com since it "lives" in the domain it serves. This boot
strapping information is necessary: How are you supposed to find out the
IP address of the nameserver for domain FOO if the nameserver for FOO
"lives" in FOO?
If you have this NS record:
sub.foobar.com. IN NS dns.xyz123.com.
you do NOT need a glue record, and, in fact, adding one is a very bad
idea. If you add one, and then the folks at xyz123.com change the
address, then you will be passing out incorrect data.
Also, unless you actually have a machine called something.IN-ADDR.ARPA,
you will never have any glue records present in any of your "reverse"
files.
There is also a sort of implicit glue record that can be useful (or
confusing :^) ). If the parent server (abc.foobar.com domain in example
above) is a secondary server for the child, then the A record will be
fetched from the child server when the zone transfer is done. The glue is
still there but it's a little different, it's in the ip address in the
named.boot line instead of explicitly in the data. In this case you can
leave out the explicit glue A record and leave the manually configured
"glue" in just the one place in the named.boot file.
RFC 1537 says it quite nicely:
2. Glue records
Quite often, people put unnecessary glue (A) records in their
zone files. Even worse is that I've even seen *wrong* glue records
for an external host in a primary zone file! Glue records need only
be in a zone file if the server host is within the zone and there
is no A record for that host elsewhere in the zone file.
Old BIND versions ("native" 4.8.3 and older versions) showed the
problem that wrong glue records could enter secondary servers in
a zone transfer.
The remainder of the FAQ is in the next part (Part 2 of 2).
|