This file is indexed.

/usr/share/doc/HOWTO/de-html/DE-DNS-HOWTO-4.html is in doc-linux-de 2003.10-5.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.65">
 <TITLE>DNS HOWTO: Eine »einfache« Domain       </TITLE>
 <LINK HREF="DE-DNS-HOWTO-5.html" REL=next>
 <LINK HREF="DE-DNS-HOWTO-3.html" REL=previous>
 <LINK HREF="DE-DNS-HOWTO.html#toc4" REL=contents>
</HEAD>
<BODY>
<A HREF="DE-DNS-HOWTO-5.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-DNS-HOWTO-3.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-DNS-HOWTO.html#toc4"><IMG SRC="toc.png" ALT="Inhalt"></A>
<HR>
<H2><A NAME="DE-DNS-HOWTO-simple"></A> <A NAME="s4">4.</A> <A HREF="DE-DNS-HOWTO.html#toc4">Eine »einfache« Domain       </A></H2>


<P>Dieser Abschnitt beschreibt, wie man seine eigene Domain 
einrichtet.</P>

<H2><A NAME="ss4.1">4.1</A> <A HREF="DE-DNS-HOWTO.html#toc4.1">Aber zuerst etwas trockene Theorie</A>
</H2>

<P>Bevor es <EM>wirklich</EM> mit diesem Abschnitt losgehen kann, soll anhand
eines Beispiels ein wenig auf die theoretische Funktionsweise des DNS
eingegangen werden. Diese wichtigen und interessanten Informationen sollten
auf jeden Fall gelesen werden. Wer nicht alles lesen m&ouml;chte, kann es
wenigstens einmal &uuml;berfliegen - bis zu der Beschreibung des Inhalts der
<CODE>named.conf</CODE>-Datei.</P>

<P>Das DNS ist ein hierarchisches System, in der Form eines Baumes. Die
Spitze wird als »<CODE>.</CODE>« geschrieben und wird »root« (Wurzel) genannt. Unter
dem »<CODE>.</CODE>« existieren einige Top Level Domains (TLDs) - die bekanntesten
sind <CODE>ORG</CODE>, <CODE>COM</CODE>, <CODE>EDU</CODE>, <CODE>NET</CODE> und nat&uuml;rlich <CODE>DE</CODE> - es gibt
aber noch viele mehr. Wie bei einem Baum gibt es neben der Wurzel auch &Auml;ste.
Jeder, der sich etwas in den Computerwissenschaften auskennt, erkennt im DNS
einen Suchbaum, an dem sich Knoten, Verzweigungen und mehr befinden.</P>

<P>Wenn nach einem Computernamen gesucht wird, taucht die Abfrage an der
Spitze rekursiv nach unten wandernd in die Hierarchie ein. Wenn man die
Adresse von <CODE>prep.ai.mit.edu</CODE> herausfinden will, muss der Nameserver erst
einmal herausfinden, welcher Nameserver f&uuml;r die Domain <CODE>edu</CODE> zust&auml;ndig
ist. Dazu befragt er einen <CODE>.</CODE>-Server, den er dank der
<CODE>root.hints</CODE>-Datei kennt. Der root-Server listet dann die Server f&uuml;r
<CODE>edu</CODE> auf:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nslookup
Default Server:  localhost
Address:  127.0.0.1
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Am Anfang wird ein root-Server befragt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> server c.root-servers.net.
Default Server:  c.root-servers.net
Address:  192.33.4.12
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Hierzu wird die Abfrageart auf NS gesetzt (Nameserver-Eintr&auml;ge):</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> set q=ns
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Nach <CODE>edu</CODE> fragen:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> edu.
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Der abschliessende ».« dieser Anfrage ist sehr wichtig. <CODE>nslookup</CODE> wei&szlig;
dadurch, dass <CODE>edu</CODE> direkt unter der Wurzel zu finden ist (und nicht
unter irgendeiner <CODE>search</CODE>-Domain. So wird die Abfrage beschleunigt).</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
edu     nameserver = A.ROOT-SERVERS.NET
edu     nameserver = H.ROOT-SERVERS.NET
edu     nameserver = B.ROOT-SERVERS.NET
edu     nameserver = C.ROOT-SERVERS.NET
edu     nameserver = D.ROOT-SERVERS.NET
edu     nameserver = E.ROOT-SERVERS.NET
edu     nameserver = I.ROOT-SERVERS.NET
edu     nameserver = F.ROOT-SERVERS.NET
edu     nameserver = G.ROOT-SERVERS.NET
A.ROOT-SERVERS.NET      internet address = 198.41.0.4
H.ROOT-SERVERS.NET      internet address = 128.63.2.53
B.ROOT-SERVERS.NET      internet address = 128.9.0.107
C.ROOT-SERVERS.NET      internet address = 192.33.4.12
D.ROOT-SERVERS.NET      internet address = 128.8.10.90
E.ROOT-SERVERS.NET      internet address = 192.203.230.10
I.ROOT-SERVERS.NET      internet address = 192.36.148.17
F.ROOT-SERVERS.NET      internet address = 192.5.5.241
G.ROOT-SERVERS.NET      internet address = 192.112.36.4
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Diese Auflistung bedeutet, dass alle <CODE>ROOT-SERVERS.NET</CODE>-Server f&uuml;r
<CODE>EDU.</CODE> zust&auml;ndig sind, also kann einer von denen befragt werden. Wir
fragen bereits den <CODE>C</CODE>-Root-Nameserver. Dann kann die n&auml;chste Ebene des
Domainnamens herausgefunden werden: <CODE>mit.edu</CODE>:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> mit.edu.
Server:  c.root-servers.net
Address:  192.33.4.12

