May 15, 2019 at 12:37Delegation of a reverse subnet zone of less than / 24 in BIND. How it works
- Tutorial
Once I faced the task of giving one of the clients the right to edit the PTR records of the subnet assigned to it / 28. I do not have automation for editing BIND settings from the outside. So I decided to go the other way - to delegate to the client a piece of the PTR / 24 subnet zone.
It would seem - what could be easier? We just prescribe the subnet in the right way and direct it to the desired NS as it is done with the subdomain. But no. It's not so simple (although in reality it’s generally primitive, but intuition will not help), that's why I am writing this article.
Who wants to figure it out for himself can read the RFC.
Who wants a ready-made solution, welcome to cat.
In order not to delay those who like copy-paste method, first I will post the practical part, and after it the theoretical part.
1. Practice. We delegate zone / 28.
Let's say we have a subnet of 7.8.9.0/24 . We need to delegate the subnet 7.8.9.240/28 to the dns client 7.8.7.8 ( ns1.client.domain ).
On the provider DNS you need to find a file that describes the reverse zone of this subnet. Let it be 9.8.7.in-addr.arpa .
Posts from 240 to 255 are commented, if any. And at the end of the file, write the following:
don't forget to increase serial zones and do
On this, the provider part is over. We pass to client dns.
First, create the /etc/bind/master/255-240.9.8.7.in-addr.arpa file with the following contents:
And in named.conf, add the description of our new file:
B restart the bind process.
All. Now you can check.
Please note that not only the PTR record is given, but also CNAME. It should be so. If you wonder why, then welcome to the next chapter.
2. Theory. How it works.
It is difficult to configure and debug a black box. Much easier if you understand what is happening inside.
When we delegate a subdomain in the domain domain , we write something like this:
We tell everyone asking that we are not responsible for this site and we say who is responsible. And all requests to client.domain are redirected to 7.8.7.8. When checking, we see the following picture (omit what the client has there. It doesn’t matter):
Those. we were informed that there is such an A record and its ip 7.8.9.241. No unnecessary information.
But how can the same thing be done with a subnet?
Because Since our DNS server is registered in RIPE, when requesting a PTR IP address from our network, the first request will still be sent to us. The logic is the same as with domains. But just how to enter the subnet in the zone file?
We try to enter it like this:
And ... a miracle did not happen. We do not receive any request redirection. The thing is that bind is not at all aware that these entries in the reverse zone file are ip-addresses and even more so they do not understand the range entry. For him, this is just a symbolic subdomain. Those. for bind there will be no difference between " 255-240 " and " oursuperclient ". And the request for the request to go where it should be, the address in the request should look like this: 241.255-240.9.8.7.in-addr.arpa . Or like this, if we use a character subdomain: 241.oursuperclient.9.8.7.in-addr.arpa . This is different from the usual: 241.9.8.7.in-addr.arpa .
Hands such a request will be problematic. And if it works out, it’s still not clear how to apply it in real life. After all, at the request of 7.8.9.241 , the provider DNS, and not the client one, still answers to us.
And here CNAME comes into play .
On the provider side, you need to make an alias for all the IP addresses of the subnet in a format that will forward the request to the client DNS.
This is for hardworking =).
And for the lazy, the design below is more suitable:
Now the request for information at 7.8.9.241 from 241.9.8.7.in-addr.arpa on the provider's dns server will be converted to 241.255-240.9.8.7.in-addr.arpa and will go to the dns client.
The client will need to process such requests. Accordingly, we create a zone of 255-240.9.8.7.in-addr.arpa . In it, we can basically post reverse records for any ip of the entire / 24 subnet, but we will only be asked about those that the provider will redirect to us, so you won’t be able to play around =).
To illustrate, I will give an example of the contents of the reverse zone file on the client side:
That's due to the fact that we use CNAME on the part of the provider, and in response to a request for data at the ip-address we get two records, not one.
And do not forget to correctly configure the ACL. Because it makes no sense to take a PTR-zone for yourself and not answer anyone from the outside =).
It would seem - what could be easier? We just prescribe the subnet in the right way and direct it to the desired NS as it is done with the subdomain. But no. It's not so simple (although in reality it’s generally primitive, but intuition will not help), that's why I am writing this article.
Who wants to figure it out for himself can read the RFC.
Who wants a ready-made solution, welcome to cat.
In order not to delay those who like copy-paste method, first I will post the practical part, and after it the theoretical part.
1. Practice. We delegate zone / 28.
Let's say we have a subnet of 7.8.9.0/24 . We need to delegate the subnet 7.8.9.240/28 to the dns client 7.8.7.8 ( ns1.client.domain ).
On the provider DNS you need to find a file that describes the reverse zone of this subnet. Let it be 9.8.7.in-addr.arpa .
Posts from 240 to 255 are commented, if any. And at the end of the file, write the following:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240don't forget to increase serial zones and do
rndc reloadOn this, the provider part is over. We pass to client dns.
First, create the /etc/bind/master/255-240.9.8.7.in-addr.arpa file with the following contents:
$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.
And in named.conf, add the description of our new file:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B restart the bind process.
/etc/init.d/named restartAll. Now you can check.
#> 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.Please note that not only the PTR record is given, but also CNAME. It should be so. If you wonder why, then welcome to the next chapter.
2. Theory. How it works.
It is difficult to configure and debug a black box. Much easier if you understand what is happening inside.
When we delegate a subdomain in the domain domain , we write something like this:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8We tell everyone asking that we are not responsible for this site and we say who is responsible. And all requests to client.domain are redirected to 7.8.7.8. When checking, we see the following picture (omit what the client has there. It doesn’t matter):
# host test.client.domain
test.client.domain has address 7.8.9.241Those. we were informed that there is such an A record and its ip 7.8.9.241. No unnecessary information.
But how can the same thing be done with a subnet?
Because Since our DNS server is registered in RIPE, when requesting a PTR IP address from our network, the first request will still be sent to us. The logic is the same as with domains. But just how to enter the subnet in the zone file?
We try to enter it like this:
255-240 IN NS 7.8.7.8And ... a miracle did not happen. We do not receive any request redirection. The thing is that bind is not at all aware that these entries in the reverse zone file are ip-addresses and even more so they do not understand the range entry. For him, this is just a symbolic subdomain. Those. for bind there will be no difference between " 255-240 " and " oursuperclient ". And the request for the request to go where it should be, the address in the request should look like this: 241.255-240.9.8.7.in-addr.arpa . Or like this, if we use a character subdomain: 241.oursuperclient.9.8.7.in-addr.arpa . This is different from the usual: 241.9.8.7.in-addr.arpa .
Hands such a request will be problematic. And if it works out, it’s still not clear how to apply it in real life. After all, at the request of 7.8.9.241 , the provider DNS, and not the client one, still answers to us.
And here CNAME comes into play .
On the provider side, you need to make an alias for all the IP addresses of the subnet in a format that will forward the request to the client DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
This is for hardworking =).
And for the lazy, the design below is more suitable:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Now the request for information at 7.8.9.241 from 241.9.8.7.in-addr.arpa on the provider's dns server will be converted to 241.255-240.9.8.7.in-addr.arpa and will go to the dns client.
The client will need to process such requests. Accordingly, we create a zone of 255-240.9.8.7.in-addr.arpa . In it, we can basically post reverse records for any ip of the entire / 24 subnet, but we will only be asked about those that the provider will redirect to us, so you won’t be able to play around =).
To illustrate, I will give an example of the contents of the reverse zone file on the client side:
$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.
That's due to the fact that we use CNAME on the part of the provider, and in response to a request for data at the ip-address we get two records, not one.
#> 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.And do not forget to correctly configure the ACL. Because it makes no sense to take a PTR-zone for yourself and not answer anyone from the outside =).