Добрый день.Возникли проблемы с разрешением адресов в обратной зоне, может кто сталкивался??
Предистория:
Подсеть из 16 адресов выдана провайдером, пусть например 192.168.1.0/28. Мы поднимаем у себя на Ubuntu 10.10 сервер, настраиваем DNS на bind9. Договариваемся с провайдером о делегировании нам зоны 0/28.1.168.192.in-addr.arpa. (RFC 2317)При настройке зоны (конфиги ниже) и перезапуске bind9 сервер отказывается разрешать адреса в имена, в syslog - зона загружена успешно с таким-то серийным номером. rndc и check-zone ошибок не выдаёт.
Просмотрел конфиги, заменил все <tab> на пробелы и заработало. Зона стягивается на вторичные серверы (у провайдера), адреса разрешаются, почта уходит.Сегодня заметили, что форвард, на который настроен наш bind некорректно разрешает ключевое для нас доменное имя, соответственно заменили форвард на правильный, но обратная зона при этом перестала работать. Проверил всё, убрал все табы, в syslog и rndc ошибок не показывает, зона не стягивается на вторичные серверы, адреса не разрешает, пока спасают вторичные серверы провайдера. И при этом прямая зона работает.
Соответсвенно конфиги
##################### named.conf.local
zone "0/28.1.168.192.in-addr.arpa" in{
type master;
notify yes;
allow-transfer { slave-servers; };
file "db.1.168.192";
};##################### db.1.168.192
;
; BIND reverse data file for local loopback interface
;
$ORIGIN .
$TTL 3600
0/28.1.168.192.in-addr.arpa IN SOA ns.domain.ru. postmaster.domain.ru. (
2011032201 ; Serial
3600 ; Refresh
86400 ; Retry
2419200 ; Expire
3600 ); Negative Cache TTL
IN NS ns.domain.ru.
IN NS ns0.isp.ru.
IN NS ns1.isp.ru.
;
$ORIGIN 0/28.1.168.192.in-addr.arpa.
1 IN PTR ns.domain.ru.
2 IN PTR mail.domain.ru.
3 IN PTR www.domain.ru.Заранее спасибо.
а что в конфиги-то смотреть. они что, сколь-нибудь нестандартны ?делаем трассировку:
debian:~# dnstracer -4s . 43.14.8.2.in-addr.arpa
Tracing to 43.14.8.2.in-addr.arpa[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ f.in-addr-servers.arpa [in-addr.arpa] (193.0.9.1)
| |\___ ns.provider.ru [14.8.2.in-addr.arpa] (7.10.10.13) Got authoritative answer [received type is cname]
| \___ ns2.provider.ru [14.8.2.in-addr.arpa] (7.10.11.13) Got authoritative answer [received type is cname]
Делаем запросы:
debian:~# host -t PTR 43.14.8.2.in-addr.arpa
43.14.8.2.in-addr.arpa is an alias for 43.0/25.14.8.2.in-addr.arpa.
43.0/25.14.8.2.in-addr.arpa domain name pointer mail.company.ru.
debian:~# host -t PTR 43.0/25.14.8.2.in-addr.arpa
43.0/25.14.8.2.in-addr.arpa domain name pointer mail.company.ru.
Спасибо, но я уже написал, что работают slave провайдеров, они мне выдают желаемый результат на запрос.
При использовании в качестве dns моего сервера, он говорит, что не является авторитетным для данной зоны, перебрасывает запрос на форварды, либо на root сервера если разрешена рекурсия. Если я ограничиваю рекурсию, то сервер сообщает, что не может найти запрашиваемый адрес.
кроме named.conf.local существует еще некоторое количество конфигов.Также, делайте стоп, старт, смотрите в логи.
В логах показывает, что зона для моей подсети загружена успешно с таким-то серийным номером. Опять же это я уже писал в начале.
Я закомментировал зоны типа 127.in-addr.arpa и т.п., задал порт и адрес прослушивания, но результат тот же.
> В логах показывает, что зона для моей подсети загружена успешно с таким-то
> серийным номером. Опять же это я уже писал в начале.
> Я закомментировал зоны типа 127.in-addr.arpa и т.п., задал порт и адрес прослушивания,
> но результат тот же.я вижу только то, что _вы думаете_ что _требуемая вами зона_ загружена успешно.
А какая _именно_ зона была загружена - этого никто не знает.
Хотите тренировать телепатию - успехов.Логов ВЫ не приводили, так что то, что вы писали в начале .... дает мало полезного для помощи вам.
Как дебажить - вам уже показано. все полезные команды, которые могут использоваться - приведены.
Логирование запросов - нах не нужно. нужно всего-лишь проверить и исправить ошибки.
Конфиги вы не приводите, в вашем случае при вашем количестве стеснения - рекомендую "виндовс-метод" - снести все и переустановить заново.Это единственный метод, который, на мой взгляд, может вам помочь в ситуации, которую вы создаете. Желаю успехов.
Ещё уточнение: bind отказывается разрешать ip адреса в имена в тот момент, когда я указываю имя зоны в classless нотации - 0/28.1.168.192.in-addr.arpa. В этой нотации сервер проработал месяц, до того как я изменил форвард и презапустил его.
При записи имени зоны в виде 0.1.168.192.in-addr.arpa. разрешение Ip адресов проходит, но мне делегирована только подсеть и зона для этой подсети должна передаваться на slaves провайдера.
> Ещё уточнение: bind отказывается разрешать ip адреса в имена в тот момент,
> когда я указываю имя зоны в classless нотации - 0/28.1.168.192.in-addr.arpa. В
> этой нотации сервер проработал месяц, до того как я изменил форвард
> и презапустил его.
> При записи имени зоны в виде 0.1.168.192.in-addr.arpa. разрешение Ip адресов проходит,
> но мне делегирована только подсеть и зона для этой подсети должна
> передаваться на slaves провайдера.ты бы реальные зоны дал чтобы можно было их пощупать
как смысл скрывать реверс?
Реальных зон указать не могу. Смысл, как мне кажется очевиден...
> Реальных зон указать не могу. Смысл, как мне кажется очевиден...смысл прятать как раз абсолютно не очевиден и не понятен, ибо высканить реверс это как два пальца об асфалт - в отличие от прямых зон реверсная зона ipv4 (для /24) ограничена 256 записями (в общем случае)
прятать что-то, что раздается на весь инет в открытом виде как-то глупо, не находите?
Посмотрите вот здесь примеры записей PTR-зоны - http://www.indelible.org/ink/classless/ По крайней мере они отличаются от тех, которые приведены Вами.
Спасибо. Всё это я уже проделывал. В этом документе рассказывается о том, как нужно делегировать обратные зоны разделенные на подсети. Таким образом настроен сервер провайдера.У меня же содержатся конкретные PTR записи для конкретных хостов, т.е. стандартная реверс зона, но для узкой подсети из 16 адресов.
Каким образом включить отладочное логирование запросов, но сделать это аккуратно не переборщив?
> Спасибо. Всё это я уже проделывал. В этом документе рассказывается о том,
> как нужно делегировать обратные зоны разделенные на подсети. Таким образом настроен
> сервер провайдера.
> У меня же содержатся конкретные PTR записи для конкретных хостов, т.е. стандартная
> реверс зона, но для узкой подсети из 16 адресов.0/28.1.168.192.in-addr.arpa IN SOA ns.domain.ru. postmaster.domain.ru
давай начнем стого, что 0/28.1.168.192.in-addr.arpa это как раз _НЕ_ стандартная реверс зона, а реверс зона частичного делигирования
>[оверквотинг удален]
>> сервер провайдера.
>> У меня же содержатся конкретные PTR записи для конкретных хостов, т.е. стандартная
>> реверс зона, но для узкой подсети из 16 адресов.
> 0/28.1.168.192.in-addr.arpa IN
> SOA ns.domain.ru. postmaster.domain.ru
> давай начнем стого, что 0/28.1.168.192.in-addr.arpa это как раз _НЕ_ стандартная реверс
> зона, а реверс зона частичного делигирования
>Сегодня заметили, что форвард, на который настроен наш bind некорректно разрешает ключевое
>для нас доменное имя, соответственно заменили форвард на правильный.
> но обратная зона при этом перестала работать.Итак, потренируем телепатию.
Предыдущий форвард, который вдруг стал некорректным, это один из серверов провайдера, на который делегируется полная реверс-зона.
Соответственно, сменили форвардера на некий внешний, а этот внешний про полную реверс-зону и не знает... Вот всё и "внезапно сломалось".
>Проверил всё, убрал все табы, в syslog и rndc ошибок не показывает, зона не стягивается
>на вторичные серверы, адреса не разрешает, пока спасают вторичные серверы провайдера. И
>при этом прямая зона работает.Но топикстартер-то упорно и упрямо не хочет запустить приведенный в первом ответе dnstracer. Он же "проверил всё"... Предполагаю, что утверждение "зона не стягивается на вторичные серверы" также "не верно" ))) потому что _как это проверяется_ также не было указано. Я думаю что она вполне себе стянулась и спокойно отдыхает, ибо делегирования нет.
Но ведь команду host приведенную в первом ответе - запустить-то крайне сложно, правда?
Гораздо проще пое-ть мозг тем, что реверс секретный :-)
извините, буква "с" на "-" заменилась...
Всё, что вы указали dnstracer и host я запустил. И как вам уже написал - ip адреса успешно разрешаются с помощью dns провайдеров. В качестве форварда как раз стоял сервер от google, который был заменён на dns провайдера, обратная перезамена результата не даёт. Возможно тут сыграл процесс перезапуска bind, а не замена форварда.
Стягивание зоны проверялось увеличением серйного номера и проверкой оного на ns провайдера путём письменной переписки с ним.
Зона делегируется провайдером мне, а не наоборот.
> Всё, что вы указали dnstracer и host я запустил. И как вам
> уже написал - ip адреса успешно разрешаются с помощью dns провайдеров.вот у меня на некоем хосте есть два провайдера и два пиринговых подключения.
В принципе, у всех четырех есть днс-сервера. Два из них - делегируют мне частичный реверс.
А у вас как ? что вы проверили и где ? Почему вы говорите об этой успешности как о некоем глобальном успехе?> В качестве форварда как раз стоял сервер от google, который был
> заменён на dns провайдера, обратная перезамена результата не даёт. Возможно тут
> сыграл процесс перезапуска bind, а не замена форварда.Я уже сказал - проверяем dnstracer. Проверяем командой host с указанием серверов (host -h).
> Стягивание зоны проверялось увеличением серйного номера и проверкой оного на ns провайдера путём письменной переписки с ним.
А как бы это, типа путем "host -t SOA" _самостоятельно_ проверять - не судьба ?
Мне провайдеры тоже много интересного пишут..> Зона делегируется провайдером мне, а не наоборот.
А еще она делегируется (должна делегироваться) провайдерУ.
Ребята, я готов отвечать на все ваши вопросы, не ругайтесь. Свои адреса не называю, потому, что указал версии ОС и Bind на своём ns сервере.
У провайдера есть запись делегирования, в которой говорится о том, что зона 0/28.1.162.198.in-addr.arpa содержится на моём сервере. Это я называю делегированием провайдером мне полномочий на разрешение ip адресов в этой зоне. Далее существуют два dns сервера провайдера, которые являются slave для этой зоны, они должны стягивать обратную зону на себя.
Сейчас проверил с помощью host -t SOA, серийный номер на dns серверах провайдера, указал в качестве сервера dns провайдера - зона как оказалось стягивается, серийный номер аналогичен моему. Но при установке в nslookup в качестве сервера моего ubuntu, он говорит, что не является авторитетным для этой зоны и, соответственно, перебрасывает на форварды.
DNS провайдера даёт авторитетный ответ.
> У провайдера есть запись делегирования, в которой говорится о том, что зона
> 0/28.1.162.198.in-addr.arpa содержится на моём сервере. Это я называю делегированием
> провайдером мне полномочий на разрешение ip адресов в этой зоне.должны быть соответствующие записи и в зоне 1.162.198.in-addr.arpa., а именно:
- делегирование зоны 0/28.1.162.198.in-addr.arpa. на ваши сервера
- склеивающие записи в зоне 1.162.198.in-addr.arpa., для каждого адреса частично делегируемого, записи вида 1.1.162.198.in-addr.arpa. CNAME 1.0/28.1.162.198.in-addr.arpa.
> Далее существуют два dns сервера провайдера, которые являются slave для этой зоны,
> они должны стягивать обратную зону на себя.
> Сейчас проверил с помощью host -t SOA, серийный номер на dns серверах
> провайдера, указал в качестве сервера dns провайдера - зона как оказалось
> стягивается, серийный номер аналогичен моему.ну допустим, ок.
> Но при установке в nslookup в
> качестве сервера моего ubuntu, он говорит, что не является авторитетным для
> этой зоны и, соответственно, перебрасывает на форварды.
> DNS провайдера даёт авторитетный ответ.что именно запрашивается в nslookup ?
Ваш сервер не является авторитетным для зоны, хранящей реверс для адреса (1.1.162.198.in-addr.arpa.)
Ваш сервер является авторитетным для зоны, в которую указывает CNAME (1.0/28.1.162.198.in-addr.arpa.)Ответ корректен ? всё ок, он и не должен быть авторитетным.
nslookup на сервер провайдера, разрешаем адрес 192.168.1.1Server: ns0.isp.ru
Address: 1.2.3.4#531.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#53Non-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
>[оверквотинг удален]
>> стягивается, серийный номер аналогичен моему.
> ну допустим, ок.
>> Но при установке в nslookup в
>> качестве сервера моего ubuntu, он говорит, что не является авторитетным для
>> этой зоны и, соответственно, перебрасывает на форварды.
>> DNS провайдера даёт авторитетный ответ.
> что именно запрашивается в nslookup ?
> Ваш сервер не является авторитетным для зоны, хранящей реверс для адреса (1.1.162.198.in-addr.arpa.)
> Ваш сервер является авторитетным для зоны, в которую указывает CNAME (1.0/28.1.162.198.in-addr.arpa.)
> Ответ корректен ? всё ок, он и не должен быть авторитетным.Спасибо, именно так всё и есть.
> Спасибо, именно так всё и есть.ну наконец-то )
> Всё, что вы указали dnstracer и host я запустил. И как вам
> уже написал - ip адреса успешно разрешаются с помощью dns провайдеров.значит у вас всё работает..
Вот, поехали дальше.Т.к. сервер мой указывает на то, что не является авторитетным для обратной зоны моей подсети, то при отключении рекурсии разрешение ip адресов прекращается. Может я чего не знаю и для разрешения имен в домене in-addr.arpa рекурсия критична? Повторюсь - ns провайдера сообщает, что является авторитетным, зону стягивает у меня, в ответе выдаёт, что для зоны авторитетны три сервера - один мой и два провайдерских, соответсвенно, это записи ns, которые я указал в своей зоне.
> Стягивание зоны проверялось увеличением серйного номера и проверкой оного на ns
> провайдера путём письменной переписки с ним.O_o - весьма не трвиальный способ проверить трансфер )))
>Предыдущий форвард, который вдруг стал некорректным, это один из серверов провайдера, на который делегируется полная реверс-зона.читать как:
Предыдущий форвард, который вдруг стал некорректным, это один из серверов провайдера, на котором размещена и на который _должна делегироваться_ полная реверс-зона.
Логи перезапуска сервера bind.Mar 23 15:03:35 mail named[15670]: received control channel command 'stop -p'
Mar 23 15:03:35 mail named[15670]: shutting down: flushing changes
Mar 23 15:03:35 mail named[15670]: stopping command channel on 127.0.0.1#953
Mar 23 15:03:35 mail named[15670]: stopping command channel on ::1#953
Mar 23 15:03:35 mail named[15670]: no longer listening on 192.168.1.1#53
Mar 23 15:03:35 mail named[15670]: exiting
Mar 23 15:03:36 mail named[15770]: starting BIND 9.7.1-P2 -u bind
Mar 23 15:03:36 mail named[15770]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='
Mar 23 15:03:36 mail named[15770]: adjusted limit on open files from 1024 to 1048576
Mar 23 15:03:36 mail named[15770]: found 1 CPU, using 1 worker thread
Mar 23 15:03:36 mail named[15770]: using up to 4096 sockets
Mar 23 15:03:36 mail named[15770]: loading configuration from '/etc/bind/named.conf'
Mar 23 15:03:36 mail named[15770]: reading built-in trusted keys from file '/etc/bind/bind.keys'
Mar 23 15:03:36 mail named[15770]: using default UDP/IPv4 port range: [1024, 65535]
Mar 23 15:03:36 mail named[15770]: using default UDP/IPv6 port range: [1024, 65535]
Mar 23 15:03:36 mail named[15770]: listening on IPv4 interface eth0, 192.168.1.1#53
Mar 23 15:03:36 mail named[15770]: generating session key for dynamic DNS
Mar 23 15:03:36 mail named[15770]: set up managed keys zone for view _default, file 'managed-keys.bind'
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 0.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 127.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 254.169.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 100.51.198.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 113.0.203.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: D.F.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 8.E.F.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 9.E.F.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: A.E.F.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: B.E.F.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: automatic empty zone: 0.1.1.0.0.2.IP6.ARPA
Mar 23 15:03:36 mail named[15770]: command channel listening on 127.0.0.1#953
Mar 23 15:03:36 mail named[15770]: command channel listening on ::1#953
Mar 23 15:03:36 mail named[15770]: zone 0/28.1.168.192.in-addr.arpa/IN: loaded serial 2011032202
Mar 23 15:03:36 mail named[15770]: zone domain.ru/IN: loaded serial 2011032202
Mar 23 15:03:36 mail named[15770]: managed-keys-zone ./IN: loaded serial 0
Mar 23 15:03:36 mail named[15770]: running
Mar 23 15:03:36 mail named[15770]: zone domain.ru/IN: sending notifies (serial 2011032202)
Mar 23 15:03:36 mail named[15770]: zone 0/28.1.168.192.in-addr.arpa/IN: sending notifies (serial 2011032202)