Frage Benötigen Internetstandards Reverse-DNS für jedes Gerät?


Die Anforderungen an Reverse-DNS sind verwirrend! Leute reden oft darüber alles Wenn Reverse-DNS nicht vorhanden ist, und das klingt beängstigend. Selbst in Fällen, in denen Anwendungen kein Reverse-DNS erfordern, werden häufig RFCs zur Unterstützung der obligatorischen PTR-Datensatzerstellung zitiert.

Einige dieser RFCs beinhalten:

RFC1912: Häufige DNS-Betriebs- und -Konfigurationsfehler

Jeder im Internet erreichbare Host sollte einen Namen haben.   ...   Stellen Sie sicher, dass Ihre PTR- und A-Datensätze übereinstimmen. Für jede IP-Adresse sollte ein passender PTR-Eintrag in der Domäne inaddr.arpa vorhanden sein. Wenn ein Host mehrfach vernetzt ist (mehr als eine IP-Adresse), stellen Sie sicher, dass alle IP-Adressen einen entsprechenden PTR-Datensatz haben (nicht nur den ersten). Wenn keine übereinstimmenden PTR- und A-Datensätze vorhanden sind, kann dies den Verlust von Internetdiensten zur Folge haben, die ähnlich sind, als wenn sie überhaupt nicht im DNS registriert wären.

RFC1033: DOMÄNE ADMINISTRATORS OPERATIONS GUIDE

Einen Host hinzufügen

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

Trotz allem bestehen einige Leute immer noch darauf, dass die PTR-Aufnahme erstellt wird ist nicht Dies wird von den Standards für die DNS-Verwaltung verlangt. Was sind die tatsächlichen Anforderungen?


25
2017-07-15 23:54


Ursprung




Antworten:


Kurze Antwort

Erfordern die Standards für den DNS-Betrieb, dass alle Geräte über einen übereinstimmenden PTR-Datensatz verfügen? Nein.

Sind die Standards für bestimmte Protokolle erforderlich? PTR Aufzeichnungen, die mit entsprechenden übereinstimmen A oder AAAA Aufzeichnungen? Ja.

Haben einige Anwendungen, die nicht einem RFC unterliegen, dieselben Anforderungen? Ja.

