The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"И снова про делегирование зоны..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"И снова про делегирование зоны..."  
Сообщение от Igor Mitichev email on 17-Фев-07, 23:23 
Вопрос, который не раз обсуждался и в фидо и в интернете, но у меня очередное
шаманство возникло.

Ситуация до омерзения проста: корпоративная сеть, поключенная к интернету через
ADSL. Соответственно, один DNS у провайдера и у него запись A на
*.vz111.debryansk.ru указывает на внешний IP модема.

Второй DNS внутри корпоративной сети. И тут записи поразнообразнее. И, наконец,
третий DNS на виндовом сервере обслуживет зону AD и обеспечивает работу active
directory.

Конфиг основного внутреннего сервера DNS (почти без сокращений):

=================== Цитируется Windows Clipboard ===================
// generated by named-bootconf.pl

acl vz111 {
192.168/16; 127.0.0.1;
};

options {
        directory "/var/named";
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;
   pid-file "named.pid";
   allow-query { "vz111"; };
};


//
// a caching only nameserver config
//
//controls {
//      inet 127.0.0.1 allow { localhost; } keys { rndckey; };
//};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

zone "vz111.debryansk.ru" IN {
        type master;
        file "vz111.zone";
        allow-update { none; };
};


include "/etc/rndc.key";
=================== Конец цитаты ===================

file "vz111.zone" (лишние записи поскипаны):

=================== Цитируется Windows Clipboard ===================
$TTL    86400

@ IN   SOA vz111.debryansk.ru. root.vz111.debryansk.ru. (
                                      0102200705 ; Serial - Порядковый номер
                                      28800      ; Refresh - Период обновления
                                      14400      ; Retry - Интервал между
попытками
                                      64800      ; Expire - Период устаревания
                                       7200 )    ; Minimum
                                   IN   NS  ns
ad.vz111.debryansk.ru.             IN   NS  ns.ad.vz111.debryansk.ru.
                                   IN   TXT "111 Military Plants, Bryansk,
Russia"
vz111.debryansk.ru.                IN   MX 0 mail
vz111.debryansk.ru.                IN   A   192.168.3.3
news.vz111.debryansk.ru.           IN   A   192.168.9.68
ns.vz111.debryansk.ru.             IN   A   192.168.9.68
ns.ad.vz111.debryansk.ru.          IN   A   192.168.3.4
*.vz111.debryansk.ru.              IN   A   192.168.3.3
=================== Конец цитаты ===================

Таким образом я расчитываю, что для разрешения имен в домене
ad.vz111.debryansk.ru. запросы клиентов будут перекидываться серверу
ns.ad.vz111.debryansk.ru. (192.168.3.4). Однако не тут то было...

Эмулируем вход компьютера в домен:

[root@news admin]# host -t SRV _ldap._tcp.ad.vz111.debryansk.ru
_ldap._tcp.ad.vz111.debryansk.ru SRV 0 100 389 win2003.ad.vz111.debryansk.ru.
[root@news admin]# host win2003.ad.vz111.debryansk.ru.
win2003.ad.vz111.debryansk.ru has address 84.42.52.64

Запись SRV разрешилась верно, а вот IP-адрес контроллера домена берется не с
сервера ns.ad.vz111.debryansk.ru., а с внешнего интернетовского DNS. Хотя,
виндовый сервер работает исправно, отдает все как надо:

=================== Цитируется Windows Clipboard ===================
[root@news admin]# dig win2003.ad.vz111.debryansk.ru. @ns.ad.vz111.debryansk.ru

; <<>> DiG 9.2.1 <<>> win2003.ad.vz111.debryansk.ru. @ns.ad.vz111.debryansk.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24016
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;win2003.ad.vz111.debryansk.ru. IN      A

;; ANSWER SECTION:
win2003.ad.vz111.debryansk.ru. 3600 IN  A       192.168.3.4

;; Query time: 4 msec
;; SERVER: 192.168.3.4#53(ns.ad.vz111.debryansk.ru)
;; WHEN: Sat Feb 17 14:33:54 2007
;; MSG SIZE  rcvd: 63
=================== Конец цитаты ===================

Что интересно, если перезапустить внутренний DNS, то все начинает какое-то
время работать правильно:

=================== Цитируется Windows Clipboard ===================
[root@news admin]# kill `cat /var/named/named.pid`
[root@news admin]# /etc/init.d/named start
[root@news admin]# host win2003.ad.vz111.debryansk.ru.
win2003.ad.vz111.debryansk.ru has address 192.168.3.4
=================== Конец цитаты ===================

но через пару часиков мы начинаем опять устойчиво наблюдать вышеописанный глюк.

Главное, не соображу, в какую сторону копать-то... То ли виндовый DNS чудит, то
ли линуксовский... Hа всякий случай, карбоню письмо в обе эхи:
*   Оpигинал    в ru.linux
* Также послано в ru.windows.2003

P.S: Ну вот, пожалуйста. Письмо было написано в GoldEd в 15:50:32. Сейчас, когда я скопировал его в форум opennet 23:20. Ситуация вернулась на круги своя:

