Решение проблем Сравнение версий

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
Последняя версия Следующая версия справа и слева
wiki:руководство_по_ubuntu_server:служба_доменных_имен:troubleshooting [2012/06/15 14:58]
[Решение проблем]
wiki:руководство_по_ubuntu_server:служба_доменных_имен:troubleshooting [2013/02/19 12:40]
[Журналирование]
Строка 14: Строка 14:
 ===resolv.conf=== ===resolv.conf===
  
-The first step in testing ​BIND9 is to add the nameserver'​s ​IP Address to a hosts resolverThe Primary nameserver should be configured as well as another host to double check thingsSimply edit /​etc/​resolv.conf ​and add the following+Первый шаг в тестировании ​BIND9 это добавление ​IP адреса сервера имен в список определителей сетевых именПервичный сервер имен должен настраиваться,​ как и любой другой узел сети, с двойной проверкойПросто отредактируйте ​/​etc/​resolv.conf, добавив следующее
 +<​code>​
 nameserver 192.168.1.10 nameserver 192.168.1.10
 nameserver 192.168.1.11 nameserver 192.168.1.11
- +</​code>​ 
-You should also add the IP Address of the Secondary nameserver in case the Primary becomes unavailable.+<​note>​Вам надо добавить также ​IP адрес вторичного сервера имен на случай недоступности первичного.</​note>​
  
 ===dig=== ===dig===
  
-If you installed the dnsutils ​package you can test your setup using the DNS lookup utility ​dig:+Если вы установили пакет **dnsutils**, вы можете проверить свою установку используя обзорную утилиту ​DNS **dig**:
  
-    After installing ​BIND9 use dig against the loopback ​interface to make sure it is listening on port 53. From a terminal prompt:+ 1. После установки **BIND9** примените ​dig к интерфейсу обратной петли (loopback), чтобы убедиться,​ что порт ​53 прослушиваетсяИз терминала наберите: 
 +<​code>​dig -x 127.0.0.1</​code>​ 
 +Вы должны увидеть строки вывода,​ похожие на следующее:​ 
 +<​code>​ 
 +;; Query time: 1 msec 
 +;; SERVER: 192.168.1.10#​53(192.168.1.10) 
 +</​code>​
  
-    dig -x 127.0.0.1 + 2Если **BIND9** настроен у вас как **кэширующий** сервер,​ используйте ​dig для замера времени при разрешении имени внешнего домена
- +<​code>​dig ubuntu.com</​code>​ 
-    You should see lines similar to the following in the command output: +Обратите внимание на время в конце вывода результата команды
- +<​code>​;; Query time: 49 msec</​code>​ 
-    ;; Query time: 1 msec +После повторного вызова ​dig должно произойти улучшение
-    ;; SERVER: 192.168.1.10#​53(192.168.1.10) +<​code>​;; Query time: 1 msec</​code>​
- +
-    If you have configured ​BIND9 as a Caching nameserver "dig" an outside domain to check the query time+
- +
-    ​dig ubuntu.com +
- +
-    Note the query time toward the end of the command output+
- +
-    ​;; Query time: 49 msec +
- +
-    After a second ​dig there should be improvement+
- +
-    ​;; Query time: 1 msec+
  
 ===ping=== ===ping===
  
-Now to demonstrate how applications make use of DNS to resolve a host name use the ping utility to send an ICMP echo requestFrom a terminal prompt enter+Теперь для демонстрации как приложения могут использовать ​DNS для разрешения сетевых имен используйте утилиту ​ping для отправки ​ICMP эхо-запросаИз терминала наберите следующее
- +<​code>​ping example.com</​code>​
-ping example.com +
- +
-This tests if the nameserver can resolve the name ns.example.com to an IP Address. The command output should resemble:+
  
 +Это проверит может ли сервер имен разрешить имя ns.example.com в IP адрес. Вывод команды будет напоминать следующее:​
 +<​code>​
 PING ns.example.com (192.168.1.10) 56(84) bytes of data. PING ns.example.com (192.168.1.10) 56(84) bytes of data.
 64 bytes from 192.168.1.10:​ icmp_seq=1 ttl=64 time=0.800 ms 64 bytes from 192.168.1.10:​ icmp_seq=1 ttl=64 time=0.800 ms
 64 bytes from 192.168.1.10:​ icmp_seq=2 ttl=64 time=0.813 ms 64 bytes from 192.168.1.10:​ icmp_seq=2 ttl=64 time=0.813 ms
 +</​code>​
  
 ===named-checkzone=== ===named-checkzone===
  
-A great way to test your zone files is by using the named-checkzone ​utility installed with the bind9 packageThis utility allows you to make sure the configuration is correct before restarting ​BIND9 and making the changes live.+Хороший способ проверить ваши файлы зон - это использовать утилиту **named-checkzone**, установленную вместе с пакетом **bind9**Эта утилита позволяет вам убедиться в корректности настроек до перезапуска **BIND9** и применения изменений.
  
