Fehlerbehebung bei häufigen DNS-Misconfigurationen

DNS (Domain Name System) ist den meisten Menschen, die das Internet nutzen, möglicherweise nicht bekannt, aber es ist die echte unsichtbare Kraft, die das Internet antreibt, ohne die jeder nur Zahlen und IPs sehen würde. Die gesamte Bedeutung von Domainnamen existiert heute nur wegen DNS.

Einführung

Die einfachste Möglichkeit, DNS in einem Satz zu erklären, ist, den Domainnamen einer IP-Adresse zuzuordnen. Ich bin mir nicht sicher, wie viele wissen, dass, wenn jemand einen Domainnamen in IE/Firefox eingibt, der Browser die DNS-Anfrage an den Resolver des ISP (ISP-Anbieter) weiterleitet und der Resolver die Root-Server kontaktiert und dann systematisch die IP-Adresse innerhalb weniger Millisekunden abruft.

Das Verständnis von DNS und seiner Funktionsweise ist eines der schwierigsten Themen in der Computertechnik, und dennoch kämpfen selbst erfahrene Netzwerkadministratoren mit diesem Thema, wenn es um das Schreiben von DNS-Zonendateien geht.

Bevor ich mit diesem Artikel fortfahre, sind die folgenden Punkte die WICHTIGSTEN, die Sie sich merken sollten, da Sie sonst nichts verstehen würden.

Punkte, die Sie beachten sollten

Ein A-Record muss IMMER eine IP-Adresse enthalten (Host zu IP zuordnen)

Wann immer Sie einen A-Record angeben, muss er auf der rechten Seite eine IP-Adresse enthalten. Der A-Record ist so wichtig im DNS, ohne den die Zuordnung von Hostnamen zu IP absurd wäre. Also merken Sie sich das!

CNAME (Alias) muss Hostnamen enthalten. Keine IPs hier
NS- und MX-Records müssen Hostnamen enthalten. Keine IPs erlaubt.
Verwenden Sie den Punkt am Ende, wann immer Sie einen Domainnamen in der DNS-Zonendatei angeben. Dieser Punkt ist so wichtig, und wenn Sie ihn vergessen, werden Sie Albträume mit Ihrer DNS-Konfiguration haben.

Zum Beispiel

example.com. IN NS ns1.example.com.

Warum Punkt? Einfach weil er angibt, dass die Abfrage von den Root-Servern (durch den Punkt dargestellt) gestartet werden soll.

MX-Records (für Mail-Server) sollten Hostnamen und keine IPs enthalten.

Häufige DNS-Begriffe und ihre Bedeutungen

(i) Glue-Records

Glue-Records sind A-Records, die mit NS-Records verknüpft sind, um den NS-Records Nameserver “Bootstrapping”-Informationen bereitzustellen. (siehe RFC 1912 Abschnitt 2.3)

domain.com. IN NS ns1.domain.com. domain.com. IN NS ns2.domain.com.

ns1 IN A 11.33.55.77 ns2 IN A 22.44.66.88

Im obigen Beispiel verknüpfen wir jeden NS-Record mit einer IP-Adresse (A-Record) und binden somit die Nameserver an die IP (das heißt, wir “kleben” sie).

(ii) LAME Nameserver Delegation

Ein Nameserver, der nicht-autorisierte Antworten gibt, wird normalerweise als ‘LAME’ bezeichnet. Jede Domain muss mindestens 2 Nameserver haben, und wenn ich jeden von ihnen frage und sie über die Domain-Zoneninformationen verfügen, erhalte ich eine autorisierte Antwort. Wenn nicht, handelt es sich um eine ‘lame delegation’. Siehe RFC 1912 Abschnitt 2.8.

Ein Beispiel für eine lame delegation ist

domain.com IN NS ns1.domain.com domain.com IN NS ns2.example-server.net

ns1.domain.com ist so konfiguriert, dass es Zoneninformationen über die Domain hat, aber ns2.exserver.net wurde nicht richtig konfiguriert und hat keine Informationen über die Domain. Daher wird ns1 autoritativ antworten, während ns2 dies nicht tun wird, was ‘lame’ sein wird, bis es richtig eingerichtet ist.

Um ein tieferes Verständnis zu erlangen, verwenden wir das dig-Tool für example.com.

Zuerst finden wir die Nameserver von example.com:

 dig example.com NS

;; ANTWORTSEKTION: example.com. 158240 IN NS a.iana-servers.net. example.com. 158240 IN NS b.iana-servers.net.

Da wir 2 Nameserver erhalten haben, fragen wir jeden von ihnen, ob sie autorisierte Antworten geben. Wenn es autoritativ ist, wird das ‘aa’-Flag im Header der erhaltenen Antwort gesetzt (‘aa’ ist die autorisierte Antwort).

