Klassenlose Reverse Map Delegation funktioniert nicht mit „dig -x“. Hat das Auswirkungen?

Question

Das NetzZytrax.com, wo ich erfuhrKlassenlose Reverse-Map-Delegation, sagt, dass dig -x <ip address>es hier nicht funktionieren sollte, wenn diese Delegierungsmethode (mit CNAMES) verwendet wird.

Zum Beispiel:

Das sollte nicht funktionieren: dig -x 192.168.23.66

Und das soll funktionieren: dig 66.64/27.168.192.IN-ADDR.ARPA

Und es funktioniert, wenn ich es ein wenig ändere (den Server angebe, an den es delegiert wurde und für den ich einen PTR-Eintrag haben möchte): dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

Es scheint wie im Tutorial beschrieben zu funktionieren:

Ich habe eine ähnliche Delegierung eingerichtet und sie verhält sich wie oben beschrieben: Wenn ich dig -xeine IP-Adresse aus dem delegierten Bereich verwende, teilt mir der delegierende Nameserver mit, wer Autorität über 66.64/27.168.192.IN-ADDR.ARPA.den Server hat, an den das klassenlose Netzwerk delegiert wurde. Dies funktioniert nur mit dem dritten Befehl ( dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA).

Ist es in Ordnung und sicher?

Da es mit dig -x (oder nslookup) nicht funktioniert, frage ich mich, ob es noch mehr Dinge gibt, die nicht funktionieren. Können Resolver solche IP-Adressen problemlos auflösen? Können E-Mail-Server beispielsweise problemlos Reverse Lookups durchführen, wenn diese Delegierungsmethode verwendet wird? Gibt es Gründe, sie nicht zu verwenden?

Mein Beispiel(leicht modifiziert):

dig @ns1.example.com -x 192.168.134.1

;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60  IN  CNAME   1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN   NS      ns2.example.com.


dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.

;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR     1st_super.example.com.

Warum es nicht funktioniert hat

Der Name der Zone, in die ich delegiert habe, war falsch und da ich bei der zweiten Abfrage den falschen Namen verwendet habe, bekam ich eine Antwort (die beiden Fehler hoben sich teilweise auf).

Falsch (nicht umgekehrt):

0-127.192.168.134.in-addr.arpa.

gewesen sein sollte:

0-127.134.168.192.in-addr.arpa.

Nachdem dieser Fehler behoben wurde und der delegierende Server der Slave für die delegierte Zone ist, dig -x <ipaddress>funktioniert es.

Answer 1

Kurz zusammengefasst

Wenn Sie einRFC2317-Stil klassenlose in-addr.arpa-Delegation, es ist völlig normal, dass Sie den autoritativen Nameserver für die Unterdelegation nicht direkt mit der umgekehrten Zuordnung der IP-Adresse abfragen können.
Was wirklich zählt, ist, dass ein Resolver-Server den umgekehrten Namen nachschlagen kann (z. B. dig -x 192.0.2.1 @8.8.8.8für jede Kombination aus IP-Adresse und Resolver-Server, die in Ihrer Umgebung/für Ihren Anwendungsfall relevant ist).

RFC2317-Erklärung

Das allgemeine Problem, für das RFC2317 eine Art Workaround bietet, besteht darin, dass die konventionsbasierte Zuordnung von der IPv4-Adresse zum umgekehrten Namen im DNS (z. B. 192.0.2.1-> 1.2.0.192.in-addr.arpa) klassenlosen Delegierungen vorausgeht und die möglichen Delegierungspunkte effektiv auf /0, /8, 16, /24, , sperrt /32. (Sie können nur an jedem Label delegieren, und die Zuordnung ist so definiert, dass jedes Oktett der IPv4-Adresse einfach zu einem Label wird, in umgekehrter Reihenfolge.)
Die Zuordnung hätte anders definiert werden müssen, in ein feineres Benennungsschema, um tatsächlich so etwas wie eine /27Delegation zu ermöglichen.

RFC2317 ändert NICHT die grundsätzliche Situation, es ändert das Protokoll tatsächlich in keiner Weise.
Es schlägt lediglich ein Schema vor, mit dem menschliche Bediener die Einschränkung umgehen können, dass klassenlose Delegationen nicht möglich sind.

Dieses Schema kann wie folgt zusammengefasst werden:

1. Sie definieren Aliase (fügen CNAMEDatensätze hinzu) für eine bestimmte Anzahl von Namen in der aktuellen Reverse-Zone (gemäß der Namenskonvention) und ordnen diese neuen Namen in einemneuer Namespace
   (Der neue Namespace kann wirklich habenbeliebigName, aber RFC2317 schlägt vor, einen beschreibenden Namen zu verwenden und den neuen Namespace als untergeordnetes Element Ihrer vorhandenen Zone irgendwo unter in-addr.arpa) zu platzieren.
2. Sie delegieren die entsprechende Zoneneuer Namespacewie nötig

Das Ergebnis ist, dass ein Resolver-Server, der nachschlagen soll, 1.2.0.192.in-addr.arpadies ganz normal tut und auf diesen CNAMEDatensatz stößt, statt auf den PTR, nach dem er eigentlich gesucht hat.
Er folgt dann einfach dem CNAMEin den neuen Namespace, ohne dass er überhaupt wissen muss, dass RFC2317 existiert, und wenn alles wie von RFC2317 vorgeschlagen eingerichtet wurde, findet er einen, PTRden er unter diesem neuen Namen verwenden kann.

2.0.192.in-addr.arpa.Wenn Sie beispielsweise eine Zone hätten, ns1.other.example.die Folgendes enthielte:

1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.

Der Suchvorgang für den tatsächlichen umgekehrten Namen ( 1.2.0.192.in-addr.arpa.) würde in ergeben CNAME, und der Resolver würde das einfach CNAMEnormal verarbeiten und ihm folgen, wohin es auch führt.

In diesem Beispiel führt es zu 1.0/27.2.0.192.in-addr.arpa., und es gibt auch eine Delegation für die Zone 0/27.2.0.192.in-addr.arpa.an ns7.example.com., sodass der Resolver einfach den Suchvorgang für das fortsetzen kann.neuer Nameund alles wird gut.

Wenn Sie hingegen eine Anfrage an senden, erfährt dieser nichts davon 1.2.0.192.in-addr.arpa..ns7.example.com.
ns7.example.com. nichthat zwar die Reverse Zone für diese Adresse, es gibt aber nur eine lose verwandte Zone, auf die die eigentliche Reverse Zone durch diese Aliase verweist.

Um zu prüfen, ob eine Delegation im RFC2317-Stil funktioniert, können Sie zunächst prüfen, ob ein tatsächlicher Resolver die Namen erfolgreich nachschlägt. Wenn Sie
sich jedoch mit den Details befassen, können Sie prüfen, womit der Nameserver für die echte Reverse Zone antwortet (in diesem Fall sollte es ein sein CNAME), wohin der kanonische Name (das CNAME„Ziel“) delegiert wird, und dann prüfen, ob dieser Nameserver wie vorgesehen auf den im CNAMEDatensatz angegebenen kanonischen Namen antwortet.