-    To test our example Forward zone file enter the following from a command prompt+ 1. Для тестирования нашего файла прямой зоны из примера введите следующее в командной строке
- +<​code>​named-checkzone example.com /​etc/​bind/​db.example.com</​code>​ 
-    ​named-checkzone example.com /​etc/​bind/​db.example.com +Если все настроенно верно, вы сможете увидеть вывод, похожий на
- +<​code>​ 
-    If everything is configured correctly you should see output similar to+zone example.com/​IN:​ loaded serial 6 
- +OK 
-    zone example.com/​IN:​ loaded serial 6 +</​code>​ 
-    OK + 2. Аналогичнодля тестирования файла обратной зоны введите следующее
- +<​code>​named-checkzone 1.168.192.in-addr.arpa /​etc/​bind/​db.192</​code>​ 
-    ​Similarlyto test the Reverse zone file enter the following+Вывод должен напоминать следующее
- +<​code>​ 
-    ​named-checkzone 1.168.192.in-addr.arpa /​etc/​bind/​db.192 +zone 1.168.192.in-addr.arpa/​IN:​ loaded serial 3 
- +OK 
-    The output should be similar to+</​code>​ 
- +<​note>​Serial Number ​вашего файла зоны может отличаться.</​note>​
-    zone 1.168.192.in-addr.arpa/​IN:​ loaded serial 3 +
-    OK +
- +
-The Serial Number ​of your zone file will probably be different.+
  
 ====Журналирование==== ====Журналирование====
  
-BIND9 has a wide variety of logging configuration options availableThere are two main optionsThe channel ​option configures where logs goand the category ​option determines what information to log. +BIND9 имеет широкий набор доступных опций настроек журналовСуществуют две основные опцииС помощью опции **channel** указывается где вести журналыа опция **category** определяет какую информацию писать в журнал.
- +
-If no logging option is configured the default option is:+
  
 +Если опции журналов отсутствуют,​ по умолчанию применяется следующее:​
 +<​code>​
 logging { logging {
      ​category default { default_syslog;​ default_debug;​ };      ​category default { default_syslog;​ default_debug;​ };
      ​category unmatched { null; };      ​category unmatched { null; };
 }; };
 +</​code>​
 +Этот раздел раскрывает как настроить BIND9 посылать отладочные сообщения,​ связанные с DNS запросами в отдельный файл.
  
-This section covers configuring BIND9 to send debug messages related to DNS queries to a separate file. + 1Сначала нам надо настроить канал (channel) для определения в какой файл посылать сообщенияРедактируем ​/​etc/​bind/​named.conf.local ​и добавляем следующее
- +<​code>​ 
-    First, we need to configure a channel ​to specify which file to send the messages toEdit /​etc/​bind/​named.conf.local ​and add the following+logging { 
- +    channel query.log {       
-    logging { +        file "/​var/​log/​query.log";​ 
-        channel query.log {       +        severity debug 3;  
-            file "/​var/​log/​query.log";​ +    };  
-            severity debug 3;  +}; 
-        };  +</​code>​ 
-    }; + 2. Затем настраиваем категорию (category) для отправки всех ​DNS запросов в файл
- +<​code>​ 
-    Next, configure a category ​to send all DNS queries to the query file+logging { 
- +    channel query.log {       
-    logging { +        file "/​var/​log/​query.log";​  
-        channel query.log {       +        severity debug 3;  
-            file "/​var/​log/​query.log";​  +    };  
-            severity debug 3;  +    category queries { query.log; };  
-        };  +}; 
-        category queries { query.log; };  +</​code>​ 
-    }; +<​note>​Обратите внимание на опцию **debug**, которая может принимать значения от до 3. Если уровень отладки не указан,​ о умолчанию используется ​1.</​note>​ 
- + 3. Поскольку сервис **named** запускается от имени **bind**, надо создать файл и сменить ему пользователя
-Note: the debug option can be set from to 3. If a level isn't specified level is the default+<​code>​
- +
-    Since the named daemon runs as the bind user the /​var/​log/​query.log file must be created and the ownership changed+
     sudo touch /​var/​log/​query.log     sudo touch /​var/​log/​query.log
     sudo chown bind /​var/​log/​query.log     sudo chown bind /​var/​log/​query.log
 +</​code>​
 + 4. Перед тем как сервис **named** сможет писать в новый файл журнала нужно изменить профиль AppArmor. Сначала редактируем файл /​etc/​apparmor.d/​usr.sbin.named,​ добавив:​
 +<​code>/​var/​log/​query.log w,</​code>​
 +Затем перегружаем профиль:​
 +<​code>​cat /​etc/​apparmor.d/​usr.sbin.named | sudo apparmor_parser -r</​code>​
 +Дополнительную информацию по **AppArmor** смотрите в разделе [[wiki:​руководство_по_ubuntu_server:​безопасность:​apparmor|AppArmor]].
  
-    Before named daemon can write to the new log file the AppArmor profile must be updatedFirst, edit /​etc/​apparmor.d/​usr.sbin.named and add: + 5Теперь перегружаем ​BIND9 для применения изменений
- +<​code>​sudo service bind9 restart</​code>​
-    /​var/​log/​query.log w, +
- +
-    Next, reload the profile: +
- +
-    cat /​etc/​apparmor.d/​usr.sbin.named | sudo apparmor_parser -r +
- +
-    For more information on AppArmor see AppArmor +
- +
-    Now restart ​BIND9 for the changes to take effect+
- +
-    ​sudo service bind9 restart+
  
-You should see the file /​var/​log/​query.log ​fill with query informationThis is a simple example of the BIND9 logging optionsFor coverage of advanced options see More Information.+Теперь вы можете увидеть файл ​/​var/​log/​query.log, заполненный информацией о запросахЭто простейший пример использования опций журналирования ​BIND9. ​По использованию расширенных опций смотрите раздел [[wiki/​руководство_по_ubuntu_server/​служба_доменных_имен/​references#​дополнительная_информация|Дополнительная информация]].
  
 ---- ----