Делегировать / 22 легко, это делегирование 4/24. A / 14 - делегирование 4/16 и т. Д.
RFC2317 покрывает особые случаи с маской больше, чем / 24. В принципе, нет никакого сверхчистого способа делегирования зон in-addr.arpa ни на чем, кроме границ октетов, но вы можете обойти это. Допустим, я хочу делегировать 172.16.23.16/29, которые будут IP-адресами 172.16.23.16 -> 172.16.23.23.
Как владелец зоны 23.16.172.in-addr.arpa, я мог бы поместить это в файл зоны 23.16.172.rev, чтобы делегировать этот диапазон моему клиенту:
16-29 IN NS ns1.customer.com
16-29 IN NS ns2.customer.com
16 IN CNAME 16.16-29.23.16.172.in-addr.arpa.
17 IN CNAME 17.16-29.23.16.172.in-addr.arpa.
18 IN CNAME 18.16-29.23.16.172.in-addr.arpa.
19 IN CNAME 19.16-29.23.16.172.in-addr.arpa.
20 IN CNAME 20.16-29.23.16.172.in-addr.arpa.
21 IN CNAME 21.16-29.23.16.172.in-addr.arpa.
22 IN CNAME 22.16-29.23.16.172.in-addr.arpa.
23 IN CNAME 23.16-29.23.16.172.in-addr.arpa.
Итак, вы можете видеть, что я определяю новую зону (16-29.23.16.172.in-addr.arpa.) И делегирую ее на серверы имен моего клиента. Затем я создаю CNAME из IP-адресов, которые будут делегированы на соответствующий номер в новой делегированной зоне.
Как клиент, которому они были делегированы, я бы сделал что-то вроде следующего в named.conf:
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
А затем в файле .rev я бы просто сделал PTR как любую обычную зону in-addr.arpa:
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
Это своего рода чистый способ сделать это, и он радует опытных клиентов, потому что у них есть зона in-addr.arpa для размещения PTR и т. Д. Более короткий способ сделать это для клиентов, которые хотят контролировать обратный DNS, но не Чтобы создать целую зону, нужно просто присвоить индивидуальной записи CNAME похожие имена в основной зоне.
В этом случае мы, делегаты, будем иметь что-то подобное в нашем файле 23.16.172.rev:
16 IN CNAME 16.customer.com.
17 IN CNAME 17.customer.com.
18 IN CNAME 18.customer.com.
19 IN CNAME 19.customer.com.
20 IN CNAME 20.customer.com.
21 IN CNAME 21.customer.com.
22 IN CNAME 22.customer.com.
23 IN CNAME 23.customer.com.
Таким образом, в принципе это похоже на другую идею, но вместо того, чтобы создавать новую зону и делегировать ее клиенту, вы CNAME присваиваете записи именам в уже существующей основной зоне клиента.
У клиента будет что-то вроде этого в файле зоны customer.com:
office IN A 172.16.23.17
17 IN PTR office.customer.com.
www IN A 172.16.23.18
18 IN PTR www.customer.com.
(etc)
Это зависит только от типа клиента. Как я уже сказал, это зависит только от типа клиента. Опытный клиент предпочтет создать собственную зону in-addr.arpa и сочтет очень странным иметь PTR в зоне доменного имени. Неопытный клиент захочет, чтобы он «просто работал», не прибегая к тонне дополнительной настройки.
Есть, вероятно, другие методы, просто подробно описывающие два, с которыми я знаком.
Я просто размышлял о своем утверждении о том, как легко справляются / 22 и / 14, и думал о том, почему это правда, но что-то между 25 и 32 сложно. Я не проверял это, но я хотел бы, чтобы вы могли делегировать весь / 32 клиенту следующим образом:
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
Затем на стороне клиента вы поймаете все / 32:
zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)
И тогда в отдельном файле у вас будет что-то вроде этого:
@ IN PTR office.customer.com.
Очевидным недостатком является то, что один файл на / 32 является грубым. Но держу пари, это сработает.
Все, что я упомянул, это чистый DNS, если какой-либо DNS-сервер не позволил вам сделать это, это ограничивает полную функциональность DNS. Мои примеры, очевидно, используют BIND, но мы сделали это на стороне клиента, используя Windows DNS и BIND. Я не вижу причин, по которым он не будет работать ни с одним сервером.