Kann ein PTR einen Punkt auf einem CNAME aufnehmen? Ja, aber das CNAME-Ziel muss der eindeutige Name des fraglichen Geräts sein (und nicht ein weiterer CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

Ist die Erstellung eines PTR-Datensatzes eine Best Practice? Allgemein geglaubt, aber es hat seine eigenen Probleme.

Lange Antwort

Diese Frage und Antwort wird mit der Absicht gegeben, zu helfen, ein allgemeines Missverständnis zu beruhigen.

Ein tragisch unterbewertetes Stück von RFC1796 gilt hier:

Es ist ein leider weit verbreitetes Missverständnis, dass die Veröffentlichung als RFC ein gewisses Maß an Anerkennung bietet. Es ist nicht oder zumindest nicht mehr als die Veröffentlichung in einer regulären Zeitschrift. In der Tat hat jeder RFC einen Status, relativ zu seiner Beziehung mit dem Internet-Standardisierungsprozess: Informativ, Experimentell oder Standards Track (Vorgeschlagener Standard, Draft Standard, Internet Standard) oder Historisch.

RFC1912 ist informativ. RFC1033 ist nicht eindeutig gekennzeichnet und hat eine offizielle Bezeichnung von UNBEKANNTEwas bedeutet, dass es so alt ist es sollte nicht als Referenz für irgendetwas angesehen werden. Sie definieren keine Standards und können auch nicht zur offiziellen Erweiterung eines Standards verwendet werden. Sie sollten niemals in dem Kontext zitiert werden, der impliziert, dass sie einen Standard definieren.

Stellen Sie sich informative RFC-Vorschläge als guten Rat und allgemein anerkannte Best Practice vor. Die umgekehrten DNS-Empfehlungen sind auf einen Blick sinnvoll: Wenn Sie diese Richtlinien einhalten, sinkt das Risiko, dass Sie in Situationen geraten, in denen eine Anwendung nicht funktioniert, da Reverse-DNS erforderlich und nicht geplant ist. Sie können sicherlich nicht erwarten, dass ein DNS-Administrator alle Anwendungen / Protokolle, die dies erfordern, kennt, und das trifft eher auf die Service-Eigentümer zu, die diese Datensätze anfordern.

Das sagte, außerhalb von sehr gute Automatisierung, verpflichtende PTR Record Creation Policies verursachen auch Verschmutzung.

  • Es ist extrem alltäglich für PTR Datensätze, die nicht mit den entsprechenden synchronisiert werden sollen A/AAAA Aufzeichnungen, wenn Geräte außer Betrieb genommen werden, was zu einem Schleichen von Fälschungen führt PTR Daten im Laufe der Zeit. Diese Daten dienen nur dazu, diejenigen irrezuführen, die versuchen, diese Informationen als glaubwürdig zu behandeln. Einige Anwendungsbesitzer sind bestrebt, darauf zu springen, wenn sie nach der Ursache eines Phantomproblems suchen. Das Problem wird nur noch schlimmer werden, da die Einführung von IPv6 immer üblicher wird, insbesondere für DNS-Administratoren, die für den IP-Adressraum von Carriern verantwortlich sind.
  • Mehrere PTR-Datensätze für die gleiche IP-Adresse zu haben, ist ziemlich nutzlos, und die Einhaltung des Hinweises der informativen RFCs wird unweigerlich dazu führen. Sehen: Warum werden mehrere PTR-Einträge in DNS nicht empfohlen?

Was ist schlimmer: Abwesenheit eines PTR-Datensatzes oder eines ungenauen PTR-Datensatzes? Wenn ein Protokoll bricht, weil sein Standard ein gültiges DNS erfordert, sind beide schlecht, und letzteres könnte tatsächlich sein schlechter. Abgesehen davon hat jeder eine andere Meinung zu diesem Thema. Das ist in Ordnung: Sie können die Richtlinien und Tools zusammenstellen, die am besten für Ihr Team und Ihr Unternehmen funktionieren. Stellen Sie nur sicher, dass sie skalieren und konsistente Ergebnisse liefern, und denken Sie daran, dass Reverse-DNS nur so genau ist wie die Zeit und Disziplin, die Ihre Teammitglieder ihm geben müssen.

Aber fehlende PTR-Einträge verursachen, dass sshd hängt!

Auch nicht wahr. Leute verwechseln oft die Grenze zwischen der Abwesenheit eines PTR-Datensatzes (NXDOMAIN) und gebrochen Reverse-DNS.

Eine Antwort von NXDOMAIN wird nur dann ein Problem verursachen, wenn Sie mit einem Dienst kommunizieren, der Forward Confirmed Reverse DNS (FCrDNS) benötigt. Mailserver, Kerberos, Oracle-Scan-VIPs usw.

Broken Reverse DNS ist, wenn es für Sie unmöglich ist, ein zu bekommen NXDOMAIN Antwort rechtzeitig. Viele Anwendungen (am berühmtesten sshd) blockiert auf der Reverse-DNS-Suche, wenn es Probleme gibt, eine Antwort von Upstream-Quellen rechtzeitig zu erhalten, was zu Verzögerungen in der Anwendung führt.


35
2017-07-15 23:54



Der spezifische Fall von sshd Langsames Antworten kann durch Putten vermieden werden UseDNS no im sshd_config. (Aber obwohl Sie das Problem umgehen können, ist es natürlich immer noch nicht akzeptabel, wenn das Reverse-DNS-Zeitlimit überschritten wird oder eine Serverfehlerantwort auftritt.) - kasperd
@Alnitak Haben Sie weitere kontextuelle Hintergründe? STD 13 zitiert 1033 an zwei Stellen, aber kein Zitat zitiert es als eine Referenz (man sagt nur "Kataloge verfügbar DNS-Software und diskutiert Verwaltungsverfahren"), und sogar die Fußnote bezieht sich darauf als "Ein Kochbuch für Domain-Administratoren". Ich werde gerne aufgeben, wenn ich mich irre (ich war zum Zeitpunkt der Veröffentlichung 4), aber das sieht nicht besonders stark aus. - Andrew B
oops - mein Fehler, ich dachte 1034 + 1035, nicht 1033 !! - Alnitak