==============================================
[root@news admin]# host win2003.ad.vz111.debryansk.ru.
win2003.ad.vz111.debryansk.ru has address 84.42.52.64
[root@news admin]# kill `cat /var/named/named.pid`
[root@news admin]# /etc/init.d/named start
[root@news admin]#                                         [  ОК  ]
[root@news admin]# host win2003.ad.vz111.debryansk.ru.
win2003.ad.vz111.debryansk.ru has address 192.168.3.4
[root@news admin]#
===============================================


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "И снова про делегирование зоны..."  
Сообщение от Mikhail email(??) on 18-Фев-07, 18:08 
Маловато информации. Непонятен порядок опроса серверов (точнее, кто откуда что получает и кто для кого чего forwarders)

1) можно распорядится через view зон, чтобы кто не надо не лез "наружу" (r провайдеру) вообще

2) не нравится след. строка:
>один DNS у провайдера и у него запись A на *.vz111.debryansk.ru указывает на внешний IP модема.

Логичнее было бы именно делигирование зоны, т.е. 'vz111.debryansk.ru in ns <внешний IP модема>', тогда на <внешний IP модема> можно "разрулить" самостоятельно. А так - он прав, сказано же, что '*'

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "И снова про делегирование зоны..."  
Сообщение от Igor Mitichev email on 19-Фев-07, 13:20 
> Маловато информации. Непонятен порядок опроса серверов (точнее, кто откуда что получает и
> кто для кого чего forwarders)

Пользователям корпоративной сети прописан внутренний DNS 192.168.9.68, конфиги которого и приведены выше. В нем же прописано делегирование зоны ad серверу 192.168.3.4. Совершенно не понимаю, зачем сервер 192.168.9.68 для разрешения имени win2003.ad.vz111.debryansk.ru лезет наружу, когда должен обращаться к 192.168.3.4.

Внешний DNS провайдера обслуживает только запросы клиентов из интернета.

> Логичнее было бы именно делигирование зоны, т.е. 'vz111.debryansk.ru in ns <внешний IP модема

Дело в том, что например web-сервер для внешнего пользователя -- это 84.42.52.64, а для корпоративного пользователя уэто совсем наоборот 192.168.3.3. Так что imho как раз нормально, что разные серверы DNS разным пользователям отдают разные IP-address.

Но вот почему мой внутренний DNS для разрешения имени в зоне ad лезет наружу, а не обращается к другому внутреннему серверу согласно директивы:

ad.vz111.debryansk.ru.             IN   NS  ns.ad.vz111.debryansk.ru.

я как-то не очень понимаю.

Точнее, сначала-то оно нормально работает, сразу после перезапуска named, а вот через пару часиков начинает глючить...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "И снова про делегирование зоны..."  
Сообщение от Mikhail email(??) on 19-Фев-07, 14:58 
>Совершенно не
>понимаю, зачем сервер 192.168.9.68 для разрешения имени win2003.ad.vz111.debryansk.ru лезет наружу, когда
>должен обращаться к 192.168.3.4.

Он обращается к корневым серверам, от них получает ответ, что зону vz111.debryansk.ru обслуживает <Внешний DNS провайдера>, и спрашивает у него.
Возможно, это не так, но здесь (в посте) другой информации нет.

А строчка
*.vz111.debryansk.ru.              IN   A   192.168.3.3
к чему?


>Дело в том, что например web-сервер для внешнего пользователя -- это 84.42.52.64,
>а для корпоративного пользователя уэто совсем наоборот 192.168.3.3. Так что imho
>как раз нормально, что разные серверы DNS разным пользователям отдают разные
>IP-address.

Нормально, более того - один север может разным клиентам возвращать разные адреса, но - должны быть прописаны view зон с ограничениями, кто (внешние/внутренние) какую зону получает (видит).

>Но вот почему мой внутренний DNS для разрешения имени в зоне ad
>лезет наружу, а не обращается к другому внутреннему серверу согласно директивы:
>
>
>ad.vz111.debryansk.ru.            
> IN   NS  ns.ad.vz111.debryansk.ru.
>
>я как-то не очень понимаю.

Возможно (см. выше), root-серверы для него больший авторитет. Нужно смотреть, куда идут запросы и кто что возвращает. Рекурсия включена?
Необязательно внутренним серверам лазить на рутовые, они вполне могут обходиться forwarders.
Основной сервер может не держать ns-запись, а быть secondary ad.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "И снова про делегирование зоны..."  
Сообщение от Igor Mitichev email on 19-Фев-07, 18:03 
>> Совершенно не понимаю, зачем сервер 192.168.9.68 для разрешения имени
>> win2003.ad.vz111.debryansk.ru лезет наружу, когда должен обращаться
>> к 192.168.3.4.

> Он обращается к корневым серверам, от них получает ответ, что зону vz111.debryansk.ru
> обслуживает <Внешний DNS провайдера>, и спрашивает у него.

