The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
И снова про делегирование зоны..., !*! Igor Mitichev, 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]#
===============================================


  • И снова про делегирование зоны..., !*! Mikhail, 18:08 , 18-Фев-07 (1)
    Маловато информации. Непонятен порядок опроса серверов (точнее, кто откуда что получает и кто для кого чего forwarders)

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

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

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

    • И снова про делегирование зоны..., !*! Igor Mitichev, 13:20 , 19-Фев-07 (2)
      > Маловато информации. Непонятен порядок опроса серверов (точнее, кто откуда что получает и
      > кто для кого чего 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, а вот через пару часиков начинает глючить...

      • И снова про делегирование зоны..., !*! Mikhail, 14:58 , 19-Фев-07 (3)
        >Совершенно не
        >понимаю, зачем сервер 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.

        • И снова про делегирование зоны..., !*! Igor Mitichev, 18:03 , 19-Фев-07 (4)
          >> Совершенно не понимаю, зачем сервер 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.

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

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

            Вот почему?

            [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]#

            • И снова про делегирование зоны..., !*! Mikhail, 19:58 , 19-Фев-07 (6)
              Запрос ушел на 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"; };
              ...
              };




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

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