Thema: Erläuterungen zu Konfiguration des DNS-Server

[1.0] [2.0] [3.0] [3.1]

3.0 Aufbau der Zonen-Datei ‚Forward‘

Hier noch mal zur Verdeutlichung meine ‚Forward‘ Datei:

/etc/bind/db.intern.lan
$TTL    86400

;                                |      DomainName – MNAME  |  Mailadresse Veranwortliche – RNAME |
@       IN      SOA     dns-server.intern.lan. root.intern.lan. (
                                               20170209         ; Serial
                                                    604800         ; Refresh
                                                      86400          ; Retry
                                                 2419200         ; Expire
                                                     86400 )        ; Negative Cache TTL
;
@                                    IN      NS   dns-server.intern.lan.

; ————————————————–—————
; – Ab hier die RechnerNamen eintragen   –
; ————————————————–—————
dns-server   IN     A                  192.168.0.99
ns-1                   IN     CNAME    dns-server

; ————————————–
; – NAS Geräte                    —
; ————————————–
server-01       IN      A                     192.168.0.245
srv-1                  IN      CNAME      server-01

server-02       IN      A                    192.168.0.243
srv-2                  IN      CNAME     server-02

3.0.1 $TTL 86400

Die ‚Time To Live‘ der Zone beträgt 86400 Sek oder 1440 Min oder 24 Std.

Die TTL Option gibt an wie lange eine schon erfolgte Namensauflösung in einem speziellen Cache vorgehalten wird. Dies hat zum einen den Vorteil das bei einer erneuten Anfrage des selben Namens die Anwortzeit scheller wird und der DNS-Server entastet wird. Zum anderen kann durch das Caching von Namensauflösungen ein kurzzeitiger Ausfall des DNS-Servers überbrückst werden. Das geht aber nur mit Namen, die sich schon im Cache befinden, neue Namen können bei einem Ausfall des DNS-Servers natürlich nicht in den Cache gelangen.

Dauer Sekunden
[RFC 1035]
Mit Einheit
[BIND]
1 Sekunde 1 1s
1 Minute 60 1m
1 Stunde 3600 1h
1 Tag 86400 1d
1 Woche 604800 1w

Man kann auch Kombinationen bilden z.B.: „Anderthalb Stunden“ = 1h30m

3.0.2 SOA

Der ‚Start Of Authority‘ enthält technische Angaben zur Steuerung für die Zone wie z.B.: Seriennummer oder Timer.
SOA bedeutet Start of Authority (dt. Beginn der Zuständigkeit) und ist wichtiger Bestandteil einer Zonendatei im Domain Name System (DNS). Ein SOA-Record enthält wichtige Angaben zur Verwaltung der Zone, insbesondere zum Zonentransfer.“
Spezifizierung:  SOA-Typ in RFC 1035
Quelle:  Wikipedia

3.0.2.0 MNAME-Wert

Die DNS-Spezifikation gibt explizit an, dass der primäre Master-Server hier benannt wird. Der Wert muss ermittelt und verwendet werden. Insbesondere ist es ein Fehler, den Zonennamen hier zu wiederholen, es sei denn, dies führt auch zu einer gültigen Adresse des primären Masters.


3.0.2.1 ‚@

Das Symbol ‚@‚ hat hier nicht die Bedeutung für eine E-Mail sondern dient hier als Platzhalter für den Zonennamen (Domainnamen) oder auch als $ORIGIN bezeichnet.

Den $ORIGIN oder Platzhalter-Inhalt findet man in der Datei ’named.conf.local‘.
Bei meiner Beispiel-DNS-Server sieht das ganze so aus:

zone „intern.lan“ {                       <—- „intern.lan“ = $ORIGIN
   type master;
   file „/etc/bind/db.intern.lan“;
};

Das wichtigste ist jedoch die Berücksichtigung des Punktes „.“ nach einem Namen in der Datei „/etc/bind/db.intern.lan“.Welche Konsequenzen das Vergessen, zeigt das folgende Beispiel:

dns-server.intern.lan. —> Umsetzung nach dns-server.intern.lan ohne das $ORIGIN angehängt wird.
… intern.lan —> Umsetzung nach  intern.lan.intern.lan ist so in der Regel nicht gewünscht.
Kurzgesagt: Der Punkt unterbindet die Anhängung der $ORIGIN

