Проблема с разрешением имён в обратной зоне Ubuntu10.10 Bind9

[ITD27M01]

Вот. Теперь поехали дальше.

Мой сервер по каким-то причинам не воспринимает себя как авторитетного за разрешение ip адресов в подсети 192.168.1.0/28

Простой пример

nslookup на сервер провайдера, разрешаем адрес 192.168.1.1

Server:         ns0.isp.ru
Address:        1.2.3.4#53

1.1.168.192.in-addr.arpa      canonical name = 1.0/28.1.168.192.in-addr.arpa.
1.0/28.1.168.192.in-addr.arpa        name = ns.domain.ru.
1.0/28.1.168.192.in-addr.arpa        name = mail.domain.ru.

nslookup на мой сервер, тот же адрес

Server:         ns.domain.ru
Address:        192.168.1.1#53

Non-authoritative answer:
1.1.168.192.in-addr.arpa      canonical name = 1.0/28.1.168.192.in-addr.arpa.
1.0/28.1.168.192.in-addr.arpa        name = ns.domain.ru.
1.0/28.1.168.192.in-addr.arpa        name = mail.domain.ru.

Authoritative answers can be found from:
0/28.1.168.192.in-addr.arpa   nameserver = ns0.isp.ru.
0/28.1.168.192.in-addr.arpa   nameserver = ns.domain.ru.
0/28.1.168.192.in-addr.arpa   nameserver = ns1.isp.ru.
ns.domain.ru      internet address = 192.168.1.1
ns0.isp.ru      internet address = 1.2.3.4
ns1.isp.ru      internet address = 1.2.3.5


Далее, я отключаю рекурсию для всего сервера в
option { ...
recursion no;
...
};
Пытаюсь разрешить адрес 192.168.1.1 и сервер про него ничего не знает (каннот финд шиз домен). Я проверил с помощью host -t SOA серийные номера моей обратной зоны на dns провайдера, по сему - зона стягивается туда. При этом прямая зона на моём сервере работает.
Ответы одинаковы для утилиты dig, но различны для nslookup как я привёл пример выше.
По сему делаю вывод, что мой сервер не хочет воспринимать себя как авторитетный сервер для обратной зоны подсети 192.168.1.1/28, а передаёт запрос на форварды или на руты если включена рекурсия.

[Karl500]

Насколько я представляю себе работу DNS (в частности, обратных зон) - то и не будет Ваш сервер "ответственным" за обратную зону. Обратная зона имеет принципиальное отличие от прямой - за нее отвечает провайдер. И он только делегирует Вам право на размещение PTR-записей в "кусочке" этой зоны (оставаясь "ответственным" за зону класса C).
В этом и отличие от прямой зоны - там минимальным "квантом" служит сама зона, в обратной же - подсеть класса C.

[ITD27M01]

Спасибо.
Итак, картина для меня такая получается. Провайдер делегирует мне возможность создания в обратной зоне PTR записей, но не делегирует возможность управления обратной зоной для подсети как это делается для поддомена в прямой зоне. Я создаю запись в прямой зоне, создаю PTR запись в обратной зоне на своём сервере, эта обратная зона стягивается на ns провайдера, который содержит зону для сети класса C и только после этого всё устаканивается?

В RFC это написано интересно?

[Karl500]

Почему не делегирует? Управляйте - нет вопросов. Если Вы смените у себя в обратной зоне запись (к примеру)
1     IN      PTR      ns.domain.ru.
на
1     IN      PTR      another.domain.ru.
то эта информация попадет в зону у провайдера и, ссответственно, будет доступна всем (через какое-то время, естественно).

[ITD27M01]

Немного не так, я щас вник в RFC и ситуация следующая.

У провайдера в обратной зоне, соответствующей сети класса C создан CNAME направляющий запросы на мой сервер в зону 0/28.1.168.192.in-addr.arpa
пример

1 CNAME 1.0/28.1.168.192.in-addr.arpa
0/28.1.168.192.in-addr.arpa NS ns.domain.ru

моя зона 0/28.1.168.192.in-addr.arpa не является в полном смысле слова обратной зоной. Это зона в домене in-addr.arpa, содержащая мои PTR записи. На эти записи ссылаются вышеуказанные CNAME, когда я меняю PTR на сервер провайдера ничего не уходит, там всё остаётся как есть - CNAME.

Спасибо большое!

[Karl500]

(продолжает) а зона 0/28.1.168.192.in-addr.arpa - и есть та зона, которой Вы управляете. Т.е. мастер которой - у Вас (а слейв чаще всего у провайдера).

Так и в чем проблема-то?

Ясно, вопрос снят