Non-authoritative answer:
mit.edu nameserver = W20NS.mit.edu
mit.edu nameserver = BITSY.mit.edu
mit.edu nameserver = STRAWB.mit.edu

Authoritative answers can be found from:
W20NS.mit.edu   internet address = 18.70.0.160
BITSY.mit.edu   internet address = 18.72.0.3
STRAWB.mit.edu  internet address = 18.71.0.151
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P><CODE>strawb</CODE>, <CODE>w20ns</CODE> und <CODE>bitsy</CODE> sind alle f&uuml;r <CODE>mit.edu</CODE> zust&auml;ndig.
Einer davon wird ausgew&auml;hlt und es geht eine Ebene tiefer: <CODE>ai.mit.edu</CODE>:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> server W20NS.mit.edu.
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Die Gross-/Kleinschrift ist bei Rechnernamen unwichtig, aber da ich die Daten
per Maus kopiere und hier einf&uuml;ge, sieht die Ausgabe genau wie auf dem
Bildschirm aus.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
Server:  W20NS.mit.edu
Address:  18.70.0.160

> ai.mit.edu.
Server:  W20NS.mit.edu
Address:  18.70.0.160

Non-authoritative answer:
ai.mit.edu      nameserver = ALPHA-BITS.AI.MIT.EDU
ai.mit.edu      nameserver = GRAPE-NUTS.AI.MIT.EDU
ai.mit.edu      nameserver = TRIX.AI.MIT.EDU
ai.mit.edu      nameserver = MUESLI.AI.MIT.EDU
ai.mit.edu      nameserver = LIFE.AI.MIT.EDU
ai.mit.edu      nameserver = BEET-CHEX.AI.MIT.EDU
ai.mit.edu      nameserver = MINI-WHEATS.AI.MIT.EDU
ai.mit.edu      nameserver = COUNT-CHOCULA.AI.MIT.EDU
ai.mit.edu      nameserver = MINTAKA.LCS.MIT.EDU

Authoritative answers can be found from:
AI.MIT.EDU      nameserver = ALPHA-BITS.AI.MIT.EDU
AI.MIT.EDU      nameserver = GRAPE-NUTS.AI.MIT.EDU
AI.MIT.EDU      nameserver = TRIX.AI.MIT.EDU
AI.MIT.EDU      nameserver = MUESLI.AI.MIT.EDU
AI.MIT.EDU      nameserver = LIFE.AI.MIT.EDU
AI.MIT.EDU      nameserver = BEET-CHEX.AI.MIT.EDU
AI.MIT.EDU      nameserver = MINI-WHEATS.AI.MIT.EDU
AI.MIT.EDU      nameserver = COUNT-CHOCULA.AI.MIT.EDU
AI.MIT.EDU      nameserver = MINTAKA.LCS.MIT.EDU
ALPHA-BITS.AI.MIT.EDU   internet address = 128.52.32.5
GRAPE-NUTS.AI.MIT.EDU   internet address = 128.52.36.4
TRIX.AI.MIT.EDU internet address = 128.52.37.6
MUESLI.AI.MIT.EDU       internet address = 128.52.39.7
LIFE.AI.MIT.EDU internet address = 128.52.32.80
BEET-CHEX.AI.MIT.EDU    internet address = 128.52.32.22
MINI-WHEATS.AI.MIT.EDU  internet address = 128.52.54.11
COUNT-CHOCULA.AI.MIT.EDU        internet address = 128.52.38.22
MINTAKA.LCS.MIT.EDU     internet address = 18.26.0.36
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Also ist <CODE>museli.ai.mit.edu</CODE> ein Nameserver f&uuml;r <CODE>ai.mit.edu</CODE>:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> server MUESLI.AI.MIT.EDU
Default Server:  MUESLI.AI.MIT.EDU
Address:  128.52.39.7
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Jetzt wird der Typ der Anfrage gewechselt. Der Nameserver wurde gefunden,
also wird <CODE>muesli</CODE> gefragt, was er alles &uuml;ber <CODE>prep.ai.mit.edu</CODE>
weiss.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> set q=any
> prep.ai.mit.edu.
Server:  MUESLI.AI.MIT.EDU
Address:  128.52.39.7

prep.ai.mit.edu CPU = dec/decstation-5000.25    OS = unix
prep.ai.mit.edu
        inet address = 18.159.0.42, protocol = tcp
          ftp  telnet  smtp  finger
prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
prep.ai.mit.edu internet address = 18.159.0.42
ai.mit.edu      nameserver = beet-chex.ai.mit.edu
ai.mit.edu      nameserver = alpha-bits.ai.mit.edu
ai.mit.edu      nameserver = mini-wheats.ai.mit.edu
ai.mit.edu      nameserver = trix.ai.mit.edu
ai.mit.edu      nameserver = muesli.ai.mit.edu
ai.mit.edu      nameserver = count-chocula.ai.mit.edu
ai.mit.edu      nameserver = mintaka.lcs.mit.edu
ai.mit.edu      nameserver = life.ai.mit.edu
gnu-life.ai.mit.edu     internet address = 128.52.32.60
beet-chex.ai.mit.edu    internet address = 128.52.32.22
alpha-bits.ai.mit.edu   internet address = 128.52.32.5
mini-wheats.ai.mit.edu  internet address = 128.52.54.11
trix.ai.mit.edu internet address = 128.52.37.6
muesli.ai.mit.edu       internet address = 128.52.39.7
count-chocula.ai.mit.edu        internet address = 128.52.38.22
mintaka.lcs.mit.edu     internet address = 18.26.0.36
life.ai.mit.edu internet address = 128.52.32.80
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Angefangen bei »<CODE>.</CODE>« wurden so der Reihe nach die Nameserver f&uuml;r jede
einzelne Ebene des Domainnamens gefunden. Wenn hierzu anstelle der vielen
einzelnen Nameserver nur der eigene Nameserver benutzt worden w&auml;re, h&auml;tte
dieser nat&uuml;rlich alle Informationen zwischengespeichert, die auf der Suche
nach dem Rechnernamen aufgetaucht w&auml;ren; so br&auml;uchte er f&uuml;r eine Weile
nicht mehr im Netz nachfragen.</P>

