BIND

Der Begriff der Zone wurde im Kontrast zur Domain geprägt, weil sie zwar miteinander verwandt, aber nicht notwendigerweise kongruent sind: eine Zone kann durchaus eine Teilmenge einer Domain darstellen und zum anderen nicht auf Host-Deklarationen innerhalb einer Domain beschränkt sein, sondern Verweise auf Hosts in „Fremd“-Domains enthalten.

Die Master-Zonendateien enthalten mindestens einen SOA Resource Record und einen oder mehrere für die Zone aussagefähige Nameserver (NS Resource Records), weiterhin eine beliebige Anzahl weiterer Resource Records (RRs) wie zum Beispiel A Resource Records oder PTR Resource Records. Allgemein notiert man RRs so:

LinkeSeite [optional:Time-to-live-Wert] [optional:Class-Name] Typ RechteSeite

LinkeSeite und RechteSeite sind grundsätzlich Zeichenketten, deren Format vom Typ bestimmt wird. Die RRs stellen also Wertepaare dar, getrennt durch die Typzuweisung – A, NS, SOA usw. – und optionale zusätzliche Attribute, nämlich eines Time-to-live-Wertes sowie einer Klassenbezeichnung, („IN“ für Internet, welches bei Fehlen der Klassenangabe als Default angenommen wird, sowie „CH“ für CHAOSnet und „HS“ für Hesiod, zwei Bezeichnungen für historische Vorstufen der Internet-Entwicklung, mittlerweile irrelevant). LinkeSeite kann auch leer sein (als White Space, d. h. Leer- oder Tabulator-Zeichen), dann gilt jeweils der LinkeSeite-Wert des vorangehenden RRs.

Mithin werden links immer die möglichen abfragbaren Informationen und rechts die zugehörigen Antwortwerte notiert. So liefert ein A-RR die einem Hostnamen zugeordnete IP-Adresse zurück („localhost IN A 127.0.0.1“); PTR-RRs dagegen dienen dem Umkehrfall, der Zuordnung von bestimmten Hostnamen zu abgefragten IP-Adressen (reverse DNS, „127.0.0.1 IN PTR localhost.“).

Zonendateien für Vorwärts- und Rückwärtsauflösung müssen konsistent formuliert werden; wie auch grundsätzlich gilt, dass für jede einzelne abfragbare Information ein RR in der betreffenden Zonendatei vorhanden sein muss: es gibt keine automatische, deduktive Ableitung irgendwelcher DNS-Informationen, wie es etwa für die Bereitstellung der reverse-DNS-Auflösung denkbar wäre (indem man z. B. PTR-Anfragen durch „inverse“ Auflösung vorhandener A-RRs – RechteSeite: Frage, LinkeSeite: Antwort – beantworten würde).

Allerdings sind sog. „Wildcard“-RRs möglich, bei denen ein Stern („*“) auf der linken Seite für beliebige Hostnamen steht. Diese gelten jedoch grundsätzlich als problematisch, weil sie ein weiteres Szenario für Angriffe auf die Integrität eines Netzes oder Dienstes eröffnen: es wird beliebigen Rechnern erleichtert, eine falsche Identität anzunehmen.

Die Zonendateien definieren damit den Inhalt einer Zone, im Wesentlichen – aber nicht ausschließlich – sind das die Hostnamen innerhalb einer Domain (also A-RRs, welche naturgemäß am häufigsten durch DNS-Clients abgefragt werden). Ebenso definiert man den für eine Domain zuständigen Mailserver (MX Resource Record, Mail Exchanger), Alias-Namen zu vorhandenen Hostnamen (CNAME-RRs, Canonical Names) oder Meta-Informationen (TXT-RRs).

Subdomains definiert man durch sog. Zone Delegation: in der Zonendatei der übergeordneten Domain wird dazu der gewünschte Subdomain-Name als Verweis auf den für die Subdomain authoritativen, also verbindlich aussagekräftigen Nameserver registriert (mithin ein NS-RR), diesen ergänzt man oft noch durch einen A-Record mit der IP-Adresse des betreffenden Subdomain-Nameservers, den sog. Glue-Record (der Begriff „Glue“ – engl. für Leim – symbolisiert, dass auf diese Art und Weise die hierarchische Anbindung zwischen Domain und Subdomain hergestellt wird).

