Once I faced the task of giving one of the clients the right to edit the PTR records of the /28 subnet given to him. I don't have automation for editing BIND settings from the outside. Therefore, I decided to go the other way - to delegate to the client a piece of the /24 subnet PTR 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 is done with a subdomain. But no. Not everything is so simple (although in fact it is generally primitive, but intuition will not help), that's why I am writing this article.
Anyone who wants to figure it out for himself can read
Who wants a ready-made solution, welcome under cat.
In order not to delay those who love the copy-paste method, I will first post the practical part, and after that the theoretical part.
1. Practice. Delegate zone /28
Let's say we have a subnet 7.8.9.0/24. We need to delegate a subnet 7.8.9.240/28 on dns client 7.8.7.8 (ns1.client.domain).
On the provider's dns, you need to find a file describing the reverse zone of this subnet. Let it be 9.8.7.in-addr.harp.
We comment on entries from 240 to 255, if any. And write the following at the end of the file:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240do not forget to increase the serial zones and do
rndc reloadThis completes the provider part. Let's move on to the client dns.
First, let's create a file /etc/bind/master/255-240.9.8.7.in-addr.arpa 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 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 the CNAME. That's the way it should be. If you're wondering why, then welcome to the next chapter.
2. Theory. How it works.
Difficult to set up and debug the black box. Much easier if you understand what's going on inside.
When we delegate a subdomain in a domain domain, then we write something like this:
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 area and we say who is responsible. And all requests for client.domain redirect to 7.8.7.8. When checking, we see the following picture (we will 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 told that there is such an A record and its ip 7.8.9.241. No extra 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?
Let's try to type it like this:
255-240 IN NS 7.8.7.8And ... the miracle did not happen. We don't get any request redirect. The thing is that bind is not aware at all that these entries in the reverse zone file are ip-addresses, and even more so, it does not understand the range entry. For him, it's 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 is needed, 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 than usual: 241.9.8.7.in-addr.harp.
It will be problematic to make such a request by hand. And if it does, it's still not clear how to apply it in real life. After all, upon request 7.8.9.241 we are still answered by the provider's DNS, not the client's.
And this is where they come into play CNAME.
On the provider's side, you need to make an alias for all 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 the hardworking =).
And for the lazy, the design below is more suitable:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Now request information at 7.8.9.241 of 241.9.8.7.in-addr.harp 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.
From the client side, such requests will need to be processed. Accordingly, we create a zone 255-240.9.8.7.in-addr.arpa. In it, we can, in principle, place reverse entries for any ip of the entire /24 subnet, but we will only be asked about those that the provider redirects to us, so we wonβt be able to play around =).
To illustrate, I will once again give an example of the content of the reverse zone file from 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.
Because we use CNAME from the provider side, we get two records in response to a request for data at the ip address, 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 correctly configure ACLs. Because it makes no sense to take the PTR zone for yourself and not answer anyone from the outside =).
Source: habr.com