Frage Reverse DNS in einer CIDR-Welt


Reverse-DNS scheint stark an Klassengrenzen gebunden zu sein. Welche Methoden gibt es jetzt, dass CIDR der Standard ist, um Autorität für ein Subnetz zu delegieren? Wenn mehrere Methoden existieren, welche ist die beste? Müssen Sie die Delegierung je nach DNS-Server unterschiedlich handhaben (Bind, djbdns, Microsoft DNS, andere)? Nehmen wir an, ich habe die Kontrolle über ein Netzwerk, das eine Klasse B 168.192.in-addr.arpa ist. Bitte geben Sie Beispiele für:

  • Wie kann ich die Berechtigung für eine / 22 delegieren?
  • Wie man Autorität für eine / 25 delegiert?

23
2018-06-09 16:39


Ursprung




Antworten:


Das Delegieren einer / 22 ist einfach, es ist die Delegation der 4 / 24er. A / 14 ist Delegierung der 4 / 16er usw.

RFC2317 deckt die Sonderfälle mit einer Netzmaske länger als / 24 ab. Grundsätzlich gibt es keine Super-Clean-Methode, um die Delegierung von inaddr.arpa-Zonen auf andere als Oktettgrenzen zu beschränken, aber Sie können dies umgehen. Nehmen wir an, ich möchte 172.16.23.16/29 delegieren, was die IP-Adressen 172.16.23.16 -> 172.16.23.23 wären.

Als Besitzer der Zone 23.16.172.in-addr.arpa könnte ich dies in meine 23.16.172.rev-Zonendatei einfügen, um diesen Bereich an meinen Kunden zu delegieren:

16-29              IN NS  ns1.customer.com
16-29              IN NS  ns2.customer.com
16                 IN CNAME    16.16-29.23.16.172.in-addr.arpa.
17                 IN CNAME    17.16-29.23.16.172.in-addr.arpa.
18                 IN CNAME    18.16-29.23.16.172.in-addr.arpa.
19                 IN CNAME    19.16-29.23.16.172.in-addr.arpa.
20                 IN CNAME    20.16-29.23.16.172.in-addr.arpa.
21                 IN CNAME    21.16-29.23.16.172.in-addr.arpa.
22                 IN CNAME    22.16-29.23.16.172.in-addr.arpa.
23                 IN CNAME    23.16-29.23.16.172.in-addr.arpa.

Sie sehen also, dass ich eine neue Zone definiere (16-29.23.16.172.in-addr.arpa.) Und sie an die Nameserver meines Kunden delegiere. Dann erstelle ich CNAMEs aus den IPs, die an die entsprechende Nummer unter der neu delegierten Zone delegiert werden sollen.

Als der Kunde, an den diese delegiert wurden, würde ich in der named.conf so etwas wie folgt machen:

zone "16-29.23.16.172.in-addr.arpa" { 
    type master;
    file "masters/16-29.23.16.172.rev";
};

Und dann würde ich in der .rev-Datei einfach PTRs wie jede normale inaddr.arpa-Zone machen:

17                 IN PTR office.customer.com.
18                 IN PTR www.customer.com.
(etc)

Dies ist eine Art sauberer Weg, um Kunden zufrieden zu stellen, da sie eine inaddr.arpa-Zone haben, in die die PTRs eingefügt werden können. Eine kürzere Möglichkeit, dies für Kunden zu tun, die Reverse-DNS kontrollieren wollen, aber Wenn Sie eine ganze Zone einrichten möchten, müssen Sie nur einen einzelnen Datensatz mit ähnlichen Namen in der Hauptzone verknüpfen.

In diesem Fall würden wir als Delegierer in unserer Datei 23.16.172.rev so etwas haben:

16                 IN CNAME    16.customer.com.
17                 IN CNAME    17.customer.com.
18                 IN CNAME    18.customer.com.
19                 IN CNAME    19.customer.com.
20                 IN CNAME    20.customer.com.
21                 IN CNAME    21.customer.com.
22                 IN CNAME    22.customer.com.
23                 IN CNAME    23.customer.com.

Es ist also im Konzept der anderen Idee ähnlich, aber anstatt eine neue Zone zu erstellen und an den Kunden zu delegieren, CNAME Sie die Datensätze zu Namen in der bereits bestehenden Hauptzone des Kunden.

Der Kunde würde in der Zonendatei customer.com so etwas haben:

office             IN A   172.16.23.17
17                 IN PTR office.customer.com.
www                IN A   172.16.23.18
18                 IN PTR www.customer.com.
(etc)

Es hängt nur von der Art des Kunden ab. Wie gesagt, es kommt nur auf den Kundentyp an. Ein versierter Kunde wird es vorziehen, seine eigene inaddr.arpa-Zone einzurichten und wird es für sehr seltsam halten, PTRs in einer Domain-Name-Zone zu haben. Ein unkundiger Kunde wird wollen, dass er "einfach funktioniert", ohne eine Tonne zusätzlicher Konfiguration vornehmen zu müssen.

Es gibt wahrscheinlich andere Methoden, nur die beiden vertraut, die ich kenne.


Ich habe gerade über meine Aussage darüber nachgedacht, wie / 22 und / 14 einfach sind und darüber nachzudenken, warum das stimmt, aber alles zwischen 25 und 32 ist schwierig. Ich habe das nicht getestet, aber ich gehe umher, wenn du das gesamte / 32 so an den Kunden delegieren könntest:

16                 IN NS ns1.customer.com.
17                 IN NS ns1.customer.com.
(etc)

Dann fangen Sie auf der Kundenseite die gesamte / 32:

zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)

Und dann hättest du in der individuellen Datei so etwas:

@            IN PTR office.customer.com.

Der offensichtliche Nachteil ist, dass eine Datei pro / 32 ziemlich grob ist. Aber ich wette, es würde funktionieren.

All das, was ich erwähnt habe, ist reines DNS, wenn irgendein DNS-Server es nicht tun ließ, weil es die volle Funktionalität von DNS einschränkt. Meine Beispiele verwenden offensichtlich BIND, aber wir haben die Kundenseite mit Windows DNS und BIND getan. Ich sehe keinen Grund, warum es mit keinem Server funktionieren würde.


31
2018-06-09 17:04



Sie denken wahrscheinlich an rfc2317 (tools.ietf.org/html/rfc2317) - Zoredache


Ja, RFC 2317, eine sehr gute Lektüre, ist der Weg zu gehen.

Ebenfalls, mein Artikel (auf Französisch).


3
2018-06-15 08:41





BIND hat das proprietäre $ GENERATE-Makro zum Erstellen von Sequenzen von PTR-Datensätzen, aber es nimmt auch eine klassenreiche Welt an und wird für Sie nicht sehr nützlich sein. Ich kenne keine anderen Server, die spezielle Unterstützung für CIDR Reverse-Zonen haben, obwohl ich vermute, dass Nachfrage besteht!

PowerDNS hat eine nette Backend-Oberfläche, mit der Sie Ihre eigenen schreiben können, wenn das Problem groß genug ist, um die Mühe wert zu sein. Sie können den Prototyp auch mit dem "PipeBackend" erstellen. Über die MySQL / PostgreSQL-Schnittstellen können Sie sogar etwas magisches SQL-Zeug machen - zumal Postgres den Datentyp "cidr" hat.


0
2018-06-09 17:04





http://aa.net.uk/kb-domains-reversedns.html (etwa auf halbem Weg) erklärt, wie mein ISP ihren Reverse-DNS macht. Ich vermute, dass du es auf jeden Fall hässlich finden wirst.


0
2018-06-09 16:52