<P>Analog zu der Baumstruktur ist jeder »<CODE>.</CODE>« im Rechnername eine
Verzweigung. Jeder Teil zwischen zwei Punkten ist der Name eines Astes im
Baum. </P>

<P>Man »klettert« auf den Baum, indem man den Rechnernamen nimmt
(<CODE>prep.ai.mit.edu</CODE>) und bei der Wurzel (<CODE>.</CODE>) beginnend die Zweige
hinabsteigt. Der n&auml;chste Zweig in diesem Beispiel w&auml;re <CODE>edu</CODE>. Die n&auml;chste
Ebene erreicht man durch das Umschalten zu dem Nameserver, der diesen Teil
des Namens kennt. Als n&auml;chstes folgt der <CODE>mit</CODE>-Zweig, der an den
<CODE>edu</CODE>-Zweig ankn&uuml;pft (zusammen ergibt das <CODE>mit.edu</CODE>) und besteigt
diesen Zweig wiederum durch Umschalten zu dem Server der die Informationen
f&uuml;r <CODE>mit.edu</CODE> bereitstellt. Der n&auml;chste Zweig lautet <CODE>ai.mit.edu</CODE> und
erneut wird der Server gewechselt. Jetzt wurde der richtige Server an der
richtigen Abzweigung erreicht. Die letzte Aufgabe ist die Abfrage der
Informationen zu <CODE>prep.ai.mit.edu</CODE> - ziemlich einfach, oder?</P>

<P>Eine Domain, &uuml;ber die wenig gesprochen wird, die aber mindestens genauso
wichtig wie alle anderen ist, ist <CODE>in-addr.arpa</CODE>. Sie ist wie die
»normalen« Domains aufgebaut und erlaubt es uns, den Rechnernamen
herauszufinden, wenn nur die IP-Adresse bekannt ist. Eine wichtige Eigenheit
muss man allerdings kennen: Die IP-Adressen werden in der
<CODE>in-addr.arpa</CODE>-Domain verkehrt herum aufgelistet. Wenn man die IP-Adresse
<CODE>192.128.52.43</CODE> hat, arbeitete der named genauso wie im
<CODE>prep.ai.mit.edu</CODE>-Beispiel: Er sucht nach den <CODE>arpa.</CODE>-Servern und dann
nach <CODE>in-addr.arpa.</CODE>-Servern, <CODE>192.in-addr.arpa.</CODE>-Servern,
<CODE>128.192.in-addr.arpa.</CODE>-Servern und nach <CODE>52.128.192.in-addr.arpa.</CODE>
Servern.  Letztendlich findet er dann die Eintr&auml;ge f&uuml;r
<CODE>43.52.128.192.in-addr.arpa.</CODE> Clever, oder? Die Antwort sollte »ja«
lauten ;-). Trotzdem wird diese Umkehrung der IP-Nummern jahrelang f&uuml;r
Verwirrung sorgen.</P>

<P>Ich habe gerade ein wenig geflunkert. Das DNS arbeitet nicht so wie ich
es gerade erkl&auml;rt habe. Aber die Beschreibung ist nahe genug an der
Wahrheit.</P>

<H2><A NAME="ss4.2">4.2</A> <A HREF="DE-DNS-HOWTO.html#toc4.2">Die eigene Domain</A>
</H2>

<P>Um eine eigene Domain zu erstellen, wird in dieser HOWTO als Beispiel der
Domainname <CODE>linux.test</CODE> benutzt. Einzelne Rechner werden zu dieser Domain
hinzugef&uuml;gt. Es wird eine »test«-TLD benutzt, um sicherzustellen, dass
niemand »da draussen« durch diese Domain gest&ouml;rt wird.</P>

<P>Eins noch, bevor es losgeht: Es sind nicht alle Zeichen in einem
Rechnernamen erlaubt. Diese Einschr&auml;nkung beinhaltet, dass nur die
Buchstaben des englischen Alphabets benutzt werden d&uuml;rfen: a-z, Ziffern
(0-9) und der Bindestrich (»-«). Nochmal, es sollten und d&uuml;rfen keine
anderen Zeichen benutzt werden. Im DNS gibt es keinen Unterschied zwischen
Groos- und Kleinbuchstaben - <CODE>pat.uio.no</CODE> is identisch mit
<CODE>Pat.UiO.No</CODE>.</P>

<P>Die erste wichtige Einstellung wurde bereits durch die folgende Zeile in
der <CODE>named.conf</CODE> gemacht:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Zu beachten ist, dass der »<CODE>.</CODE>« am Ende der Domainnamen in dieser
Datei fehlt. Die Einstellungen definieren die Zone
<CODE>0.0.127.in-addr.arpa</CODE>, dass unser Server der Haupt-(Master)Server daf&uuml;r
ist und dass die Daten in einer Datei mit dem Namen <CODE>pz/127.0.0</CODE>
gespeichert werden. Auch diese Datei existiert bereits:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
@       IN    SOA     ns.linux.test. hostmaster.linux.test. (
                      1       ; Serial
                      8H      ; Refresh
                      2H      ; Retry
                      1W      ; Expire
                      1D)     ; Minimum TTL
                      NS      ns.linux.test.
