Delegating the reverse zone subnet less than / 24 in BIND. How it works
Once I got up a task to give one of my clients the right to edit the PTR-records of the subnet given to him / 28. I don’t have automation for editing BIND settings from outside. Therefore, I decided to go the other way - to delegate to the client a piece of PTR-zone of the subnet / 24.
It would seem - what could be easier? Simply, we prescribe the subnet in the right way and direct it to the desired NS as it is done with the subdomain. But no. Everything is not so simple (although in reality it is generally primitive, but intuition will not help), therefore I am writing this article.
Who wants to figure it out for himself can read the RFC
Who wants the ready decision, welcome under kat.
In order not to delay those who love the copy-paste method, first I will place the practical part, and after it the theoretical part.
')
1. Practice. Delegating a zone / 28
Suppose we have a subnet 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 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 .
Records from 240 to 255 comment, if any. And at the end of the file we write the following:
Do not forget to increase the serial zone and do
At this provider part is over. Go to the client dns.
First, create the file /etc/bind/master/255-240.9.8.7.in-addr.arpa with the following content:
And in named.conf we add the description of our new file:
Restart the bind process.
Everything. Now you can check.
Please note that not only a PTR record is sent, but also a CNAME. It should be so. If you are wondering why, then welcome to the next chapter.
2. Theory. How it works.
It is difficult to configure and debug the black box. Much easier if you understand what's going on inside.
When we delegate a subdomain in the domain domain , we write something like this:
We tell everyone who asks that we are not responsible for this site and we say who is responsible. And all requests for client.domain will redirect 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.
And how can the same be done with a subnet?
Because our DNS server is registered in RIPE, then when requesting a PTR ip address from our network, the first request will still be to us. The logic is the same as with domains. That's just how to enter the subnet in the zone file?
We try to write it like this:
And ... the miracle did not happen. We do not receive any request redirection. The thing is that bind is not aware that these records in the reverse zone file are ip-addresses and certainly do not understand the range entry. For him, it's just some kind of 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 is necessary, the address in the request should look like this: 241.255-240.9.8.7.in-addr.arpa . Or like this, if we use the symbolic 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, it’s still not clear how to apply it in real life. After all, on request 7.8.9.241 , the provider DNS still responds to us, not the client.
And here come the game CNAME .
On the provider side, you need to make an alias for all ip-addresses of the subnet in a format that will forward the request to client DNS.
This is for hardworking =).
And for the lazy more suitable design below:
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 go to the dns client.
On the client side, you will need to handle such requests. Accordingly, we create a zone of 255-240.9.8.7.in-addr.arpa . We can, in principle, place reverse entries for any ip of the entire subnet / 24, but we will only be asked about those that the provider will redirect to us, so it’s impossible to indulge =).
To illustrate, once again I will give an example of the content of the reverse zone file from the client:
This is due to the fact that we, from the provider’s side, use CNAME, and we receive in response to a request for data on the ip-address two records, and not one.
And do not forget to properly configure the ACL. Because it makes no sense to pick up a PTR-zone and not respond to anyone from the external =).
It would seem - what could be easier? Simply, we prescribe the subnet in the right way and direct it to the desired NS as it is done with the subdomain. But no. Everything is not so simple (although in reality it is generally primitive, but intuition will not help), therefore I am writing this article.
Who wants to figure it out for himself can read the RFC
Who wants the ready decision, welcome under kat.
In order not to delay those who love the copy-paste method, first I will place the practical part, and after it the theoretical part.
')
1. Practice. Delegating a zone / 28
Suppose we have a subnet 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 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 .
Records from 240 to 255 comment, if any. And at the end of the file we write the following:
255-240 IN NS 7.8.7.8 $GENERATE 240-255 $ CNAME $.255-240 Do not forget to increase the serial zone and do
rndc reload At this provider part is over. Go to the client dns.
First, create the file /etc/bind/master/255-240.9.8.7.in-addr.arpa with the following content:
$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 we 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"; }; Restart the bind process.
/etc/init.d/named restart Everything. 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 a PTR record is sent, but also a CNAME. It should be so. If you are wondering why, then welcome to the next chapter.
2. Theory. How it works.
It is difficult to configure and debug the black box. Much easier if you understand what's going on 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.8 We tell everyone who asks that we are not responsible for this site and we say who is responsible. And all requests for client.domain will redirect 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.241 Those. We were informed that there is such an A record and its ip 7.8.9.241. No unnecessary information.
And how can the same be done with a subnet?
Because our DNS server is registered in RIPE, then when requesting a PTR ip address from our network, the first request will still be to us. The logic is the same as with domains. That's just how to enter the subnet in the zone file?
We try to write it like this:
255-240 IN NS 7.8.7.8 And ... the miracle did not happen. We do not receive any request redirection. The thing is that bind is not aware that these records in the reverse zone file are ip-addresses and certainly do not understand the range entry. For him, it's just some kind of 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 is necessary, the address in the request should look like this: 241.255-240.9.8.7.in-addr.arpa . Or like this, if we use the symbolic 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, it’s still not clear how to apply it in real life. After all, on request 7.8.9.241 , the provider DNS still responds to us, not the client.
And here come the game CNAME .
On the provider side, you need to make an alias for all ip-addresses of the subnet in a format that will forward the request to 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 more suitable design below:
255-240 IN NS ns1.client.domain. $GENERATE 240-255 $ CNAME $.255-240 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 go to the dns client.
On the client side, you will need to handle such requests. Accordingly, we create a zone of 255-240.9.8.7.in-addr.arpa . We can, in principle, place reverse entries for any ip of the entire subnet / 24, but we will only be asked about those that the provider will redirect to us, so it’s impossible to indulge =).
To illustrate, once again I will give an example of the content of the reverse zone file from the client:
$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. This is due to the fact that we, from the provider’s side, use CNAME, and we receive in response to a request for data on the ip-address two records, and 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 properly configure the ACL. Because it makes no sense to pick up a PTR-zone and not respond to anyone from the external =).
Source: https://habr.com/ru/post/451890/
All Articles