Umgekehrte Zonendelegierung an Subnetze kleiner als /24 in BIND. Wie es funktioniert

Eines Tages stand ich vor der Aufgabe, einem meiner Kunden das Recht zu geben, PTR-Datensätze des ihm zugewiesenen /28-Subnetzes zu bearbeiten. Ich habe keine Automatisierung zum Bearbeiten der BIND-Einstellungen von außen. Deshalb habe ich mich für einen anderen Weg entschieden – dem Client einen Teil der PTR-Zone des /24-Subnetzes zu delegieren.

Es scheint – was könnte einfacher sein? Wir registrieren einfach das Subnetz nach Bedarf und leiten es wie bei einer Subdomain an den gewünschten NS weiter. Aber nein. Es ist nicht so einfach (obwohl es in Wirklichkeit im Allgemeinen primitiv ist, aber die Intuition hilft nicht), deshalb schreibe ich diesen Artikel.

Jeder, der es selbst herausfinden möchte, kann es lesen RFC
Wer eine fertige Lösung möchte, ist bei cat herzlich willkommen.

Um diejenigen, die die Copy-Paste-Methode mögen, nicht zu verzögern, werde ich zuerst den praktischen Teil und dann den theoretischen Teil veröffentlichen.

1. Üben. Delegationszone /28

Nehmen wir an, wir haben ein Subnetz 7.8.9.0/24. Wir müssen das Subnetz delegieren 7.8.9.240/28 zum DNS-Client 7.8.7.8 (ns1.client.domain).

Im DNS des Anbieters müssen Sie eine Datei finden, die die Reverse-Zone dieses Subnetzes beschreibt. Lass es sein 9.8.7.in-adr.arpa.
Wir kommentieren die Einträge von 240 bis 255, sofern vorhanden. Und am Ende der Datei schreiben wir Folgendes:

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

Vergessen Sie nicht, die serielle Zone zu vergrößern und dies zu tun

rndc reload

Damit ist der Anbieterteil abgeschlossen. Kommen wir nun zum Client-DNS.

Erstellen wir zunächst eine Datei /etc/bind/master/255-240.9.8.7.in-addr.arpa wie folgt:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

Und in benannt.conf Fügen Sie eine Beschreibung unserer neuen Datei hinzu:

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9.8.7.in-addr.arpa";
};

B Starten Sie den Bindevorgang neu.

/etc/init.d/named restart

Alle. Jetzt können Sie es überprüfen.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Bitte beachten Sie, dass nicht nur der PTR-Record angegeben wird, sondern auch der CNAME. So soll es sein. Wenn Sie sich fragen, warum, dann willkommen im nächsten Kapitel.

2. Theorie. Wie es funktioniert.

Es ist schwierig, eine Blackbox zu konfigurieren und zu debuggen. Es ist viel einfacher, wenn man versteht, was im Inneren vorgeht.

Wenn wir eine Subdomain in einer Domain delegieren Domain, dann schreiben wir so etwas:

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

Wir sagen jedem, der fragt, dass wir für diesen Bereich nicht verantwortlich sind und sagen, wer dafür verantwortlich ist. Und alle Anfragen für client.domain Weiterleitung zu 7.8.7.8. Bei der Überprüfung sehen wir das folgende Bild (was der Kunde dort hat, lassen wir weg. Das spielt keine Rolle):

# host test.client.domain
test.client.domain has address 7.8.9.241

Diese. Uns wurde mitgeteilt, dass es einen solchen A-Eintrag gibt und seine IP 7.8.9.241 ist. Keine unnötigen Informationen.

Wie kann das Gleiche mit einem Subnetz gemacht werden?

Weil Unser DNS-Server ist in RIPE registriert. Wenn Sie eine PTR-IP-Adresse aus unserem Netzwerk anfordern, wird die erste Anfrage weiterhin an uns gerichtet. Die Logik ist dieselbe wie bei Domänen. Aber wie trägt man ein Subnetz in eine Zonendatei ein?

Versuchen wir es so einzugeben:

255-240  IN  NS      7.8.7.8

Und... das Wunder geschah nicht. Wir erhalten keine Anfrageweiterleitung. Die Sache ist, dass bind nicht einmal weiß, dass es sich bei diesen Einträgen in der Reverse-Zone-Datei um IP-Adressen handelt, und noch mehr, dass er den Bereichseintrag nicht versteht. Für ihn ist dies nur eine Art symbolischer Subdomäne. Diese. Für bind gibt es keinen Unterschied zwischen „255-240"Und"Unser Superkunde". Und damit die Anfrage dort ankommt, wo sie hin soll, sollte die Adresse in der Anfrage so aussehen: 241.255-240.9.8.7.in-addr.arpa. Oder so, wenn wir eine Zeichen-Subdomäne verwenden: 241.oursuperclient.9.8.7.in-addr.arpa. Das ist anders als üblich: 241.9.8.7.in-adr.arpa.

Es wird schwierig sein, eine solche Anfrage manuell zu stellen. Und selbst wenn es funktioniert, ist immer noch unklar, wie es im wirklichen Leben angewendet werden kann. Immerhin auf Anfrage 7.8.9.241 Das DNS des Anbieters antwortet uns immer noch, nicht das des Kunden.

Und hier kommen sie ins Spiel CNAME.

Auf der Seite des Anbieters müssen Sie einen Alias ​​für alle IP-Adressen des Subnetzes in einem Format erstellen, das die Anfrage an den Client-DNS weiterleitet.

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
и т.д.

Das ist für die Fleißigen =).

Und für die Faulen ist das folgende Design besser geeignet:

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

Fordern Sie jetzt Informationen an unter 7.8.9.241 von 241.9.8.7.in-adr.arpa auf dem DNS-Server des Anbieters konvertiert 241.255-240.9.8.7.in-addr.arpa und geht zum DNS-Client.

Die Clientseite muss solche Anfragen bearbeiten. Dementsprechend erstellen wir eine Zone 255-240.9.8.7.in-addr.arpa. Darin können wir im Prinzip Reverse-Einträge für jede IP des gesamten /24-Subnetzes platzieren, aber sie werden uns nur nach denen fragen, die der Provider an uns weiterleitet, sodass wir nicht herumspielen können =).
Zur Veranschaulichung gebe ich noch einmal ein Beispiel für den Inhalt einer Reverse-Zone-Datei von der Client-Seite:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

Das liegt daran, dass wir auf Seiten des Anbieters CNAME verwenden und als Antwort auf eine Datenanfrage nach IP-Adresse zwei Datensätze erhalten, nicht einen.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Und vergessen Sie nicht, die ACL richtig zu konfigurieren. Weil es keinen Sinn macht, eine PTR-Zone für sich selbst zu beanspruchen und niemandem von außen zu antworten =).

Source: habr.com

Kommentar hinzufügen