Docstoc

DNS-LabLoesungen

Document Sample
DNS-LabLoesungen Powered By Docstoc
					BBZS
Modul 159

                                   DNS Lab - Lösungen

Konfiguration der verwendeten (virtuellen) Rechner
         Default Gateway: 10.11.0.2
         „externer“ DNS-Server: 10.11.0.2 oder ein geeigneter NS im Internet
         Domain-Name: Format: domXY.local  dom              .local
         Sub-Domain-Name: Format: sub.domXY.local:  sub.dom            .local

OS                         Funktion                  IP-Adresse/ Maske    FQDN
Debian                     DNS-Server                10.11.     .1        ns1.dom     .local
Win32                      DNS-Client                                     frog.dom    .local




Bevor wir einen eigenen DNS-Server für verschiedene DNS-Serverrollen konfigurieren
wollen wir an einigen Beispielen erkunden, wie die DNS-Server Infrastruktur für einige
Domänen im Internet ausschaut.

Dazu verwenden wir zwei verschiedene Tools:
Das Standardtool: nslookup
Den UNIX-Befehl: host

Lab 1
NS für eine Domäne mit nslookup finden
Wir verwenden nslookup auf einem Win32-System im interaktiven Modus.

        Stellen Sie mit dem Unterbefehl „help“ fest, über welche beiden Befehle, eingestellt
         werden kann, dass nach den NS-Records für eine bestimmte Domäne gesucht wird.
         Dabei ist die zweite Version einfach eine Verkürzung der ersten Version.