Letzterer kann (bzw. muss sogar) entfallen, wenn der Subdomain-Nameserver selbst weder in der Sub- noch der übergeordneten Domain verankert ist (mithin in einer „Dritt“-Domain liegt, für die der gerade abgefragte Nameserver nicht authoritativ ist; BIND 9 weist solche A-RRs als „out-of-zone data“ zurück und verweigert das Laden der betreffenden Zone und damit ggf. den Programmstart). Während eine solche Konstellation ansonsten problemlos realisierbar ist, wird man jedoch in den meisten Fällen – organisatorisch betrachtet – es vorziehen, das Hosting der Subdomain-Zone entweder an einen Nameserver in dieser Subdomain zu delegieren oder aber „selbst zu erledigen“, mit anderen Worten: auf dem Nameserver der übergeordneten Domain vorzuhalten.

Ist ein Glue-Record vorhanden, befähigt das den Nameserver zu sogenannten Smart-Answers: wird im folgenden Beispiel „ns.example.com“ nach dem Hostnamen „sub.example.com“ gefragt (ein Client unterscheidet i. d. R. nicht weiter zwischen Host- und Domainnamen), lautet die Antwort sinngemäß: „Eine IP-Adresse für sub.example.com kenne ich nicht. Aber ns.sub.example.com kann weiterhelfen, Du findest ihn unter der IP-Adresse 192.168.50.1.“ Ohne Glue-Record würde der letzte Teilsatz entfallen, bzw. müsste lauten: „Finde die IP-Adresse von ns.sub.example.com doch selbst heraus!“ Dem Client, der hier auf seine eigentliche Anfrage eine Negativantwort erhalten hat, ist es (bei entsprechend „smarter“ Programmierung seiner Resolver-Bibliothek) freigestellt, stattdessen die zusätzlich übermittelten Informationen auszuwerten und somit einen DNS-Request zur Auflösung von „ns.sub.example.com“ einzusparen. An dieser Stelle liegt es, sowohl bei vorhandenem als auch fehlendem Glue-Record, ohnehin immer in der Verantwortung des Resolvers, sich zum gewünschten Subdomain-Nameserver „durchzuhangeln“ (wobei er sich jedoch der – weiter unten betrachteten – Fähigkeit eines Nameservers zur Rekursion bedienen kann, sofern nur dies dem betreffenden Client erlaubt ist).

Das Beispiel gilt für eine Domain „example.com“ mit

• zugehörigem SOA- und NS-RR („ns.example.com“)
• einem Host „www.example.com“
• einer Subdomain „sub.example.com“

Die „example.com“-Domain wird als Zonendatei „example.com.db“ auf „ns.example.com“ gehostet:

; die Time-to-live-Direktive ist seit BIND v8 am Beginn einer Zonen-
; datei vorgeschrieben; sie gilt für alle RRs ohne explizites TTL-Feld:
$TTL 1d

; optionale Direktive; alle Hostnamen OHNE nachgestellten "." in dieser Zone sind rela-
; tiv zur ff. Domain (anders ausgedrueckt: werden implizit durch $ORIGIN ergaenzt):
$ORIGIN example.com.
; sofern hier nicht angegeben, ist der Wert von $ORIGIN implizit durch den in der zugehoe-
; rigen zone-Direktive (in named.conf) deklarierten Domainnamen bestimmt, ggf. kann letz-
; terer aber auch durch $ORIGIN ueberschrieben werden, daher ist auf Konsistenz zu achten

; Start of Authority und zustaendiger Nameserver sind obligatorisch für eine
; Zonendefinition ("@" ist ein Joker-Symbol für den Wert von $ORIGIN):
@       SOA ns.example.com. hostmaster.example.com. 42 3600 1800 604800 1800
        NS  ns.example.com.

; weist dem Domainnamen example.com eine IP-Adresse zu (was ihn somit auch zu
; einem Hostnamen macht):
        A   192.168.0.100
        AAAA 2001:db8::100

; macht der Welt die IP-Adresse des oben im SOA eingefuehrten ns.example.com bekannt:
ns      A   192.168.0.1
ns      AAAA 2001:db8::1

; definiert den Host www.example.com als Alias von example.com:
www     CNAME @

; definiert die Domain sub.example.com mit dem
; zustaendigen Nameserver ns.sub.example.com:
sub     NS  ns.sub

; Glue: Anfragen nach der IP-Adresse dieses Nameservers
; können direkt von ns.example.com beantwortet werden:
ns.sub  A   192.168.50.1

Auf 192.168.50.1 muss dann ein weiterer Nameserver für die Zone „sub.example.com“ residieren. Jedoch könnte man diese genauso gut von „ns.example.com“ verwalten lassen – dazu ändert sich der vorletzte RR des Beispiels in „sub NS ns“, weiterhin kann der Glue-Record entfallen, da BIND hier selbständig erkennt, dass man für die Subdomain autoritativ ist (auf diesen Begriff wird gleich noch näher eingegangen).

