Op een dag stond ik voor de taak om één van mijn klanten het recht te geven om PTR-records te bewerken voor het hem toegewezen subnet /28. Ik heb geen automatisering voor het extern bewerken van BIND-instellingen. Daarom besloot ik een andere weg te volgen: de klant een stuk PTR-zone van het subnet /24 te delegeren.
Het lijkt misschien simpel genoeg? Gewoon het subnet op de juiste manier invoeren en deze naar de juiste NS verwijzen, net zoals met subdomeinen. Maar dat is het niet. Het is niet zo eenvoudig (hoewel het eigenlijk vrij primitief is, maar intuïtie helpt niet), daarom schrijf ik dit artikel.
Wie zelf wil begrijpen, kan het lezen.
Wie een kant-en-klaar oplossing wil, is welkom onder de kat.
Om degenen die van knippen en plakken houden niet in de weg te zitten, plaats ik eerst het praktische deel en daarna het theoretische.
1. Praktijk. We delegeren het zone /28.
Stel dat we een subnet hebben. 7.8.9.0/24. We moeten het subnet delegeren. 7.8.9.240/28 aan de dns-cliënt. 7.8.7.8 (ns1.client.domain).
Op de provider DNS moet je het bestand vinden dat de omgekeerde zone van dit subnet beschrijft. Laten we zeggen dat het 9.8.7.in-addr.arpa.
Records van 240 tot 255 kunnen worden gecommenteerd als die er zijn. En aan het einde van het bestand schrijven we het volgende:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240vergeet niet het serienummer van de zone te verhogen en voer
rndc reloadDaarmee is het providerdeel klaar. Laten we overgaan naar de client DNS.
Laten we eerst een bestand aanmaken. /etc/bind/master/255-240.9.8.7.in-addr.arpa met de volgende inhoud:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serienummer
3H ; verversing
15M ; herhaling
1W ; vervaldatum
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.
En in named.conf voeg een beschrijving van ons nieuwe bestand toe:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};We herstarten het bindproces.
/etc/init.d/named restartDat is het. Nu kunnen we het controleren.
#> 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.Let op dat niet alleen het PTR-record wordt teruggegeven, maar ook het CNAME. Dat is zoals het hoort. Als je benieuwd bent waarom, dan ben je welkom in het volgende hoofdstuk.
2. Theorie. Hoe het werkt.
Het is moeilijk om een zwart kastje in te stellen en te debuggen. Het is veel eenvoudiger als je weet wat er binnenin gebeurt.
Wanneer we een subdomein in een domein domein, schrijven we iets als dit:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8We tell everyone who asks that we are not responsible for this zone and indicate who is responsible. And all requests to client.domain are redirected to 7.8.7.8. When we check, we see the following picture (let's skip what the client has, that’s not important):
# host test.client.domain
test.client.domain has address 7.8.9.241That is, we were informed that there is such an A record and its IP is 7.8.9.241. No extra information.
And how can the same thing be done with a subnet?
Since our DNS server is registered in RIPE, when a PTR query for an IP address from our network is made, the first request will still be to us. The logic is the same as with domains. The only question is how to write the subnet in the zone file?
We try to write it like this:
255-240 IN NS 7.8.7.8And... the miracle didn't happen. We do not receive any request redirection. The thing is that bind is not even aware that these records in the reverse zone file are IP addresses, and even less does it understand the range record. To it, this is just some symbolic subdomain. That is to say, there will be no difference for bind between "255-240» en «oursuperclient". And for the request to go where it should, the address in the request must look like this: 241.255-240.9.8.7.in-addr.arpa. Or like this, if we use a symbolic subdomain: 241.oursuperclient.9.8.7.in-addr.arpa. This differs from the usual: 241.9.8.7.in-addr.arpa.
It will be problematic to make such a request by hand. And even if it succeeds, it's still unclear how to apply it in real life. Indeed, for the request 7.8.9.241 we are still answered by the provider's DNS, not the client's.
And here comes in CNAME.
On the provider's side, an alias in the format needed to redirect queries to the client's DNS must be created for all IP addresses in the subnet.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
and so on.
This is for the diligent =).
And for the lazy, the following construction is more suitable:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Now, the request for information at the address 7.8.9.241 uit 241.9.8.7.in-addr.arpa on the provider’s DNS server will be transformed into 241.255-240.9.8.7.in-addr.arpa and sent to the DNS client.
On the client's side, such queries need to be processed. Accordingly, we create a zone 255-240.9.8.7.in-addr.arpa. In it, we can generally place reverse records for any IP of the entire /24 subnet, but they will only ask us about those that the provider redirects to us, so we cannot play around =).
To illustrate, I will once again provide an example of the reverse zone file content from the client's side:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serienummer
3H ; verversing
15M ; herhaling
1W ; vervaldatum
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.
Omdat we aan de providerzijde CNAME gebruiken, krijgen we als reactie op het dataverzoek IP-adres twee records en geen één.
#> 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. Vergeet niet om ACL correct in te stellen. Het is immers nutteloos om jezelf de PTR-zone toe te eigenen en niet te reageren op iemand van buitenaf =).
Bron: habr.com