3.0.2.2 eMail-Adresse oder RNAME-Wert
Neben dem Domain-Namen muß auch ein Verantwortlicher der Zonendatei angegeben werden. Fehlt diese Angabe so kann es zu mehr als dubiosen Fehlermeldungen des DNS-Servers kommen. Hierbei ist darauf zu achten, das das Symbol ‚@‘ nicht in der Konfigurationsdatei verwendet werden darf!

statt root@intern.lan   muss man das Symbol ‚@‘ durch einen Punkt ersetzen, also

root.test.intern.lan. oder info.uvr-netconsulting.de.

Normalerweise gibt verwendet man an dieser Stelle ein ‚Dummy-Postfach‘ und nicht eine real existierende eMail-Adresse. Will man es doch machen so geht geschieht das folgendermaßen:
uwe.von.royen@intern.lan.  –> uwe\.von\.royen.intern.lan.  

Punkte vor dem ‚@‘ werden aufgelöst durch ‚\.‘ .

3.0.2.3 Seriennummer

Die Seriennummer hat eigentlich nur eine Signalfunktion für einen Master und Save DNS-Server. Auf dem Master muss ein Eintrag existieren woran der Slave erkennen kann, das sich die Datenbank auf dem Master verändert hat. und eine neue Synchronisation erfolgen muss. Betreibt man sein Netzwerk nur mit einem Master DNS-Server macht eine recht simple Seriennummer ( hier in meinem Beispiel ‚1‘) Sinn, in einem größeren Netzwerk ist es besser wie folgt die Seriennummer zu erzeugen:

YYYYMMDDVV
│     │    │   └──    ldf. Zahl 1 bis n
│     │    └────    Tag                             2015013101 z.B.
│     └──────     Monat
└─────────     Jahr

Quelle: https://www.ripe.net/publications/docs/ripe-203
Das wichtigste Problem ist, dass dieser Wert nach jeder Änderung der Zonendaten erhöht wird. Für Debuggingzwecke hat es sich als hilfreich erwiesen, das Änderungsdatum in die Seriennummer zu kodieren. Der Wert „1999022301“ ist also ein Beispiel für das YYYYMMDDnn-Schema und muss durch entsprechende Werte für das Jahr (JJJJ, vierstellig), Monat (MM, zweistellig), Tag des Monats (DD, zweistellig) und Version pro ersetzt werden Tag (nn, zweistellig). Die erste Version des Tages sollte den Wert „01“ haben. Es ist wichtig, die Reihenfolge Jahr – Monat – Tag zu bewahren. Personen, die dies als Debugging-Hilfe verwenden, müssen sich jedoch nicht auf die Datumsinformationen verlassen, da die Erfahrung zeigt, dass nach der anfänglichen Einrichtung die Wartung dieses Wertes oftmals der Autoinkrement-Funktion überlassen bleibt, die die Software manchmal bereitstellt. Andere Systeme existieren – deren Dokumentation nicht in den Geltungsbereich dieses Dokuments fällt.

3.0.2.4 Refresh 
Sekundenabstand, in dem die Slaves anfragen, ob sich etwas geändert hat (Empfehlung laut Ripe-203: 86400 ≙ 24 Stunden)
3.0.2.5 Retry 
Sekundenabstand, in denen ein Slave wiederholt, falls sein Master nicht antwortet (Empfehlung laut Ripe-203: 7200 ≙ 2 Stunden)
3.0.2.6 Expire
wenn der Master auf einen Zonentransfer-Request nicht reagiert, deaktiviert ein Slave nach dieser Zeitspanne in Sekunden die Zone (Empfehlung laut Ripe-203: 3600000 ≙ 1000 Stunden)
3.0.2.7 TTL 
Time to Live für Negatives Caching (Empfehlung laut Ripe-203: 172800 ≙ 2 Tage). Ursprünglich hatte dieses Feld die Bedeutung eines Minimum-TTL-Werts für alle Resource Records der Zone und wurde in der Praxis als Standardwert verwendet, wenn bei einem Resource Record kein TTL-Wert angegeben war; diese Bedeutung wurde mit  abgeschafft.
Ergänzung:
Wird der TTL Wert nicht im SOA Record angeben, sondern so als individuelle TTL-Wert ( nicht zu Verwechseln mit dem globalen $TTL ) für bestimmte Resource Records vergeben, so muß der TTL Wert unbedingt vor ‚IN‘ stehen! Dieser neue TTL-Wert ist dann für alle nachfolgenden Einträge gültig, bis ein neuer Wert gesetzte wird oder ein neuer SOA Record in der Zonen-Datei auftaucht. Der TTL Wert wird in Sekunden angegeben, Sie können aber auch die Einheiten m=Minuten, h=Stunden, d=Tage, w=Woche verwenden.
z.B.:

www  20m       A    192.168.1.2          ; ab hier gilt TTL=20  ??? ist unklar!!! Siehe Regel 10
     test              A    1.2.3.4                   ; TTL=20 aus vorherigem Eintrag

3.0.3 IN

Klasse ‚IN‚ für Internet-Adresse.
Das Kennzeichnung ‚IN‘ braucht eigentlich nur im ersten Resourcen Record (RR) angegeben werden.

3.0.4 NS oder NS-RR

NS‚ steht als Kennzeichen für einen NameServer.
IP-Adressen sind in NS-Records nicht erlaubt!
Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten. Im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.“
Wird ein eigener Nameserver verwendet,  dessen Hostname
„dns-server.intern.lanl“ lauten soll, muss ein zusätzlich passenden A-Record definieren.

3.0.5 A oder AAAA

Mit dem A-Record wird dem einem Namen im DNS-Server eine IPv4-Adresse zugeordnet.
Mit dem AAAA-Record („quad-A“)geschieht die Zuordnung einer IPv6-Adresse.

3.0.6  CNAME

CNAME-Record weist einem Namen ein weiteren Namen (Alias) zu. Die Abkürzung CNAME steht für  „canonical name“ (canonical = anerkannt, bezeichnet also den primären, quasi echten Namen).
Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten. Im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.

3.0.7  PTR

Der PTR (Pointer) – des Resourcen Record ordnet einer IP-Adresse ein oder mehrere Namen zu. Sie sind praktisch als Umkehrzuweisung (reverse) ein Name mehrere IP-Adressen zu. Zentrale Bedeutung in der Datei: „/etc/bind/db.rev.0.168.192“ für Zuweisung IP <-> Name. Praktisch die Umkehrung zum A-Record.

3.0.8  MX

Der MX-Resourcen Record muss man nicht kann man aber in einem eigenen Homenetz-Werk haben. Es zeigt einen eigenen E-Mail-Server an, der nicht unbedingt im öffentlichen Internet bekannt sein muß, aber recht gute Dienste im eigene Homenetz = Intranetz leisten kann. Er dient als zentraler Anlaufpunkt für E-Mail der stellvertretend z.B von T-Online die
E-Mail für alle User abholen und versenden kann. Der eigene E-Mail Server verteilt dann im Intranet die E-Mail an die entsprechenden User.

Die Abkürzung MX steht für „mail exchange“ und gibt die Adresse bzw. Namen des zuständigen Mail-Servers an. Der oder die Einträge eines MX-Records müssen immer auf einen A-Record verweisen!

    Beispiele:
domain.tld.      IN   MX   10 mail.variomedia.de. <—- öffentlicher Mail-Server
*.domain.tld.   IN   MX   10 mail.variomedia.de.
oder
mail                        A        212.227.144.210                          <—- öffentlicher Mail-Server
example.com.   MX    10 mail.example.com
example.com.   MX    20 backupmail.provider.com

oder wie in meinem Beispiel wo der Mail-Server in einer Intranet-Umgebung steht könnte:
/etc/bind/db.intern.lan
….
 ;
@                IN      NS      dns-server.intern.lan.
                    IN      MX     10 mail.intern.lan.
 mail         IN      A          192.168.0.248

Der Wert 10 gibt die Priorität des Mail-Servers an. Der Eintrag macht besonders bei mehren Mail-Server innerhalb einer Zone Sinn. Je niedrigen die Zahl desto höher die Priorität mit der ein Mail-Server die Mails zur Verarbeitung weitergeleitet bekommt.

Der MX Resource Record oder Mail Exchange Resource Record (MX-RR) einer Domain ist ein Eintrag (Resource Record) im Domain Name System, der sich ausschließlich auf den Dienst E-Mail (SMTP) bezieht.
Ein MX-Record sagt aus, unter welcher IP-Adresse der Mail-Server zu einer Domäne oder Subdomäne erreichbar ist. Es ist üblich für eine Domäne mehrere MX-Records zu definieren mit unterschiedlichen Prioritäten, sodass bei Ausfall eines Mail-Servers ein anderer die E-Mails entgegennehmen kann.