1                     PTR     localhost.
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Wichtig ist der »<CODE>.</CODE>« am Ende von jedem kompletten Domainnamen in
dieser Datei - im Gegensatz zu der <CODE>named.conf</CODE>-Datei von oben. Es gibt
Leute, die jede Zonendatei mit einem <CODE>$ORIGIN</CODE>-Statement beginnen,
aber das ist &uuml;berfl&uuml;ssig. Der Ursprung (origin) einer Zonendatei (der Punkt
an dem sich die Domain in der DNS-Hierarchie befindet) wird durch den
Zonen-Abschnitt in der <CODE>named.conf</CODE>-Datei definiert. In diesem Fall ist
das <CODE>0.0.127.in-addr.arpa</CODE>.</P>
<P>Die gerade erstellte Zonen-Datei enth&auml;lt 3 Eintragungen (»resource records«
(RRs)). Einen NS RR und einen PTR RR. SOA ist die Ab&uuml;rzung f&uuml;r »Start Of
Authority«. Der Klammeraffe »@« ist ein spezielles Zeichen und steht f&uuml;r den
Ursprung dieser Domain. Die »domain«-Zeile f&uuml;r diese Datei definiert den
Ursprung als 0.0.127.in-addr.arpa, also steht in der ersten Zeile
ausgeschrieben:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa.   IN      SOA ...
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>NS ist der Name-Server RR. Am Anfang der Zeile fehlt das »@«. Man kann
sich diese »Tipparbeit« sparen, weil bereits die vorhergehende Zeile mit »@«
anfing. Die NS-Zeile k&ouml;nnte also auch so geschrieben werden:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa.   IN      NS      ns.linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Hierdurch erf&auml;rt das DNS den Rechner, der als Nameserver f&uuml;r die Domain
<CODE>0.0.127.in-addr.arpa</CODE> fungiert: <CODE>ns.linux.test</CODE>. »ns« ist der &uuml;bliche
Name f&uuml;r einen Nameserver - genauso wie Web-Server normalerweise
<CODE>www.</CODE><EM>irgendetwas</EM> heissen. Trotzdem kann nat&uuml;rlich auch jeder
beliebige andere Name benutzt werden.</P>

<P>Als letzter Eintrag bedeutet die PTR-Zeile, dass der Rechner mit der
Adresse 1 im Subnetz <CODE>0.0.127.in-addr.arpa</CODE> (also 127.0.0.1)
<CODE>localhost</CODE> heisst.</P>

<P>Der SOA-Eintrag steht am Anfang von <EM>jeder</EM> Zonendatei. Ihn sollte es
in jeder Datei nur ein einziges mal geben. Dieser Eintrag beschreibt die
Ursprungszone (<CODE>linux.test</CODE>), wer f&uuml;r den Inhalt der Domaindaten dieser
Zone verantwortlich ist (<CODE>hostmaster@linux.test</CODE>) - man sollte hier seine
eigene E-Mail-Adresse einf&uuml;gen oder besser den &uuml;blichen Alias »hostmaster«
erzeugen. Ausserdem ist die Versionsnummer dieser Zonendatei enthalten
(Seriennummer: 1) und diverse weitere Einstellungen, die mit dem Caching und
Secondary (Zweit-)Nameservern zu tun haben. Wenn die Einstellungen der
Felder (refresh, retry, expire und minimum) aus der HOWTO &uuml;bernommen werden,
sollte man auf der sicheren Seite sein.</P>

<P>Jetzt wird der named neu gestartet (der Befehl hierf&uuml;r ist <CODE>ndc
restart</CODE>) und die Einstellungen werden mit <CODE>nslookup</CODE> kontrolliert:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nslookup

Default Server:  localhost
Address:  127.0.0.1

> 127.0.0.1
Server:  localhost
Address:  127.0.0.1

Name:    localhost
Address:  127.0.0.1
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Also ist <CODE>nslookup</CODE> in der Lage, den Namen <CODE>localhost</CODE> 
mit der IP-Adresse 127.0.0.1 herauszufinden - hervorragend.</P>

<P>Um jetzt zur&uuml;ck zur Hauptsache - der <CODE>linux.test</CODE>-Domain zu kommen,
wird ein neuer »Zonen«-Abschnitt in die <CODE>named.conf</CODE> eingef&uuml;gt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
zone "linux.test" {
        notify no;
        type master;
        file "pz/linux.test";
};
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Am Ende des Domainnamens in der <CODE>named.conf</CODE>-Datei wird kein
»<CODE>.</CODE>« geschrieben.</P>

<P>In die <CODE>linux.test</CODE>-Zonendatei werden jetzt irgendwelche Testdaten
eingef&uuml;gt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
;
; Zonendatei f&uuml;r linux.test
;
; Die komplette Zonendatei
;
@       IN      SOA     ns.linux.test. hostmaster.linux.test. (
                        199802151       ; Datum + Seriennummer #
                        8H              ; refresh, Sekunden
                        2H              ; retry, Sekunden
                        1W              ; expire, Sekunden
                        1D )            ; minimum, 
;
                NS      ns              ; Rechnername des Nameserver
                MX      10 mail.linux.test      ; erster Mailserver
                MX      20 mail.friend.test.    ; zweiter Mailserver