[EingabePromptNSlookup>set querytype=NS // kürzer: set q=NS
[EingabePromptNSlookup>]set type=NS // kürzer: set t=NS

        Wie lautet die Eingabe, um die NS von <google.ch> abzufragen?

[EingabePromptNSlookup>set t=NS
[EingabePromptNSlookup>google.ch

        Wie heissen die FQDN der NS von <google.ch>?

google.ch    nameserver = ns4.google.com
google.ch    nameserver = ns1.google.com
google.ch    nameserver = ns2.google.com
google.ch    nameserver = ns3.google.com
ns1.google.com internet address = 216.239.32.10

Modul 159
DNS-Lab                                          1
ns2.google.com internet address = 216.239.34.10
ns3.google.com internet address = 216.239.36.10
ns4.google.com internet address = 216.239.38.10


    Was fällt auf, wenn die gleiche Abfrage mehrmals ausgeführt wird?
     Was ist der Grund für dieses Verhalten.
     Wie nennt man dieses Verfahren?

Es fällt auf dass, die sich die Reihenfolge der aufgeführten NS-Einträge praktisch mit jedem
Aufruf ändert.

Grund für dieses Verhalten ist, dass den anfragenden NS nicht stets der gleiche Google-NS
als erster NS angeboten wird. Dadurch wird ein Lastausgleich auf den Google-NS erreicht.

Dieses Verfahren heisst „round robin“ Verfahren (Rundlauf-Verfahren) zur Lastverteilung
zwischen den verschiedenen Domain-NS.


Lab 2
NS für eine Domäne mit dem UNIX-Kommando <host> finden

    Schauen Sie mit <man host> nach, was das Kommando im Zusammenhang mit DNS
     leistet. Notieren Sie den wesentlichen Satz aus der „DESCRIPTION“.
Host is a simple utility for performing DNS lookups. It is normally used to convert names to IP
addresses an vice versa.

    Wie lautet die vollständige Kommando-Eingabe mit <host>, um die NS von <ch.>
     abzufragen.
host –t NS ch

    Welche NS von <ch.> stehen in der TLD <ch.>? Wie viele NS sind insgesamt für die
     Domäne <ch.> authorisierend?
Dazu können Sie das Kommando <grep> zur Ausfilterung von <.ch.>, das am Ende einer
Zeile steht verwenden:
host –t NS ch ¦ grep ’ch\.$ ’

Dabei bedeutet:
\.     Das Nachfolgende Zeichen, in diesem Falle der Punkt, wird nicht als Sonderzeichen
       beachtet.
$      Weist grep an, das zu suchende Suchmuster am Ende einer Zeile
       zu suchen.

Bemerkung:
Unter dem Begriff REGEXP (Regular Expressions) wird in UNIX eine Möglichkeit zur
abstrakten, überaus mächtigen, aber auch komplizierten Beschreibung von Suchmustern
verstanden.

Damit erhält man die folgende Ausgaben:
domreg.nic.ch
merapi.switch.ch
cctld.tix.ch
Anzahl NS, die für <ch.> authorisierend sind: 3
Modul 159
DNS-Lab                                       2
    Stellen Sie mit dem Tool <host> noch fest, wie viele NS für <.> authorisierend sind.
     Capturen Sie die Anfrage und die Antwort mit Ethereal. Formulieren Sie dazu einen
     geeigneten Capture-Filter, damit nur DNS-Queries / Responses, die mit Ihrem eigenen
     Linux-Host in Verbidung stehen, gefiltert werden.
Capture-Filter: udp port 53 or tcp port 53
Anzahl NS für die Domäne <.>: 13
Die Root-Server befinden sich in der Domäne: root-servers.net
Anzahl Frames, die für die DNS-Response erforderlich sind: 1




Ethereal-Capture Datei:



Lab 3
BIND als Caching Only-NS konfigurieren
Wir gehen davon aus, dass <bind9> aus den Quellen installiert ist und die Binaries im
Verzeichnis </usr/local/sbin> liegen.
Unter www.zytrax.com/books/dns finden Sie eine gute Dokumentation zu DNS allgemein und
zur Konfiguration von Bind.

    Die einfachste Serverrolle, die Bind übernehmen kann ist die des Caching Only NS.
     Notieren Sie die wesentlichen Merkmale eine Caching Only NS.
Der Caching Only DNS-Server
-    ist für keine Zone autorisierend, ausser für seine eigene <localhos> Forward- und
     Revese-Lookup Zone.
-    nimmt von Client-Resolvern rekursive Anfragen entgegen.
-    löst die Client-Anfragen durch eine Reihe von iterativen Anfragen auf
-    speichert die aufgelösten Anfragen während der jeweiligen Gültigkeitsdauer der RR-
     Einträge im Cache.
-    beantwortet erneute Anfragen nach gecachten Einträgen mit dem Vermerk „nicht
     authorisierend“


Bind erfordert zum Start
     eine Konfigurations-Datei <etc/named.conf>, die auf die Serverrolle angepasst ist.
     ein Arbeitsverzeichnis, in dem die erforderlichen Zonen-Dateien abgelegt sind. Der
      Speicherort und die Bezeichnung für dieses Arbeitsverzeichnis sind nicht
      vorgeschrieben, da diese Angaben in der Konfigurationsdatei <named.conf>
      eingetragen werden müssen. Wir verwenden als Arbeitsverzeichnis den Ordner
      </etc/bind>.
Im DNS-Buch von Zytrax finden Sie im Kapitel 6.4 ein Muster für <named.conf> für einen
Caching Only Server.
Die eigentliche Konfiguration von bind erfolgt im Abschnitt <options>.



Modul 159
DNS-Lab                                       3
Damit der NS der Abarbeitung einer rekursiven Client-Anfrage vornehmen kann, muss er in
der Lage sein, die dazu erforderlichen, iterativen Anfragen abzuarbeiten. Die Serie der
iterativen Anfragen startet bekanntlich mit einer Anfrage an einen Rool-Server.
Dazu müssen aber die Root-Server Angaben zuerst in das System eingepflegt und dann in
der Bind-Konfigurationsdatei <named.conf> bekannt gemacht werden.
Diese Bekanntmachung erfolgt in <named.conf> unter dem Abschnitt <zone “.“ {}>
Zur Beschaffung der Root-Server Daten gibt es unter UNIX das Tool <dig>. Wenn Sie <dig>
wie folgt aufrufen, wird eine für bind verwendbare Ausgabe für eine <.>-Zonen-Datei erstellt:
dig ns @a.root-servers.net.
Mit einer anschliessenden Umleitung der Standard-Ausgabe in eine Datei mit
> ./bind/root.servers leiten Sie die Ausgabe in die Datei </etc/bind/root.servers> um.

~#dig ns @a.root-servers.net. > ./bind/root.servers


; <<>> DiG 9.3.2-P1 <<>> ns @a.root-servers.net.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29938
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13

;; QUESTION SECTION:
;.                           IN     NS

;; ANSWER SECTION:
.                 518400            IN      NS     L.ROOT-SERVERS.NET.
.                 518400            IN      NS     M.ROOT-SERVERS.NET.
.                 518400            IN      NS     I.ROOT-SERVERS.NET.
.                 518400            IN      NS     E.ROOT-SERVERS.NET.
.                 518400            IN      NS     D.ROOT-SERVERS.NET.
.                 518400            IN      NS     A.ROOT-SERVERS.NET.
.                 518400            IN      NS     H.ROOT-SERVERS.NET.
.                 518400            IN      NS     C.ROOT-SERVERS.NET.
.                 518400            IN      NS     G.ROOT-SERVERS.NET.
.                 518400            IN      NS     F.ROOT-SERVERS.NET.
.                 518400            IN      NS     B.ROOT-SERVERS.NET.
.                 518400            IN      NS     J.ROOT-SERVERS.NET.
.                 518400            IN      NS     K.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
L.ROOT-SERVERS.NET.          3600000        IN     A      198.32.64.12
M.ROOT-SERVERS.NET.          3600000        IN     A      202.12.27.33
I.ROOT-SERVERS.NET.          3600000        IN     A      192.36.148.17
E.ROOT-SERVERS.NET.          3600000        IN     A      192.203.230.10
D.ROOT-SERVERS.NET.          3600000        IN     A      128.8.10.90
A.ROOT-SERVERS.NET.          3600000        IN     A      198.41.0.4
H.ROOT-SERVERS.NET.          3600000        IN     A      128.63.2.53
C.ROOT-SERVERS.NET.          3600000        IN     A      192.33.4.12
G.ROOT-SERVERS.NET.          3600000        IN     A      192.112.36.4
F.ROOT-SERVERS.NET.          3600000        IN     A      192.5.5.241
B.ROOT-SERVERS.NET.          3600000        IN     A      192.228.79.201
J.ROOT-SERVERS.NET.          3600000        IN     A      192.58.128.30
K.ROOT-SERVERS.NET.          3600000        IN     A      193.0.14.129

;; Query time: 627 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Oct 17 09:49:12 2006
Modul 159
DNS-Lab                                       4
;; MSG SIZE     rcvd: 436

Datei </etc/bind/root.servers>
Im Rest der Konfigurations-Datei werden nun noch die Zonen für Forward- und Rever-
Lookup-Zone für <localhsot> definiert. Damit lautet die ganze Konfiguratonsdatei
<named.conf>
// Basis-Konfiguration
options {
      // Arbeitsverzeichnis
      directory "/etc/bind";
      // Zonen-Transfer ist nicht erlaubt
      // da der NS für keine Zone authorisierend ist
      allow-transfer{"none";};
      // Host, aus welchem Subnet dürfen
      // den NS nutzen
      allow-query{10.11.0.0/16;};
};
// Erforderliche Zonen zur Abarbeitung rekursiver Queries
zone "." {
      type hint;
      file "root.servers";
};

// Interne Domain mit localhost
zone "localhost" in{
      type master;
      file "master.localhost";
      allow-update{"none";};
};
// localhost reverse zone
zone "0.0.127.in-addr.arpa" in {
      type master;
      file "localhost.rev";
      allow-update{"none";};
};

Die Syntax von <named.conf> kann mit dem Tool <named-checkconf> getestet werden.
usr/local/sbin>named-checkconf
sollte ohne Rückmeldung terminieren.
Nun folgen noch in /etc/bind/ die Dateien für die interne Zone <localhost>
; BIND data file for local loopback interface
;
$TTL 604800
@     IN    SOA   localhost. root.localhost. (
                        1           ; Serial
                   604800           ; Refresh
                    86400           ; Retry
                  2419200           ; Expire
                   604800 )   ; Negative Cache TTL
;
@     IN    NS    localhost.
@     IN    A     127.0.0.1

Datei </etc/bind/master.localhost>

; BIND reverse data file for local loopback interface
;
$TTL 604800

Modul 159
DNS-Lab                                       5
@      IN      SOA    localhost. root.localhost. (
                            1           ; Serial
                       604800           ; Refresh
                        86400           ; Retry
                      2419200           ; Expire
                       604800 )   ; Negative Cache TTL
;
@     IN       NS     localhost.
1.0.0 IN       PTR    localhost.


Datei: </etc/bind/localhost.rev>
Der Zustand der Zonen-Dateien kann mit dem Tool <named-checkzone> getestet werden.
Die Syntax des Kommandoaufrufs ist:
named-checkzone ZonenName /Pfad/NameDerZonenDatei
Nachdem die Konfiguration der DNS-Serverrolle abgeschlossen ist, sollte sich <named>
starten lassen. Mit <ps> kann kontrolliert werden, ob von <named> wirklich eine Prozess-
Nummer belegt wird.
Konfigurieren Sie nun einen Win32-DNS-Client so, dass sein Resolver den eben
konfigurierten DNS-Server verwendet.
Leeren Sie auf dem DNS-Client den DNS-Cache und testen Sie die Funktion des Caching
Only NS mit einem Ping auf www.google.ch.

Lab 4
Den Caching Only-NS im Betrieb untersuchen
Starten Sie Ethereal mit geeigneten Capture-Filtern auf dem DNS-Client und dem DNS-
Server.
Führen Sie auf dem DNS-Client einen Ping auf www.switch.ch aus.
Beantworten Sie nun anhand der Capture-Daten die folgenden Punkte in der Tabelle:
DNS-Client                                       DNS-Server
Art der Anfrage: rekursive Anfrage               Art der Anfrage:
Anfrage-Ziel: DNS-Caching Only Server            nicht rekursiv > iterativ nach www.switch.ch
                                                 AnfrageZiel:
                                                 198.32.64.12 (L.ROOT-SERVERS.NET)
                                                 Antwort:
                                                 Die weiter oben aufgelisteten autoritativen
                                                 Nameserver von CH.


                                                 Art der Anfrage:
                                                 nicht rekursiv nach www.switch.ch
                                                 AnfrageZiel:
                                                 130.59.211.10 (merapi.switch.ch)
                                                 Antwort: Nameserver von switch.ch
                                                 merapi.switch.ch (ist auch für die Zone
                                                 switch.ch autorisierend)
                                                 und scsnms.switch.ch

Modul 159
DNS-Lab                                      6
                                                Art der Anfrage:
                                                nicht rekursiv nach www.swich.ch
                                                AnfrageZiel:
                                                scnms.switch.ch
                                                Antwort: CNAME oreius.switch.ch
                                                Art der Anfrage:
                                                nicht rekursiv nach A oreius.switch.ch
                                                AnfrageZiel:
                                                scnms.switch.ch
                                                Antwort: IP-Adresse für oreius.switch.ch
Anfrage-Antwort:
Oreius.switch.ch als primärer Name für
www.switch.ch 130.59.138.34

Flushen Sie nun den DNS-Cache des Clients und starten Sie Ethereal erneut auf dem Client
und dem Server.
Führen Sie nun erneut einen Ping auf www.switch.ch aus. Ergänzen Sie mit Hilfe der
Capture-Daten die folgende Tabelle:

DNS-Client                                      DNS-Server
Art der Anfrage: rekursiv                       Art der Anfrage: iterative Anfrage
Anfrage-Ziel: lokaler DNS Caching Only          AnfrageZiel:
Server                                          130.59.10.30 (scsnms.switch.ch)
                                                Antwort: IP-Adresse von www.switch.ch


Anfrage-Antwort:
IP-Adresse von www.switch.ch
Bemerkung:
Wenn der Ping nicht nach www.switch.ch sondern nach seinem primären Namen
oreius.switch.ch geht, holt der Caching Only Server seine Antwort direkt aus dem Cache.

Lab 5
Bind für Master Zonen <domXY.local> und <XY.11.10.in-addr.arpa> konfigurieren
Jetzt soll Bind als authorisierender NS für die Zonen <domXY.local> und die Reverse-
Lookup-Zone <XY.11.10.in-addr.arpa> arbeiten. Dazu ist eine Anpassung der named-
Konfigurations-Datei <named.conf> erforderlich.
Dabei wird davon ausgegangen, dass in der Domäne <domXY.local> ein NS und zwei
Win32 Client-Rechner stehen.
    Der <options>-Teil wird auf die neue Serverrolle angepasst
    Es müssen für die zwei neuen Master-Zonen zwei Zonen-Definitionen eingetragen
     werden.
Datei <etc/named.conf>
// Basis-Konfiguration
// MASTER & Caching Name Server for dom00.local
Modul 159
DNS-Lab                                     7
//
options {
      // Arbeitsverzeichnis
      directory "/etc/bind";
      // Zonen-Transfer ist nicht erlaubt
      // da der NS für keine Zone authorisierend ist
      allow-transfer{"none";};
      // Host, aus welchem Subnet dürfen
      // den NS nutzen
      allow-recursion{10.11.0.0/16;};
};
//
//
// Erforderliche Zonen zur Abarbeitung rekursiver Queries
zone "." {
      type hint;
      file "root.servers";
};
// Authorisierend für Zone dom00.local
zone "dom00.local" in{
      type master;
      file "pri.dom00.local";
      allow-update{"none";};
};

// Interne Domain mit localhost
zone "localhost" in{
      type master;
      file "master.localhost";
      allow-update{"none";};
};
// localhost reverse zone
zone "0.0.127.in-addr.arpa" in {
      type master;
      file "localhost.rev";
      allow-update{"none";};
};
// revers zone for classless net 10.11.185.0/24
zone "185.11.10.in-addr.arpa" in{
      type master;
      file "10.11.185.rev";
};


Datei </etc/bind/master.local> für die Zone <loalhost>
; BIND reverse data file for local loopback interface
$TTL 604800
$ORIGIN 0.0.127.IN-ADDR.ARPA.
@     IN    SOA   localhost. root.localhost. (
                   2006112001 ; Serial
                   604800           ; Refresh
                    86400           ; Retry
                  2419200           ; Expire
                   604800 )   ; Negative Cache TTL
;
@     IN    NS    localhost.
1.0.0 IN    PTR   localhost.


Datei <(/etc/bind/localhost.rev> für die Zone <0.0.127.in-addr.arpa>

Modul 159
DNS-Lab                                       8
; BIND reverse data file for local loopback interface
$TTL 604800
$ORIGIN 0.0.127.IN-ADDR.ARPA.
@     IN    SOA   localhost. root.localhost. (
                        1           ; Serial
                   604800           ; Refresh
                    86400           ; Retry
                  2419200           ; Expire
                   604800 )   ; Negative Cache TTL
;
@     IN    NS    localhost.
1.0.0 IN    PTR   localhost.


Datei </etc/bind/pri.dom00.local> für die Zone <dom00.local>
; Zone file for zone dom00.local
$TTL 2h; zone default TT = 2 days
$ORIGIN dom00.local.

@     IN SOA debian101.dom00.local. root.dom00.local. (
      2006112002 ; serial
      12h         ; ref
      15m         ; ret
      3w          ; exp
      3h          ; min
      )
;     NS
            IN    NS    debian101.dom00.local.
;     A-RR
debian101   IN    A     10.11.185.1
server1           IN    A     10.11.185.10
server2           IN    A     10.11.185.210


Datei: </etc/(bind/10.11.185.rev> für die Zone 185.11.10.in-addr.arpa
$TTL 3h
$ORIGIN 182.11.10.IN-ADDR.ARPA.
@ IN SOA debian101.dom00.local. root.debian101.local. (
      2006112001 ; serial
      3h          ; refresh
      1h          ; retry
      1w          ; epire
      1h          ; minimum
)
;
      IN    NS    debian101.dom00.local.
;     PTR Records
1     IN    PTR   debian101.dom00.local.
10    IN    PTR   server1.dom00.local.
210   IN    PTR   server2.dom00.local.


Führen Sie nun von einem Client-Rechner <server2> einen Ping auf <server1.domXY.local>
durch und verfolgen Sie die Anfrage mit einem geeigneten Capture-Filter auf dem NS.
Funktion des dom00.local Master DNS Servers testen:




Modul 159
DNS-Lab                                      9
Expandierte Antwort auf Query A server2.dom00.local




Lab 6
Bind für delegierte Master-Zone <sub.domUV.local> konfigurieren
In dieser Übung geht es darum eine Zonen-Delegierung vorzunehmen:
Teile der Zone <domXY.local> werden in eine Sub-Zone <sub.domXY.local> ausgelagert.
Suchen Sie Gründe, warum Teile einer Zone in eine Sub-Zone delegiert werden.
Abtreten von administrativer Verantwortung an Administratoren von Unterdomäen.
Verkleinern der Zonendateien: schnellerer Zugriff auf RR, Verkürzung der Zeiten für
vollständigen Zonentransfer.


Praktisches Vorgehen:
      Die Sub-Zonen werden nicht auf dem eigenen Bind konfiguriert sondern auf dem
       Bind eines Partners.
In diesem Beispiel wird der NS auf dem Host <10.11.182.2/ 16 , cheronimo> installiert.
<cheronimo> liegt im gleichen /16- , ja sogar im gleichen /24-Subnet wie die Hosts von
<dom00.local>. Aus diesem Grunde wird in diesem Beispiel auf das Abdelegieren einer
Unterzone von <185.11.10.in-addr.arpa> verzichtet.
Damit ergeben sich die folgenden Anpassungen
Zone <dom00.local>, Zonendatei auf NS von dom00.local: <pri.dom00.local>
      Dazu muss in der eigenen Zone <domXY.local>
            - der NS von sub.dom00.local bekannt gemacht werden

Modul 159
DNS-Lab                                      10
            - für diesen NS ein A-RR „Glue-Eintrag“ geschrieben werden,
   damit die Suche in der Sub-Zone fortgesetzt wird.
(Vergl. Theorieblatt und www.zytrax.com/books/dns)

; Zone file for zone dom00.local
$TTL 2h; zone default TT = 2 days
$ORIGIN dom00.local.
@     IN SOA debian101.dom00.local. root.dom00.local. (
      2006112003 ; serial
      12h         ; ref
      15m         ; ret
      3w          ; exp
      3h          ; min
      )
;     NS
@           IN    NS    debian101.dom00.local.
;     A RR
debian101   IN    A     10.11.185.1
server1           IN    A     10.11.185.10
server2           IN    A     10.11.185.210
; $ORIGIN directive simplifies and clarifies definitions
$ORIGIN sub.dom00.local.      ; all subsequent RRs use this ORIGIN
; NS for the subdomain
@     IN    NS    cheronimo.sub.dom00.local.
; A-RR for name server cheronimo.sub.dom00.local - "the glue record"
cheronimo   IN    A     10.11.185.2 ; glue record

Zone <185.11.10.in-addr.arpa>, Zonendatei auf NS von dom00.local: <10.11.185.rev>
      Stellen Sie den <server3> und <server4>in die Sub-Domäne <sub.domXY.local>
       (Ob die Server <sever3> und <server4> wirklich existieren ist nicht entscheidend, der
       DNS-Abfrage-Vorgang kann auch verfolgt werden, ohne dass die Server dann
       wirklich „anpingbar“ sind.=

$TTL 3h
$ORIGIN 185.11.10.IN-ADDR.ARPA.
@ IN SOA debian101.dom00.local. root.debian101.local. (
      2006112002 ; serial
      3h          ; refresh
      1h          ; retry
      1w          ; epire
      1h          ; minimum
)
;
      IN    NS    debian101.dom00.local.
;     PTR Records
1     IN    PTR   debian101.dom00.local.
10    IN    PTR   server1.dom00.local.
210   IN    PTR   server2.dom00.local.
; hosts for sub.dom00.local
2     IN    PTR   cheronimo.sub.dom00.local.
230   IN    PTR   server3.sub.dom00.local.
231   IN    PTR   server4.sub.dom00.local.

      Dokumentieren Sie das Vorgehen mit einer Step-by-Step Beschreibung und den
       entsprechenden Konfigurations-Dateien
Jetzt geht es um die Konfiguration des NS der Zone <sub.dom00.local>


Modul 159
DNS-Lab                                     11
Datei <named.conf> auf NS sub.dom00.local
// Basis-Konfiguration
// MASTER & Caching Name Server for sub.dom00.local
//
options {
      // Arbeitsverzeichnis
      directory "/etc/bind";
      // Zonen-Transfer ist nicht erlaubt
      // da der NS für keine Zone authorisierend ist
      allow-transfer{"none";};
      // Host, aus welchem Subnet dürfen
      // den NS nutzen
      allow-recursion{10.11.0.0/16;};
};
// Erforderliche Zonen zur Abarbeitung rekursiver Queries
zone "." {
      type hint;
      file "root.servers";
};
// Authorisierend für Zone sub.dom00.local
zone "sub.dom00.local" in{
      type master;
      file "pri.sub.dom00.local";
      allow-update{"none";};
};

// Interne Domain mit localhost
zone "localhost" in{
      type master;
      file "master.localhost";
      allow-update{"none";};
};
// localhost reverse zone
zone "0.0.127.in-addr.arpa" in {
      type master;
      file "localhost.rev";
      allow-update{"none";};
};
// keine Reverse-Lookup Zone
// Hosts von sub.dom00.loal im IP-Subnet von dom00.local

Datei <pri.sub.dom00.local> für Zone <sub.dom00.local> auf NS-<sub.dom00.local>
; Zone file for zone sub.dom00.local
$TTL 2h; zone default TT = 2 days
$ORIGIN sub.dom00.local.

@     IN SOA cheronimo.sub.dom00.local. root.sub.dom00.local. (
      2006112002 ; serial
      12h         ; ref
      15m         ; ret
      3w          ; exp
      3h          ; min
      )
;     NS-RR
      IN    NS    cheronimo.sub.dom00.local.
;     A RRs
cheronimo   IN    A     10.11.185.2
server3           IN    A     10.11.185.230
server4           IN    A     10.11.185.231


Modul 159
DNS-Lab                                12
      Führen Sie einen Test durch
Im folgenden Test wird der Ablauf einer DNS-Query nach dem Server
<server3.sub.dom00.local> mit drei Ethereal-Screenshots belegt:
DNS-Abfrage auf einem Client:
Es ist zu sehen, dass der Client den NS aus dom00.local anfragt und dieser die Antwort mit
Verweis auf den NS aus <sub.dom00.local> erteilt.




Weiterleitung der Anfrage vom NS-<dom00.local> an NS und Antwort an Client




Modul 159
DNS-Lab                                     13
Bearbeitung auf NS-<sub.dom00.local> und Rückmeldung an NS-<dom00.local>




Was jetzt noch zu wäre:
Delegation einer Sub-NET/185.11.10.in-addr.arpa Zone gemäss RFC 2317 „Classless IN-
ADDR.ARPA delegation“. Dafür liegen die serverX.dom00.local und
serverY.sub.dom00.local im IP-Adress-Raum zu ungünstig  Planung des Mappings der
(Sub)-Domäne z.B. auf den 10.11.185.0/24 Adressraum.




Modul 159
DNS-Lab                                  14

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:11/2/2011
language:German
pages:14