Unterhalb der Second-Level-Domain-Hierarchiestufe kann jeder Betreiber eines Nameservers nach Belieben Subdomains definieren, in derselben ist das den Domain-Registraren vorbehalten, die ihrerseits Zugriff auf die Nameserver der Top-Level-Domains haben.

Da gemäß der DNS-Spezifikation Nameserver redundant vorgehalten werden sollen, aber das Pflegen identischer Zonefiles auf zwei oder mehreren unabhängigen Computern sehr umständlich und fehlerträchtig ist, unterscheidet man Master- und Slave-Server. Letztere holen eine Zonendatei per Zonentransfer von einem zugewiesenen Master-Server. Dabei wird die im SOA-Record der Zone definierte Seriennummer auf Veränderung geprüft, nur nach Inkrementierung derselben erfolgt ein Slave-seitiges Übernehmen der Zonendaten; seit BIND v8 existiert auch ein Notify-Verfahren, bei dem der Master-Server Slaves über die Veränderung von Zone-Files benachrichtigt (um die Latenz der Zonen-Updates zu minimieren). Dabei kann der Administrator durch „notify“- und „allow-notify“-Direktiven genau festlegen, welcher Slave durch welchen Master zu benachrichtigen ist. Im „named.conf“-Beispiel weiter unten findet sich je ein Muster für eine Master- („zone "example.com" ...“) und eine Slave-Zonendefinition („zone "example.net" ...“).

Man bezeichnet Nameserver bzw. ihre Antworten als autoritativ, wenn die DNS-Anfragen unmittelbar aus einer vorliegenden Zonendatei beantwortet werden können – im Gegensatz zu durch Rekursion bzw. Forwarding gewonnenen DNS-Daten, die im Cache des Servers vorgehalten werden. Master- wie Slave-Nameserver können einander gleichwertig autoritative Antworten generieren (auch wenn ein Slave „nur“ Kopien der Master-Zonen vorhält).

Neben dem Zugriff auf die in ihren Zonendateien verankerten Hostnamen beherrschen Nameserver auch das rekursive Auflösen „unbekannter“ Host- bzw. Domainnamen, dabei werden diese, von rechts beginnend, zerlegt und an die für die jeweiligen Top-Level- und Subdomains zuständigen Nameserver gerichtet. Die Abfrage beginnt dabei bei den Root-Nameservern, deren IP-Adressen jedem Nameserver vorab bekannt sein müssen und die ihrerseits Verweise auf die Nameserver der Top-Level-Domains zurückgeben.

Verantwortungsbewusste DNS-Administratoren konfigurieren ihren Server nun allerdings so, dass zunächst ein oder mehrere (netz-)topologisch „benachbarte“ (bzw. „übergeordnete“) Nameserver befragt werden (das sog. Forwarding), ehe eine vollständige Rekursion über die Root-Server veranlasst wird (um letztere zu entlasten). Dabei spekuliert man darauf, dass bei den Forwardern die Wahrscheinlichkeit höher ist, dass die benötigte Information (oder Teile davon, etwa die Auflösung der abgefragten Top-Level-Domain) schon in ihrem Cache vorliegt.

Aus der traffic-minimierenden Vermaschung interagierender Nameserver sowie dem Zwischenspeichern (Caching) der gewonnenen Informationen mit wohldefinierten Minimal- und Maximal-„Haltbarkeitsfristen“ ergibt sich die optimierte, kooperative Arbeitsweise des internetweiten Domain Name Systems.

Während Forwarding bei einer „fabrikneuen“ BIND-Distribution standardmäßig aktiviert ist (Option „Forward first;“), ist beim Aktivieren von Rekursion Vorsicht angesagt. Bei einem Nameserver, der sowohl aus dem Intra- wie auch aus dem Internet erreichbar ist, sollte man Rekursion nur für Benutzer aus dem Intranet erlauben (z. B. durch eine Option wie „allow-recursion { 192.168.0.0/16; };“), da dies sonst als Einfallstor für Denial-of-Service- und Cache-Poisoning-Attacken aus dem Internet ausgenutzt werden kann.

Die Informationen sind in verschiedenen Bereichen untergebracht. Die wichtigsten sind:

Globaler Bereich

genau eine „options {...};“-Direktive

Server-Liste

beliebig viele „server {...};“-Direktiven

Zonen-Liste

beliebig viele „zone {...};“-Direktiven

controls-Bereich

eine „controls {...};“-Direktive

logging-Bereich

eine „logging {...};“-Direktive

