Eines Tages stand ich vor der Aufgabe, einem meiner Kunden das Recht zur Bearbeitung der PTR-Einträge des ihm zugewiesenen Subnetzes /28 zu gewähren. Da ich keine Automatisierung zur Bearbeitung der BIND-Einstellungen von außen habe, beschloss ich, einen anderen Weg zu gehen – ich delegiere einen Teil der PTR-Zone des Subnetzes /24 an den Kunden.
Es scheint einfach zu sein. Man gibt einfach das Subnetz richtig an und verweist auf den entsprechenden NS, wie man es mit einem Subdomain macht. Aber so einfach ist es nicht (obwohl es in der Praxis wirklich trivial ist, aber die Intuition hilft nicht), deshalb schreibe ich diesen Artikel.
Wer selbst herausfinden möchte, kann die
lesen. Wer eine fertige Lösung möchte, ist herzlich eingeladen, weiterzulesen.
Um diejenigen, die die Copy-Paste-Methode lieben, nicht aufzuhalten, beginne ich mit dem praktischen Teil, gefolgt von dem theoretischen.
1. Praxis. Delegation der Zone /28.
Angenommen, wir haben ein Subnetz 7.8.9.0/24. Wir müssen das Subnetz delegieren 7.8.9.240/28 an den DNS-Kunden 7.8.7.8 (ns1.client.domain.).
Im Provider-DNS müssen wir die Datei finden, die die Reverse-Zone dieses Subnetzes beschreibt. Nehmen wir an, das ist 9.8.7.in-addr.arpa..
Die Einträge von 240 bis 255 kommentieren wir, wenn vorhanden. Und am Ende der Datei schreiben wir Folgendes:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240Vergessen Sie nicht, die Serial-Zonen zu erhöhen und führen Sie aus
rndc reloadDamit ist der Anbieterteil abgeschlossen. Wir wechseln zum Kundendns.
Lassen Sie uns zunächst eine Datei erstellen /etc/bind/master/255-240.9.8.7.in-addr.arpa kubectl-img
$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 named.conf fügen wir 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";
};Wir starten den Bind-Prozess neu.
/etc/init.d/named restartFertig. Jetzt können wir ü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-Eintrag, sondern auch der CNAME zurückgegeben wird. Das sollte so sein. Wenn Sie wissen möchten, warum, sind Sie in Kapitel zwei herzlich eingeladen.
2. Theorie. Wie funktioniert das.
Es ist schwierig, ein Black Box einzurichten und zu debuggen. Es ist viel einfacher, wenn man versteht, was im Inneren passiert.
Wenn wir einen Subdomain im Domain domain, delegieren, schreiben wir etwas wie dies:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Wir sagen allen, die fragen, dass wir für diesen Abschnitt nicht verantwortlich sind und da wir mitteilen, wer verantwortlich ist. Und alle Anfragen an client.domain werden auf 7.8.7.8 umgeleitet. Bei der Überprüfung sehen wir folgendes Bild (lassen wir weg, was beim Kunden ist. Das ist nicht wichtig):
# host test.client.domain
test.client.domain has address 7.8.9.241Das heißt, uns wurde mitgeteilt, dass es diesen A-Eintrag gibt und seine IP 7.8.9.241 ist. Keine zusätzlichen Informationen.
Wie kann man dasselbe mit einem Subnetz machen?
Da unser DNS-Server in RIPE eingetragen ist, wird bei der Anfrage nach PTR für eine IP-Adresse aus unserem Netzwerk die erste Anfrage trotzdem an uns gerichtet. Die Logik ist dieselbe wie bei Domains. Aber wie trägt man das Subnetz in die Zonen-Datei ein?
Wir probieren es so einzutragen:
255-240 IN NS 7.8.7.8Und… das Wunder ist nicht passiert. Wir erhalten keine Weiterleitung der Anfrage. Das Ganze liegt daran, dass bind überhaupt nicht weiß, dass diese Einträge in der umgekehrten Zonen-Datei IP-Adressen sind und schon gar nicht versteht, was ein Bereichseintrag ist. Für ihn ist das einfach ein gewisser symbolischer Subdomains. Das heißt, für bind macht es keinen Unterschied zwischen „255-240» und «oursuperclient«. Damit die Anfrage an das richtige Ziel gesendet wird, muss die Adresse in der Anfrage so aussehen: 241.255-240.9.8.7.in-addr.arpa. Oder so, wenn wir eine symbolische Subdomain verwenden: 241.oursuperclient.9.8.7.in-addr.arpa. Das unterscheidet sich von der normalen: 241.9.8.7.in-addr.arpa.
Mit einem solchen Anfrage könnte es schwierig sein, dies manuell zu erledigen. Selbst wenn es gelingt, ist unklar, wie man es in der Praxis umsetzt. Denn auf die Anfrage 7.8.9.241 antwortet weiterhin der DNS-Server des Anbieters und nicht der des Clients.
Hier kommen dann CNAME.
ins Spiel. Auf der Seite des Anbieters müssen für alle IP-Adressen des Subnetzes Aliase in einem Format erstellt werden, das die Anfrage an den clientseitigen DNS weiterleitet.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
usw.
Das ist für die Fleißigen =).
Für die Fauleren ist die folgende Konstruktion besser geeignet:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Jetzt wird die Anfrage nach Informationen zu der Adresse 7.8.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 umgewandelt und an den DNS des Clients weitergeleitet.
Auf der Seite des Clients müssen solche Anfragen verarbeitet werden. Entsprechend erstellen wir die Zone 255-240.9.8.7.in-addr.arpa. In dieser können grundsätzlich rückwärtsgerichtete Einträge für beliebige IPs des gesamten Subnetzes /24 untergebracht werden, aber es werden nur die angefragt, die der Anbieter an uns weiterleitet, sodass wir uns nicht austoben können =).
Zur Veranschaulichung gebe ich nochmals ein Beispiel für den Inhalt der Reverse-Zone auf der Clientseite:
$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.
Da wir auf Seiten des Providers CNAME verwenden, erhalten wir als Antwort auf die Abfrage bezüglich der IP-Adresse zwei Einträge statt einem.
#> 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 einzustellen. Es ist schließlich sinnlos, sich die PTR-Zone zu nehmen und nicht auf externe Anfragen zu reagieren =).
Quelle: habr.com
