Delegierung einer Reverse-Subnetzzone von weniger als / 24 in BIND. Wie funktioniert es?

Einmal stand ich vor der Aufgabe, einem der Kunden das Recht zu geben, die PTR-Datensätze des ihm zugewiesenen Subnetzes zu bearbeiten / 28. Ich habe keine Automatisierung zum Bearbeiten der BIND-Einstellungen von außen. Also habe ich beschlossen, den anderen Weg zu gehen - ein Stück der PTR / 24-Subnetzzone an den Client zu delegieren.

Es scheint - was könnte einfacher sein? Wir schreiben das Subnetz einfach richtig vor und leiten es an das gewünschte NS weiter, wie es mit der Subdomain gemacht wird. 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.

Wer es selbst herausfinden will, kann den RFC lesen
Wer eine fertige Lösung will, ist herzlich willkommen bei cat.

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

1. Üben. Delegierungszone / 28

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

Auf dem DNS des Anbieters müssen Sie eine Datei finden, die die umgekehrte Zone dieses Subnetzes beschreibt. Sei es 9.8.7.in-addr.arpa .
Beiträge von 240 bis 255 werden gegebenenfalls kommentiert. Schreiben Sie am Ende der Datei Folgendes:

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

Vergessen Sie nicht, die seriellen Zonen zu erhöhen und dies zu tun

 rndc reload 

Damit ist der Provider-Teil beendet. Wir übergeben an Kunden DNS.

Erstellen Sie zunächst die Datei /etc/bind/master/255-240.9.8.7.in-addr.arpa mit dem folgenden Inhalt:

 $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. 

Fügen Sie in der Datei named.conf die 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 

Das ist alles. Jetzt können Sie ü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-Datensatz angegeben wird, sondern auch CNAME. Es sollte so sein. Wenn Sie sich fragen, warum, dann begrüßen Sie das nächste Kapitel.

2. Theorie. Wie funktioniert es

Es ist schwierig, eine Black Box zu konfigurieren und zu debuggen. Viel einfacher, wenn Sie verstehen, was im Inneren passiert.

Wenn wir eine Subdomain in der Domain- Domain delegieren, schreiben wir ungefähr Folgendes:

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

Wir sagen allen, die fragen, dass wir nicht für diese Website verantwortlich sind, und wir sagen, wer dafür verantwortlich ist. Alle Anfragen an client.domain werden an 7.8.7.8 umgeleitet. Bei der Überprüfung sehen wir das folgende Bild (lassen Sie weg, was der Client dort hat. Es spielt keine Rolle):

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

Das heißt, Wir wurden informiert, dass es einen solchen A-Datensatz und dessen IP 7.8.9.241 gibt. Keine unnötigen Informationen.

Aber wie geht das auch mit einem Subnetz?

Weil Da unser DNS-Server in RIPE registriert ist, wird bei der Anforderung einer PTR-IP-Adresse von unserem Netzwerk die erste Anforderung weiterhin an uns gesendet. Die Logik ist dieselbe wie bei Domänen. Aber wie soll man das Subnetz in die Zonendatei eingeben?

Wir versuchen es so einzugeben:

 255-240 IN NS 7.8.7.8 

Und ... ein Wunder ist nicht geschehen. Wir erhalten keine Weiterleitung von Anfragen. Die Sache ist, dass bind überhaupt nicht weiß, dass diese Einträge in der Reverse Zone-Datei IP-Adressen sind und noch mehr, so dass sie den Bereichseintrag nicht verstehen. Für ihn ist dies nur eine symbolische Subdomain. Das heißt, Für die Bindung gibt es keinen Unterschied zwischen " 255-240 " und " unserem Superclient ". Und die Anfrage für die Anfrage, dorthin zu gehen, wo sie sein sollte, sollte die Adresse in der Anfrage folgendermaßen aussehen: 241.255-240.9.8.7.in-addr.arpa . Oder so, wenn wir eine Zeichen-Subdomain verwenden: 241.oursuperclient.9.8.7.in-addr.arpa . Dies unterscheidet sich von den üblichen: 241.9.8.7.in-addr.arpa .

Hände eine solche Anfrage wird problematisch sein. Und wenn es klappt, ist immer noch nicht klar, wie man es im wirklichen Leben anwendet. Schließlich antwortet uns auf Anfrage von 7.8.9.241 immer noch der DNS des Anbieters und nicht der Client.

Und hier kommt CNAME ins Spiel.

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

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

Dies ist für fleißige =).

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

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

Jetzt wird die Informationsanfrage unter 7.1.9.241 von 241.9.8.7.in-addr.arpa auf dem DNS -Server des Anbieters in 241.255-240.9.8.7.in-addr.arpa konvertiert und an den DNS-Client weitergeleitet.

Der Client muss solche Anforderungen bearbeiten. Dementsprechend erstellen wir eine Zone von 255-240.9.8.7.in-addr.arpa . Darin können wir grundsätzlich Reverse-Datensätze für jede IP des gesamten / 24-Subnetzes veröffentlichen, aber wir werden nur nach denen gefragt, die der Anbieter an uns weiterleitet, sodass Sie nicht herumspielen können =).
Zur Veranschaulichung werde ich ein Beispiel für den Inhalt der Reverse-Zone-Datei auf der Clientseite geben:

 $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. 

Hier erhalten wir aufgrund der Tatsache, dass wir CNAME seitens des Anbieters verwenden, zwei Datensätze als Antwort auf eine Anforderung von Daten nach IP-Adresse und 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. 

Vergessen Sie nicht, die ACL korrekt zu konfigurieren. Weil es keinen Sinn macht, eine PTR-Zone für sich zu nehmen und niemandem von außen zu antworten =).