;
localhost       A       127.0.0.1
ns              A       192.168.196.2
mail            A       192.168.196.4
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Zwei Anmerkungen m&uuml;ssen &uuml;ber den SOA-Eintrag gemacht werden.
<CODE>ns.linux.test</CODE> <EM>muss</EM> ein Rechner mit einem g&uuml;ltigen A-Record sein.
Es ist nicht erlaubt, einen CNAME-Eintrag im SOA-Abschnitt zu benutzen. Der
Name muss &uuml;brigens nicht »ns« lauten, es kann auch jeder andere g&uuml;ltige
Rechnername sein. Ausserdem liest sich hostmaster.linux.test als
hostmaster@linux.test - dies sollte ein Alias oder eine Mailbox sein, die
von den DNS-Administratoren regelm&auml;ssig gelesen wird. Alle E-Mails, die sich
auf das DNS beziehen, werden an diese Adresse geschickt. Genauso wie der
Rechnername nicht unbedingt <CODE>ns</CODE> sein muss, kann auch hier eine andere
g&uuml;ltige E-Mail-Adresse benutzt werden, aber oft wird davon ausgegangen,
dass auch die »hostmaster«-Adresse existiert und gelesen wird.</P>

<P>Es gibt in dieser Datei noch einen neuen RR-Typen - den MX oder Mail
eXchanger. Dieser Eintrag liefert Mailservern die Adresse zur&uuml;ck, an die
E-Mails geliefert werden sollen, die nach <CODE>jemandem@linux.test</CODE> geschickt
werden. In diesem Fall nach <CODE>mail.linux.test</CODE> oder <CODE>mail.friend.test</CODE>.
Die Nummer vor den Mail-Eintr&auml;gen ist die Priorit&auml;t, mit der die Mailserver
ausgew&auml;hlt werden. Der RR mit der kleinsten Nummer (10) ist der erste, an den
versucht wird, E-Mails zu schicken. Wenn das nicht klappt, kann die E-Mail an
einen Server mit einer h&ouml;heren Priorit&auml;tsnummer geschickt werden - zum
Beispiel einen Not-Mailserver <CODE>mail.friend.test</CODE>, der hier die Priorit&auml;t
20 hat.</P>

<P>Der named wird mit Hilfe von <CODE>ndc restart</CODE> neu gestartet und die
Ergebnisse werden wie immer mit <CODE>nslookup</CODE> begutachtet:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nslookup
> set q=any
> linux.test
Server:  localhost
Address:  127.0.0.1

linux.test
        origin = ns.linux.test
        mail addr = hostmaster.linux.test
        serial = 199802151
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        minimum ttl = 86400 (1 day)
linux.test     nameserver = ns.linux.test
linux.test     preference = 10, mail exchanger = mail.linux.test.linux.test
linux.test     preference = 20, mail exchanger = mail.friend.test
linux.test     nameserver = ns.linux.test
ns.linux.test  internet address = 192.168.196.2
mail.linux.test        internet address = 192.168.196.4
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Bei genauerer Betrachtung sollte man einen Fehler entdecken. Die Zeile</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.test     preference = 10, mail exchanger = mail.linux.test.linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>ist falsch. Sie sollte </P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.test     preference = 10, mail exchanger = mail.linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>lauten.</P>

<P>Ich habe diesen Fehler mit Absicht eingebaut, um davon zu lernen :-). In
der Zonendatei findet man den Fehler in der Zeile</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                MX      10 mail.linux.test      ; Erster Mailserver
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Es fehlt ein Punkt oder das »linux.test« ist zuviel. Wenn ein Rechnername
in der Zonendatei nicht mit einem Punkt endet, wird die Ursprungszone an den
Namen angeh&auml;ngt. Dadurch entsteht die Verdoppelung
<CODE>linux.test.linux.test</CODE>. Also ist die richtige Schreibweise entweder</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                MX      10 mail.linux.test.     ; Erster Mailserver
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>oder</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                MX      10 mail                 ; Erster Mailserver
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Ich benutze die zweite Variante - es ist weniger Tipparbeit. Es gibt einige
Bind-Experten, denen diese Arbeitsweise nicht gef&auml;llt und andere, die es
ebenso machen. Nochmal: In einer Zonendatei sollte die Domain entweder
ausgeschrieben und mit einem Punkt beendet werden oder sie sollte komplett
weggelassen werden - in diesem Fall wird der Ursprung angeh&auml;ngt.</P>

<P>Ich muss noch einmal betonen, dass in der <CODE>named.conf</CODE>-Datei <EM>kein</EM>
»<CODE>.</CODE>« hinter dem Domainnamen sein darf. Man glaubt garnicht, wie oft ein
Punkt zuviel oder zuwenig Fehler verursacht und die Leute an den Rand des
Wahnsinns bringt.</P>

<P>Und jetzt folgt eine neue Zonendatei mit einigen zus&auml;tzlichen Eintr&auml;gen:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
;
; Zonendatei f&uuml;rlinux.test
;
; die komplette Zonendatei
;
@       IN      SOA     ns.linux.test. hostmaster.linux.test. (
                        199802151       ; aktuelles Datum + Seriennummer
                        8H              ; refresh, Sekunden
                        2H              ; retry, Sekunden
                        1W              ; expire, Sekunden
                        1D )            ; minimum, Sekunden
;
                TXT     "Linux.Test, die DNS-Einf&uuml;hrung"
                NS      ns              ; Rechnername des Nameservers
                NS      ns.friend.test.
                MX      10 mail         ; erster Mailserver
                MX      20 mail.friend.test. ; zweiter Mailserver