dig @b.iana-servers.net example.com NS
dig @a.iana-servers.net example.com NS

;; Antwort erhalten:
;; ->>HEADER<<- Opcode: QUERY, Status: NOERROR, ID: 60896
;; Flags: qr aa rd; QUERY: 1, ANTWORT: 2, AUTHORITY: 0, ADDITIONAL: 0

;; FRAGESEKTION:
;example.com. IN NS

;; ANTWORTSEKTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.

Achten Sie auf die Flags.

Flags: qr aa rd

Da ‘aa’ in der Antwort gesetzt ist, bieten beide Nameserver von example.com eine autorisierte Antwort. Wenn es eine lame delegation ist, erhalten Sie keine autorisierte Antwort.

VORSICHT:

Sie sollten CNAME (Alias) nicht zusammen mit NS-Records verwenden, da dies oft die meisten Resolver verwirrt, Schleifen verursacht und häufig zu ‘lame’ Delegationen führt.

domain.com IN NS ns1.domain.com. domain.com IN NS ns2.domain.com. domain.com In CNAME ns9.example-server.net

Verwenden Sie also niemals CNAME zusammen mit NS-Records.

(iii) Stealth Nameservers

Stealth Nameservers (oder versteckte Nameserver) sind nicht übereinstimmende/konfliktierende Nameserver, die auf Root-Ebene gegen die Nameserver in der Domain existieren.

Um dies zu veranschaulichen, wenn ich die übergeordneten Server nach Ihrer Domain für NS-Records auf Root-Ebene frage, erhalte ich

ns0.domain.com ns2.domain.com ns3.domain.com

aber wenn ich die Nameserver Ihrer Domain nach den NS-Records abfrage, sind diese nicht dieselben und kommen wie

ns0.domain.com ns2.domain.com ns.example-dns.net

Da ns.example-dns.net und ns3.domain.com versteckt sind, sind beide ‘stealth nameservers’. Obwohl es nichts Falsches daran gibt, ist es ratsam, keine stealth nameservers sowohl auf Root-Ebene als auch in Ihrem DNS-Server zu haben.

Sie können den dig-Befehl verwenden, um NS-Records auf Root-Server-Ebene nachzuschlagen.

 dig +trace @K.root-servers.net example.com NS

und um einen der Nameserver der Domain zu fragen.

 dig @ns0.domain.com example.com NS

Achten Sie auf etwaige NS-Unstimmigkeiten zwischen den beiden Abfragen. Wenn ein Nameserver auf Root-Ebene fehlt, fügen Sie den fehlenden Nameserver bei Ihrem Domain-Registrar hinzu. Wenn der Nameserver auf Domain-Ebene fehlt, fügen Sie den Nameserver zur Zonendatei der Domain hinzu und aktualisieren Sie alle Ihre sekundären Nameserver.

(iv) Offener DNS-Server

Einen offenen DNS-Server zu betreiben, ist ein großes Sicherheitsrisiko, da er rekursive Anfragen sowohl von innen als auch von außen in Ihrem Netzwerk beantwortet. Das bedeutet, dass jeder Ihren Server nach IP-Adressen abfragen kann und Ihr DNS-Server ihnen antwortet.

Um dies zu veranschaulichen, haben wir zwei Nameserver, die bind für die Domain example.com ausführen.

ns1.example.com ns2.example.com

Wir fragen ns1.example, um die externe Domain google.com aufzulösen, und wenn wir die IP-Adresse (A-Record) im Antwortbereich erhalten, bedeutet das, dass es sich um einen ‘offenen DNS-Server’ handelt.

 dig @ns1.example.com google.com
 dig @ns2.example.com google.com

;; Globale Optionen: printcmd
;; Antwort erhalten:
;; ->>HEADER<<- Opcode: QUERY, Status: SERVFAIL, ID: 12107
;; Flags: qr rd; QUERY: 1, ANTWORT: 0, AUTHORITY: 0, ADDITIONAL: 0

;; FRAGESEKTION:
;google.com. IN A

;; Abfragezeit: 32 msec

Da es keinen ANTWORT-Bereich oder keine IP-Adresse gibt, stellen beide Nameserver keinen offenen DNS-Server dar.

Wenn Sie zufällig bind8 oder später ausführen, müssen Sie nur ‘recursion no’ innerhalb der Optionen festlegen, um den DNS-Server daran zu hindern, rekursive Anfragen zu beantworten.

options {
….
recursion no;
}

(v) Zonenübertragungen (AXFR-Anfrage)

