Обратный DNS в мире CIDR

Обратный DNS, кажется, сильно привязан к границам классов. Какие существуют методы, когда CIDR является стандартом для делегирования полномочий для подсети? Если существует несколько методов, какой из них лучше? Нужно ли обрабатывать делегирование по-разному в зависимости от DNS-сервера (Bind, djbdns, Microsoft DNS и т. Д.)? Допустим, у меня есть контроль над сетью класса B 168.192.in-addr.arpa. Пожалуйста, приведите примеры для:

• Как делегировать полномочия для а / 22?
• Как делегировать полномочия на / 25?

Делегировать / 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. Я не вижу причин, по которым он не будет работать ни с одним сервером.

Да, RFC 2317 , очень хорошее чтение, это путь.

Также моя статья (на французском).

BIND имеет собственный макрос $ GENERATE для создания последовательностей записей PTR, но он также предполагает классный мир и не будет очень полезен для вас. Я не знаю никаких других серверов, которые имеют особую поддержку обратных зон CIDR, хотя я подозреваю, что на это есть спрос!

PowerDNS имеет хороший внутренний интерфейс, который позволит вам написать свой собственный, если проблема достаточно велика, чтобы стоить усилий. Вы также можете создать прототип, используя "PipeBackend". Вы могли бы даже сделать некоторые магические действия с SQL через интерфейсы MySQL / PostgreSQL - тем более что Postgres имеет тип данных "cidr".

http://aa.net.uk/kb-domains-reversedns.html (примерно на полпути вниз) объясняет, как мой провайдер делает свой обратный DNS. Я подозреваю, что в любом случае это будет ужасно ужасно.