Im Globalen Bereich werden Zugriffsberechtigungen, Krypto-Keys und Optionen definiert (siehe Abschnitt BIND-Options[14] in der Online-Dokumentation). In der (optionalen) Serverliste sind Informationen über Partner-Server enthalten (z. B. ob ein Server inkrementellen Zonentransfer unterstützt). In der Zonen-Liste ist für jede bereitzustellende Zone ein Eintrag enthalten, der den Namen der Zone, den Namen des zugeordneten Zonenfiles, den Zonen-Typ (Master oder Slave), Zugriffsberechtigungen sowie Options enthält. Mit letzteren können auch global schon definierte Options wieder überschrieben werden (und sind dann nur im Kontext der jeweiligen Zone gültig). In einer Minimal-Konfiguration eines Nameservers sind je eine Zonendatei für die Auflösung des Hostnamens „localhost“ in die IP-Adresse 127.0.0.1 sowie die diesbezügliche Reverse-Zone enthalten. Im „named.conf“-Beispiel weiter unten sind das die ersten beiden „zone“-Direktiven. Die zugehörigen Zonendateien sind trivial und haben z. B. das folgende Aussehen (eine mögliche Zonendatei für die Domain „example.com“ wurde bereits weiter oben dargestellt):

; File "localhost.db":
$ORIGIN localhost.
$TTL 1d
@   IN  SOA @ root (
        42   ; serial nr, a tribute to Douglas Adams
        1h   ; refresh
        5m   ; retry
        7d   ; expire
        1d ) ; minimum TTL
    IN  NS  @
    IN  A   127.0.0.1
    IN  AAAA ::1

; File "localhost-rev.db":
$ORIGIN 0.0.127.in-addr.arpa.
$TTL 1d
@   IN  SOA localhost. hostmaster.localhost. (
            42   ; serial
            4h   ; refresh
            30m  ; retry
            7d   ; expire
            1d ) ; minimum TTL
 NS  localhost.
1 PTR localhost.

; File "localhost-rev6.db":
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
$TTL 1d
@   IN  SOA localhost. hostmaster.localhost. (
            42   ; serial
            4h   ; refresh
            30m  ; retry
            7d   ; expire
            1d ) ; minimum TTL
 NS  localhost.
1 PTR localhost.

Die „root“- bzw. „hint“-Zone (Direktive „zone "." IN {type hint; ...};“ im „named.conf“-Beispiel) kann ggf. weggelassen werden, da eine entsprechende Liste der Root-Server schon im Programmcode verankert ist. Durch Download einer aktuellen „named.root“-Datei und Einbinden wie gezeigt kann jedoch leicht, d. h. ohne Quelltext-Modifikation und Neuübersetzung, auf Änderungen reagiert werden (die Liste der Root-Server wird zwar nur selten geändert, zuletzt aber am 12. Dezember 2008).

Das Format der „named.root“-Datei entspricht dem einer normalen Zonendatei mit NS- und A-RRs, jedoch ohne vorangestellten SOA-RR. Sie kann – neben dem Download bei der IANA – z. B. durch den Befehl

    $> dig NS . @a.root-servers.net >named.root

beschafft werden, sofern die aktuelle Adresse des A-Root-Nameservers bekannt ist.

Der controls-Bereich definiert einen Control-Port als Schnittstelle für das rndc-Steuerprogramm und im logging-Bereich werden verschiedene Typen von Logdateien und deren Zuordnung von Programm-Ereignissen (Abfragen, Fehler etc.) eingestellt.

Beispiel einer named.conf:

options {
  allow-transfer {
     localhost ;
     172.27.157.16 ;
  };
  host-statistics YES ;
  notify          YES ;
  forward first;
  forwarders { 172.27.157.16; };
};

server 172.27.157.16 {
  bogus          no ;
  support-ixfr   yes ;
};

zone "localhost" IN {
  type master;
  file "localhost.db";
  notify no;
};

zone "0.0.127.in-addr.arpa" IN {
  type master;
  file "localhost-rev.db";
  notify no;
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
  type master;
  file "localhost-rev6.db";
  notify no;
};


zone "." IN {
  type hint;
  file "named.root";
};

zone "example.com" {
  type master ;
  file "example.com.db" ;
  notify explicit;
  also-notify { 172.27.157.16; };
};

zone "example.net" {
   type           slave ;
   masters        "ns.example.net" ;
   file           "slave/example.net.db" ;
   allow-notify   "ns.example.net" ;
};

controls {
   inet * port 953 allow { localhost; }
   keys { "rndc-key"; };
};
key "rndc-key" {
   algorithmus hmac-md5;
   secret "password";
};

logging {
   channel default-log { file "logs/named.log"; severity debug; print-severity yes; };
   category default    { default-log; };
   channel queries-log { file "logs/queries.log"; severity info; };
   category queries    { queries-log; };
};