Zonenübertragungen werden von sekundären Nameservern durchgeführt, um die neuesten und aktualisierten Zoneninformationen für die Domain vom Master- oder Primärnameserver abzurufen. Zonenübertragungen sollten nur für sekundäre Nameserver verfügbar gemacht werden und nicht für die offene Welt, da dies ein großes Sicherheitsrisiko darstellt und die internen Informationen Ihres Netzwerks einem Angreifer offenlegen kann.

Um eine Zonenübertragung für example.com anzufordern, müssen wir zuerst den Master-Nameserver fragen. Siehe das folgende Beispiel mit dig.

 dig @ns1.example.com example.com

Wenn Sie die Ausgabe mit der vollständigen Zonendatei sehen, müssen Sie die Zonenübertragung deaktivieren. In den meisten Fällen sehen Sie “Verbindung fehlgeschlagen” oder “REFUSED”, was bedeutet, dass die Zonenübertragung nicht erlaubt ist, und das ist eine gute Sache.

Häufige DNS-Fehler beim Schreiben von Zonendateien

1. Kein CNAME, der auf NS-Records zeigt

domain.com IN NS ns1.domain.com. domain.com IN NS ns2.domain.com. domain.com In CNAME ns9.example-server.net —–> FALSCH

Das Platzieren von CNAME zusammen mit NS führt dazu, dass alle Nameserver fehlschlagen und zu einer lame delegation führen. Tun Sie das nicht!

Siehe RFC1912 2.4 und RFC2181 10.3.

2. Vermeiden Sie es, DNS-Server auf IPs im selben Subnetz (/24) oder auf demselben Server auszuführen.

Der gesamte Zweck von DNS besteht darin, dass Nameserver über verschiedene geografische Standorte verteilt sind, damit, wenn ein DNS ausfällt, der andere funktioniert. Obwohl es sehr gängige Praxis ist, beide Nameserver auf demselben Server oder Subnetz auszuführen, bietet es keine Fehlertoleranz. Wenn der Server ausfällt, fallen Ihre Nameserver aus und Ihre Website lädt nicht.

ns1 IN A 75.33.22.xx —–> dasselbe Subnetz /24 ns2 IN A 75.33.22.xx —–> dasselbe Subnetz /24

3. Richtiges GLUE

Fügen Sie immer Glue zu Ihren NS-Records zu den IP-Adressen mit A-Records hinzu, andernfalls wird einer Ihrer Nameserver fehlschlagen.

domain.com IN NS ns1.domain.com. domain.com IN NS ns2.domain.com.

ns1 IN A 1.2.3.4 —–> GLUE ns2 IN A 2.4.6.9 —–> GLUE

Siehe RFC1912.

4. Keine doppelten MX-Records

domain.com IN MX mail.domain.com. domain.com IN MX mail.domain.com —-> DOPPELT

5. Erlauben Sie Port 53 für sowohl UDP- als auch TCP-Verbindungen

Wenn Sie eine Firewall verwenden, stellen Sie sicher, dass Sie Port 53 für DNS-TCP- und UDP-Anfragen nicht blockieren. Standardmäßig verwenden DNS-Abfragen das UDP-Protokoll, während Zonenübertragungen und Benachrichtigungen das TCP-Protokoll von Port 53 verwenden.

Port 53 UDP = DNS-Anfragen
Port 53 TCP = Zonenübertragungen

6. CNAMEs können nicht mit MX-Hosts koexistieren.

Geben Sie keinen CNAME oder Alias an, der auf MX-Records zeigt.

domain.com IN MX 10 mail.domain.com. mail IN CNAME domain.com. ———-> FALSCH

Verwenden Sie stattdessen einen A-Record, um direkt auf die IP-Adresse zuzuordnen.

mail IN A 11.33.55.77 —> RICHTIG

Siehe RFC1912.

7. MX-Records sollten keine IP-Adressen enthalten

domain.com IN 10 MX mail.domain.com. —-> RICHTIG
domain.com IN 20 MX 11.22.33.44 —–> FALSCH

Der richtige Weg, dies zu tun, besteht darin, den MX-Host an den A-Record zu kleben.

domain.com IN MX 10 mail.domain.com. —–> RICHTIG
mail IN A 11.33.55.77 ———-> RICHTIG

8. NS-Records sollten KEINE IP-Adresse enthalten

Geben Sie immer Nameserver für Ihre Domain mit NS-Records an. Es sollte ein Name und keine IP-Adresse sein.

domain.com IN NS dns0.domain.com. —–> RICHTIG
domain.com IN NS 75.xx.xx.xx ———–> FALSCH

REVERSE DNS FÜR MAIL-ZUSTELLUNG

Für eine ordnungsgemäße Mail-Zustellung sind die folgenden Anti-Spam-Methoden sehr wichtig, um sicherzustellen, dass die E-Mail im Posteingang des Benutzers zugestellt wird. Die meisten öffentlichen E-Mail-Dienstanbieter wie Yahoo, Hotmail und Gmail verwenden diese Parameter, um E-Mails als Spam oder nicht zu kennzeichnen.

(i) Richten Sie Reverse IP für Ihren Mail-Server mit PTR in DNS ein (benötigt dedizierte IP)
(ii) Richten Sie SPF-Record in Ihrem DNS ein
(iii) Richten Sie Domain Keys ein

Ich habe in vielen Fällen gesehen, dass, wenn Sie einen Shared Hosting-Plan verwenden, die meisten E-Mails im Spam-/Bulk-Ordner des Benutzers landen. Verwenden Sie also einen dedizierten Server.

Richten Sie Reverse IPs für Mailserver-IP-Adressen ein

Um Reverse IP einzurichten, müssen Sie zuerst eine Anfrage an Ihren Hosting-Anbieter stellen (da er die IP-Adresse besitzt) und ihn bitten, eine Reverse IP für Ihren Mail-Server einzurichten. Sobald das erledigt ist, müssen Sie eine Zeile mit PTR in Ihrer Domain-Zonendatei einfügen.

Um die Reverse-IP-Abfrage zu testen:

 host

zeigt die Ausgabe von Reverse DNS an.

Richten Sie SPF-Record ein

Der SPF-Record wird mit einem TXT-Record in Ihrer DNS-Zonendatei eingerichtet. Er sieht aus wie unten gezeigt. Besuchen Sie http://openspf.org für weitere Informationen zur Einrichtung und Konfiguration.

domain.com IN TXT “v=spf1 a mx ip4:11.33.55.77 -all”

Um den SPF-Record mit dig abzufragen:

 dig domain.com TXT

Domain Keys

Er enthält im Wesentlichen 2 Records (mit und ohne Selector), die unter TXT mit Unterstrich zusammen mit dem generierten öffentlichen Schlüssel platziert sind.

Der ‘sel’ ist ein Selector und kann der Selektorenname sein.

So richten Sie DNS-Nameserver für Ihre Domain mit BIND9 ein

Gehen Sie einfach zu Ihrer Linux-Konsole und geben Sie die folgenden Befehle ein.

 yum install bind

Erstellen Sie eine neue Zonendatei für Ihre Domain und fügen Sie die Beispieldatei ein (siehe unten). Sie müssen domain.com, Serial und E-Mail-Parameter ändern.

nano /var/named/domain.com.db

Öffnen Sie /etc/named.conf und fügen Sie die folgenden Zeilen ein:

zone “domain.com” {
type master;
file “/var/named/domain.com.com.db”;
};

Ändern Sie die Datei und starten Sie bind neu.

service named restart

Beispieldatei für DNS-Zone für BIND

Verwenden Sie diese Datei, um Ihre Domains und Nameserver in BIND9 einzurichten:

;=================================================================
;BEISPIEL BIND DNS ZONENDATEI
;für JEDEN Domain (Ändern Sie einfach domain.com in Ihre Website)
;================================================================

; Bevor Sie beginnen, VERGESSEN SIE NICHT DEN PUNKT UND DIE SERIENINCREMENTE

$TTL 14400
$ORIGIN domain.com.

; SOA-Record
; Geben Sie den primären Nameserver ns1.domain.com an
; Die Seriennummer sollte bei jedem Update erhöht werden
@ 14400 IN SOA ns1.domain.com. webmaster.domain.com. (
2009092902 ; Seriennummer im YYYYMMDDXX (XX ist die Erhöhung)
10800; Refresh-Sekunden
3600; Retry
604800; Ablauf
38400; Minimum
);
; IP-Adresse der Website, die im A-Record angegeben ist

IN A xx.xx.xx.xx

; Mindestens 2 DNS-Namenservernamen

IN NS ns1.domain.com.
IN NS ns2.domain.com.

; Zuordnung aller Nameserver und ihrer entsprechenden IPs (GLUE)

ns1 IN A xx.xx.xx.xx
ns2 IN A xx.xx.xx.xx

; Geben Sie hier alle Subdomains und www-Einträge mit CNAME-Record an

www IN CNAME domain.com.
ftp IN CNAME domain.com.
server IN CNAME domain.com.
webmail IN CNAME domain.com.

; Richten Sie MX-Record (Mail-Exchanger mit Priorität) ein
domain.com. IN MX 10 mail.domain.com.

; Setzen Sie A-Record für Mail
mail IN A xx.xx.xx.xx;====================================

Über den Autor

Herr Balakrishnan ist Internetunternehmer und Linux-Administrator mit Interessen an PHP-Programmierung und Linux-Anwendungen. Er ist über seine Blog-Seite corpocrat.com oder auf seiner Twitter-Seite erreichbar.