_Что_ он делает я понимаю, я не понимаю _почему_. В конфиге зона vz111.debryansk.ru прописана как master. В этой master-зоне есть директива делегирования. Почему named, являющийся авторитетным для данной зоны лезет к корневым серверам? Я может туплю, но я действительно не понимаю логику работы bind.

>Возможно, это не так, но здесь (в посте) другой информации нет.

Я не знаю, какую еще информацию дать. Конфиги я представил в практически полном объеме... Кстати, в ru.windows.2003 мне тоже дали совет удалить сведения о корневых серверах и настроить forwarders на DNS-сервер провайдера. И я даже уверен, что это поможет. Но все равно, это решение для меня пока является каким-то ритуальным танцем с бубном потому, что я не понимаю внутренней логики.

>А строчка
>*.vz111.debryansk.ru.   IN   A   192.168.3.3
>к чему?

фактически, любая ссылка DNS (в рамках домена, разумеется), кроме прописанных в файле зоны явно, будет указывать на этот сервер. То есть на нем крутится большинство сервисов и эта одна строчка заменяет строчки mail, pop, smtp, www, и еще пяток виртуальных хостов apache. По сути -- дань сисопской лени потому, что одну строчку прописать легче, чем семь :)

>Нормально, более того - один север может разным клиентам возвращать разные адреса,
>но - должны быть прописаны view зон с ограничениями, кто (внешние/внутренние)
>какую зону получает (видит).

На сколько я в курсе, это действует с 9 версии named? Хм... А у меня какая? А! О! starting BIND 9.2.1 -u named

>Возможно (см. выше), root-серверы для него больший авторитет.

Это-то и странно. Я-то по простоте своей всегда полагал, что если зона описана как master, то все прочие сервера идут лесом...

> Нужно смотреть, куда идут запросы и кто что возвращает.

Я извеняюсь за ламерство, а как это сделать?

> Рекурсия включена?

Нет, на сколько я помню. На работе завтра уточню... Да нет, не в ключена. Вон они, конфиги-то, вверху страницы.

> Необязательно внутренним серверам лазить
> на рутовые, они вполне могут обходиться forwarders.

Видимо, на этом решении и остановлюсь.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "И снова про делегирование зоны..."  
Сообщение от Igor Mitichev email on 19-Фев-07, 18:12 
>> Нужно смотреть, куда идут запросы и кто что возвращает.
>
>Я извеняюсь за ламерство, а как это сделать?

Вот почему?

[root@news admin]# dig ns.ad.vz111.debryansk.ru

; <<>> DiG 9.2.1 <<>> ns.ad.vz111.debryansk.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31394
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;ns.ad.vz111.debryansk.ru.      IN      A

;; ANSWER SECTION:
ns.ad.vz111.debryansk.ru. 313562 IN     A       84.42.52.64

;; AUTHORITY SECTION:
ad.vz111.debryansk.ru.  1533    IN      NS      ns.ad.vz111.debryansk.ru.
ad.vz111.debryansk.ru.  1533    IN      NS      ns.vz111.debryansk.ru.
ad.vz111.debryansk.ru.  1533    IN      NS      win2003.ad.vz111.debryansk.ru.

;; ADDITIONAL SECTION:
ns.vz111.debryansk.ru.  86400   IN      A       192.168.9.68
win2003.ad.vz111.debryansk.ru. 522 IN   A       192.168.3.4

;; Query time: 33 msec
;; SERVER: 192.168.9.68#53(192.168.9.68)
;; WHEN: Mon Feb 19 18:10:01 2007
;; MSG SIZE  rcvd: 143

[root@news admin]#

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "И снова про делегирование зоны..."  
Сообщение от Mikhail email(??) on 19-Фев-07, 19:58 
Запрос ушел на 192.168.9.68. Тот запросил 'zone "." IN' - корневые серверы, кто отвечает за 'ru'. Был послан на ответственного, запросил у того, кто держит debryansk.ru, перешел к4 тому, запросил... и т.п. Дошел до провайдера, который ответил, что
*.vz111.debryansk.ru A IN <IP модема>, т.е. 84.42.52.64.

А если бы на нем (провайдере) была запись
IN NS <IP модема>, то след. запрос был бы к 192.168.9.68 (как я понимаю), но - снаружи. Тогда - не без помощи view, конечно - 192.168.9.68 мог бы объяснить всем, кто на самом деле есть ns.ad.vz111.debryansk.ru - вернул бы внутренним клиентам адрес из внутр. сети, а внешних отказался бы обслуживать.

Посмотреть, кто куда и зачем, можно,
1) запустив сервер с параметром '-d ...'
2) включив 'rndc querylog' + 'rndc trace level'
3) настроив logging в named.conf - сыпать разные события в разные логи, пример:

logging {                                            
    channel "default_debug" {                        
        file "log/named.log" versions 3 size 100k;  
        //severity info;                            
        // severity dynamic;                        
        severity debug;                              
        print-time yes;                              
        print-category yes;                          
    };                                              
...
category "default" { "default_debug"; };
...
};

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру