Зворотний DNS, здається, сильно прив’язаний до меж класу, які методи існують тепер, коли CIDR є стандартом для делегування повноважень для підмережі? Якщо існує кілька методів, який із них найкращий? Чи потрібно по-різному обробляти делегування залежно від сервера DNS (Bind, djbdns, Microsoft DNS та інші)? Скажімо, я маю контроль над мережею, яка є класом B 168.192.in-addr.arpa, будь ласка, надайте приклади для:
Відповіді:
Делегувати a / 22 легко, це делегування 4/24. A / 14 - це делегація 4/16-х років тощо.
RFC2317 охоплює особливі випадки з мережевою маскою довше ніж / 24. В основному, немає надзвичайно чистого способу зробити делегування зон inadadr.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-адрес, щоб їх було делеговано відповідному номеру в новоделегованій зоні.
Як замовник, якому вони були делеговані, я б зробив щось подібне в найменуванні.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)
Це такий чистий спосіб зробити це, і це робить кмітливим клієнтом щасливим, оскільки у них є зона inadadr.arpa, щоб поставити PTR і т. Д. Коротший спосіб зробити це для клієнтів, які хочуть контролювати зворотний DNS, але не ' t хочете створити цілу зону - це просто записувати окремий запис 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.
Тож вона за принципом схожа на іншу ідею, але замість того, щоб створювати нову зону та делегувати її замовнику, ви CNAMEE записуєте на імена у вже існуючій головній зоні клієнта.
Клієнт матиме щось подібне у своєму зоні-файлі 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. Я підозрюю, що будь-який спосіб ви зробите це буде некрасиво, як пекло.