Обратный DNS, похоже, сильно привязан к границам классов, какие методы существуют сейчас, когда CIDR является стандартом для делегирования полномочий для подсети? Если существует несколько методов, какой из них лучше? Вам нужно по-разному обрабатывать делегирование в зависимости от DNS-сервера (Bind, djbdns, Microsoft DNS, другие)? Допустим, у меня есть контроль над сетью класса B 168.192.in-addr.arpa, пожалуйста, предоставьте примеры для:
Делегировать / 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.
Таким образом, это похоже на концепцию другой идеи, но вместо того, чтобы создавать новую зону и делегировать ее клиенту, вы привязываете записи к именам в уже существующей основной зоне клиента.
В файле зоны 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. Я не вижу причин, по которым это не сработает ни с одним сервером.
Да, RFC 2317, очень хорошее чтение, это путь.
Также, моя статья (На французском).
BIND имеет собственный макрос $ GENERATE для создания последовательностей записей PTR, но он также предполагает классовый мир и не будет для вас очень полезным. Я не знаю других серверов, которые имеют специальную поддержку обратных зон CIDR, хотя подозреваю, что на это есть спрос!
PowerDNS имеет красивый внутренний интерфейс, который позволит вам написать свой собственный, если проблема достаточно велика, чтобы оправдать затраченные усилия. Вы также можете создать прототип с помощью «PipeBackend». Вы даже можете делать некоторые волшебные вещи SQL через интерфейсы MySQL / PostgreSQL - тем более, что Postgres имеет тип данных cidr.
http://aa.net.uk/kb-domains-reversedns.html (примерно на полпути вниз) объясняет, как мой интернет-провайдер выполняет обратный DNS. Я подозреваю, что любой способ сделать это будет чертовски уродливо.