localhost       A       127.0.0.1

gw              A       192.168.196.1
                HINFO   "Cisco" "IOS"
                TXT     "Der Router"

ns              A       192.168.196.2
                MX      10 mail
                MX      20 mail.friend.test.
                HINFO   "Pentium" "Linux 2.0"
www             CNAME   ns

donald          A       192.168.196.3
                MX      10 mail
                MX      20 mail.friend.test.
                HINFO   "i486"  "Linux 2.0"
                TXT     "DEK"

mail            A       192.168.196.4
                MX      10 mail
                MX      20 mail.friend.test.
                HINFO   "386sx" "Linux 1.2"

ftp             A       192.168.196.5
                MX      10 mail
                MX      20 mail.friend.test.
                HINFO   "P6" "Linux 2.1.86"
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Es gib hier wieder einige neue RRs: HINFO (Host INFOrmation -
Rechnerinformation) besteht aus zwei Teilen - es geh&ouml;rt zum guten Ton, beide
Teile anzugeben. Der erste Teil ist die Hardare bzw. die CPU des Systems,
der zweite Teil enth&auml;lt den Namen der Software oder des Betriebssystems des
Rechners. Der Rechner mit dem Namen »ns« enth&auml;lt eine Pentium CPU und l&auml;uft
mit Linux 2.0. CNAME (Canonical Name) ist eine M&ouml;glichkeit, einem Rechner
mehrere Namen zuzuweisen. Also ist www ein Alias f&uuml;r ns.</P>

<P>Die Benutzung von CNAME-Eintr&auml;gen ist ein wenig kontrovers. Unter
Ber&uuml;cksichtigung der folgenden Regeln, sollte es keine Probleme geben. MX,
CNAME oder SOA-Eintr&auml;ge d&uuml;rfen <EM>niemals</EM> auf einen CNAME-Eintrag
verweisen, sondern nur auf A-Records. Aus diesem Grund ist das folgende
nicht erlaubt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
blabar          CNAME   www                     ; NEIN!
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Die richtige Variante lautet:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
blabar          CNAME   ns                      ; JA!
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Man kann davon ausgehen, dass ein CNAME kein g&uuml;ltiger Rechnername f&uuml;r
eine E-Mail-Adresse ist: <CODE>webmaster@www.linux.test</CODE> ist nach den obigen
Einstellungen eine ung&uuml;ltige Adresse. Auch wenn ein Test auf dem eigenen
Rechner keine Schwierigkeiten macht, kann man mit Sicherheit erwarten, dass
es immer ein paar Mail-Admins gibt, die diese Regel durchboxen. Ein Weg zur
Vermeidung dieses Problems ist es, nur A-Eintr&auml;ge zu benutzen (und nat&uuml;rlich
andere wie zum Beispiel MX,...):</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
www             A       192.168.196.2
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Eine Handvoll der alten Bind-Magier empfehlen ebenfalls, <EM>niemals</EM>
CNAME zu benutzen. Die Grundsatzdiskussion »warum oder warum nicht« geh&ouml;rt
aber nicht in diese HOWTO.</P>

<P>Was man aber auch sehen kann, ist dass diese HOWTO und viele andere Sites
diese Regeln nicht befolgen.</P>

<P>Die neuen Einstellungen der Bind-Datenbank werden mit <CODE>ndc reload</CODE>
geladen - der named liest daraufhin seine Konfigurationsdateien neu ein.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nslookup
Default Server:  localhost
Address:  127.0.0.1

> ls -d linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Das bewirkt eine Auflistung aller Eintr&auml;ge. Als Ergebnis erh&auml;lt man:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[localhost]
$ORIGIN linux.test.
@                       1D IN SOA       ns hostmaster (
                                        199802151       ; Seriennummer
                                        8H              ; refresh
                                        2H              ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

                        1D IN NS        ns
                        1D IN NS        ns.friend.test.
                        1D IN TXT       "Linux.Test, die DNS-Einfuehrung"
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.test.
gw                      1D IN A         192.168.196.1
                        1D IN HINFO     "Cisco" "IOS"
                        1D IN TXT       "The router"
mail                    1D IN A         192.168.196.4
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.test.
                        1D IN HINFO     "386sx" "Linux 1.0.9"
localhost               1D IN A         127.0.0.1
www                     1D IN CNAME     ns
donald                  1D IN A         192.168.196.3
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.test.
                        1D IN HINFO     "i486" "Linux 1.2"
                        1D IN TXT       "DEK"
ftp                     1D IN A         192.168.196.5
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.test.
                        1D IN HINFO     "P6" "Linux 1.3.59"
ns                      1D IN A         192.168.196.2
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.test.
                        1D IN HINFO     "Pentium" "Linux 1.2"
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Sehr sch&ouml;n - man erkennt sofort die &Auml;hnlichkeit zu der Zonendatei
selbst. Mal sehen, was nur f&uuml;r <CODE>www</CODE> ausgegeben wird:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> set q=any
> www.linux.test.
Server:  localhost
Address:  127.0.0.1

www.linux.test canonical name = ns.linux.test
linux.test     nameserver = ns.linux.test
linux.test     nameserver = ns.friend.test
ns.linux.test  internet address = 192.168.196.2
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>In anderen Worten: Der richtige Name von <CODE>www.linux.test</CODE> ist
<CODE>ns.linux.test</CODE>. Au&szlig;erdem werden zus&auml;tzliche Informationen &uuml;ber ns
ausgegeben - genug um eine Verbindung aufzubauen, wenn man ein Programm
w&auml;re.</P>

<H2><A NAME="ss4.3">4.3</A> <A HREF="DE-DNS-HOWTO.html#toc4.3">Die umgekehrte Zone (Reverse Zone)</A>
</H2>

<P>Jetzt k&ouml;nnen Programme also die Rechnernamen der Domain linux.test in
die f&uuml;r sie n&ouml;tigen IP-Adressen umwandeln. Zus&auml;tzlich wird aber noch eine
Zone ben&ouml;tigt, die die Umwandlung von IP-Adressen in Rechnernamen erm&ouml;gicht
- eine umgekehrte oder »reverse« Zone. Die Rechnernamen werden von vielen
Programmen (z.B. FTP, IRC, WWW und anderen) zur Entscheidung dar&uuml;ber
herangezogen, ob sie mit einem reden wollen oder nicht - und falls sie es
m&ouml;chten, welche Priorit&auml;t man erh&auml;lt. Um vollen Zugang zu allen
Internetdiensten zu bekommen ist eine umgekehrte Zone n&ouml;tig.</P>

<P>Hierzu wird noch etwas in die <CODE>named.conf</CODE> eingef&uuml;gt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
zone "196.168.192.in-addr.arpa" {
        notify no;
        type master;
        file "pz/192.168.196";
};
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Dieser Eintrag ist dem <CODE>0.0.127.in-addr.arpa</CODE>-Eintrag sehr &auml;hnlich -
auch der Inhalt der Zonendatei ist gleich:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
@       IN      SOA     ns.linux.test. hostmaster.linux.test. (
                        199802151 ; Seriennummer, Datum + Seriennnummer
                        8H      ; Refresh
                        2H      ; Retry
                        1W      ; Expire
                        1D)     ; Minimum TTL
                NS      ns.linux.test.

1               PTR     gw.linux.test.
2               PTR     ns.linux.test.
3               PTR     donald.linux.test.
4               PTR     mail.linux.test.
5               PTR     ftp.linux.test.
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Jetzt wird der named neu gestartet (<CODE>ndc restart</CODE>) und die gerade
gemachten Einstellungen werden mit <CODE>nslookup</CODE> &uuml;berpr&uuml;ft:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 192.168.196.4
Server:  localhost
Address:  127.0.0.1

Name:    mail.linux.test
Address:  192.168.196.4
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>So, das sieht OK aus. Jetzt werden nochmal alle Einstellungen ausgegeben
und gecheckt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> ls -d 196.168.192.in-addr.arpa
[localhost]
$ORIGIN 196.168.192.in-addr.arpa.
@                       1D IN SOA       ns.linux.test. hostmaster.linux.test. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

                        1D IN NS        ns.linux.test.
1                       1D IN PTR       gw.linux.test.
2                       1D IN PTR       ns.linux.test.
3                       1D IN PTR       donald.linux.test.
4                       1D IN PTR       mail.linux.test.
5                       1D IN PTR       ftp.linux.test.
@                       1D IN SOA       ns.linux.test. hostmaster.linux.test. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        1W              ; expiry
                                        1D )            ; minimum
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Das sieht sehr gut aus. Wenn die Ausgabe allerdings nicht mit der obigen
&uuml;bereinstimmt, muss man in der syslog-Datei nach Fehlermeldungen suchen.
Wie das gemacht wird, habe ich ganz am Anfang dieses Abschnitts erkl&auml;rt.</P>

<H2><A NAME="ss4.4">4.4</A> <A HREF="DE-DNS-HOWTO.html#toc4.4">Warnungen</A>
</H2>

<P>Es gibt noch ein paar Dinge, die gesagt werden sollten. Die IP-Adressen,
die in den obigen Beispielen benutzt wurden, stammen aus einem der »privaten
Netze«. Sie d&uuml;rfen nicht &ouml;ffentlich im Internet benutzt werden. Darum sind
sie ideal f&uuml;r die Benutzung in einer HOWTO. Der zweite Punkt ist die
<CODE>notify no;</CODE>-Zeile. Sie veranla&szlig;t den named dazu, seine
Zweit-(Secondary)-Server nicht &uuml;ber &Auml;nderungen in den Zonendateien zu
informieren. Denn der Bind Version 8 kann die anderen Server, die in den
NS-Eintr&auml;gen einer Zonendatei stehen, &uuml;ber Neuerungen in einer Zone
informieren. Das ist f&uuml;r den t&auml;glichen Gebrauch sehr praktisch, aber f&uuml;r
private Zonen-Experimente sollte diese Option abgeschaltet werden. Wir
wollen doch nicht das Internet mit unserem Experiment bel&auml;stigen, oder?</P>

<P>Ausserdem ist die Domain nat&uuml;rlich nur ein Test - genauso wie alle
Adressen, die sie beinhaltet. Ein reales Beispiel aus einer existierenden
Domain ist im n&auml;chsten Kapitel zu sehen.</P>

<H2><A NAME="ss4.5">4.5</A> <A HREF="DE-DNS-HOWTO.html#toc4.5">Warum Reverse Lookups nicht funktionieren.</A>
</H2>

<P>Es gibt ein paar Probleme mit Namensaufl&ouml;sungen, wenn die Adressen
r&uuml;ckw&auml;rts aufgeschl&uuml;sselt werden sollen, die zwar selten aber dennoch
auftreten. Bevor ich darauf eingehe, sollte &uuml;berpr&uuml;ft werden, ob die
Reverse Lookups auf dem eigenen Rechner funktionieren. Wenn nicht - zur&uuml;ck
an den Anfang und den Fehler beheben.</P>

<P>Ich werde hier im Detail auf zwei Probleme eingehen, wie sie auftreten
k&ouml;nnen, wenn von ausserhalb des eigenen Netzes auf den Nameserver zugegriffen
wird.</P>

<H3>Die reverse-Zone wurde nicht delegiert.</H3>

<P>Wenn man von einen Serviceprovider einen Netzwerkbereich und einen
Domainnamen bekommt, wird der Domainname normalerweise automatisch
delegiert. Eine Delegierung ist der NS-Eintrag, der einen von einem
Nameserver zum n&auml;chsten weiterleitet, wie es in dem oberen Theorie-Abschnitt
erkl&auml;rt wurde. Das wurde doch gelesen und verstanden? Wenn die
reversen-Zonen noch nicht funktionieren, zur&uuml;ck an den Anfang und nochmals
genau lesen.</P>

<P>Die reverse Zone muss n&auml;mlich ebenfalls delegiert werden. Wenn man das
<CODE>192.168.196</CODE>-Netz mit der Domain <CODE>linux.test</CODE> vom Provider zugeteilt
bekommen hat, muss dieser auch <CODE>NS</CODE>-Eintr&auml;ge f&uuml;r die reversen-Zonen
eintragen - genauso wie f&uuml;r die »normalen« Zonen. Wenn man die Kette von
<CODE>in-addr.arpa</CODE> zur&uuml;ck zum eigenen Netz verfolgt, wird man ansonsten ein
Loch in der Kette finden. &Uuml;blicherweise ist diese L&uuml;cke beim eigenen
Serviceprovider zu finden. Wenn dieses Loch gefunden wird, kontaktiert man
am besten seinen Provider, damit dieser den Fehler behebt.</P>

<H3>Man besitzt ein klassenloses Subnetz.</H3>

<P>Dieser Punkt ist ein etwas schwieriger Punkt, aber Subnetze ohne Klasse
sind in der letzten Zeit sehr wichtig geworden und vermutlich hat man davon
eins, es sei denn man geh&ouml;rt zu einer mittelgrossen Firma.</P>

<P>Klassenlose Subnetze halten das Internet in diesen Tagen &uuml;berhaupt noch
am Leben. Bereits vor einigen Jahren gab es viele Probleme damit, dass die
IP-Adressen knapp wurden. Die netten Leute im IETF (der Internet Engineering
Task Force, die das Internet »verwalten") steckten Ihre K&ouml;pfe zusammen und
l&ouml;sten das Problem. Und mussten daf&uuml;r einen Preis bezahlen - den Preis, dass
man kleinere Netze als die der Klasse »C« bekommen kann - und dadurch kann
einiges schiefgehen. Dazu kann ich nur raten unter</P>
<P>
<BLOCKQUOTE><CODE>
<A HREF="http://www.acmebw.com/askmrdns/00007.htm">http://www.acmebw.com/askmrdns/00007.htm</A></CODE></BLOCKQUOTE>

nach einer guten Erkl&auml;rung dieses
Problems und wie man damit umgeht, zu fragen.</P>

<P>Gelesen? Ich werde hier nicht weiter darauf eingehen.</P>

<P>Der erste Teil des Problems ist, dass der eigene ISP die Techniken
verstanden haben muss, die dort erkl&auml;rt werden. Nicht alle kleinen ISPs
verstehen es und setzen es auch um. Wenn dem so ist, muss man ihnen das
eventuell erkl&auml;ren und vor allem sehr ausdauernd sein. Damit das
funktioniert, sollte man allerdings sicher sein, dass man selber das Ganze
verstanden hat ;-). Erst dann wird der Provider auch eine sch&ouml;ne reverse
Zone auf seinem Server einrichten, die man mit <CODE>nslookup</CODE> &uuml;berpr&uuml;fen kann.</P>

<P>Der zweite und letzte Teil dieses Problems ist, dass man die Technik, die
dahinter steht, richtig verstehen muss. Jeder der noch unsicher ist, sollte
auf die Seite zur&uuml;ckgehen und es noch einmal lesen. Dann kann man sich daran
machen, die eigene Klassenlose reverse-Zone einzurichten, wie es dort
beschrieben wird.</P>

<P>Eine Falle wartet hier allerdings immernoch. Alte Resolver-Programme
werden <EM>nicht</EM> in der Lage sein, dem <CODE>CNAME</CODE>-Trick in der
resolve-Kette zu folgen und werden die Rechner nicht aufschl&uuml;sseln k&ouml;nnen.
Das kann dann dazu f&uuml;hren, dass der Dienst den Rechner in eine falsche
Zugriffsklasse einordnet und einem den Zugriff verweigert oder &auml;hnliches.
Wenn man auf so einen Service st&ouml;&szlig;t, bleibt als einzige M&ouml;glichkeit (die ich
kenne), dass der ISP einen PTR-Eintrag direkt in die klassenlose Zonen-Datei
schreibt - als Ersatz f&uuml;r den CNAME-Trick.</P>

<P>Einige ISPs bieten andere Wege, um dieses Problem zu behandeln, an. Ein
Beispiel k&ouml;nnen WWW-basierte Formulare sein, in die man seine
reversen-Eintr&auml;ge machen kann oder andere automatisierte Systeme.</P>

<HR>
<A HREF="DE-DNS-HOWTO-5.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-DNS-HOWTO-3.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-DNS-HOWTO.html#toc4"><IMG SRC="toc.png" ALT="Inhalt"></A>
</BODY>
</HTML>