bind9 на debian 7.2. (Нубовопросы.)

Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС.

Модераторы: SLEDopit, Модераторы разделов

nokogerra
Сообщения: 83

bind9 на debian 7.2.

Сообщение nokogerra »

Доброго времени суток. Я практически не имел дел с linux/unix за исключением esxi, и не имел дел с dns дальше того, что отдает провайдер, поэтому вопросы могут быть глупыми и их много.
Прочитал статьи по bind на блоге одного товарища, которые очень замечательно и глубоко описывает сабжи своих статей (по его же статьям делал squid с интеграцией в ad ds по krb), также прочитал раздел по dns и named в Linux Network Administrators Guide, но вот такие вопросы остались:
1. Чем все таки отличаются домен и зона, следующий пример из справочника не дает четкого понимания:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Т.е. имеется в виду что в домене может быть несколько зон, и при этом зона physics.groucho.edu не является суб-доменом?
2. Разница между типами запросов:
итеративный в качестве ответа возвращает ip-адрес или адрес NS, авторитетного за нужную зону.
рекурсивный в качестве ответа может вернуть также ip-адрес, NS авторитетного за нужную зону, а также, DNS, к которому был произведен запрос, может обратиться к другим DNS-серверам. Так вот к каким, в той же зоне или вообще к любым? Или имеется в виду обычный рекурсивный запрос "по нисходящей" - сначала к корневому, потом к TLD, и т.д.? Если так, то, например итеративный запрос к корневому серверу в таком случае может считаться частью рекурсивного запроса?
3. Зачем нужны зоны "127.in-addr.arpa", "0.in-addr.arpa", "255.in-addr.arpa" и "localhost"? В качестве объяснения вот что было сказано: "Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону." Как я понимаю это актуально только в том случае, если dns будет принимать рекурсивные запросы, в случае только итеративных иметь описание этих зон не обязательно, верно? Также я не представляю себе примера таких "трансляций случайных запросов", может кто привести пример?
4. Не до конца осознал разницу между типами зон (type).
-master - авторитетный за зону, первичный - понятно.
-slave (я так понял, иногда называется secondary) - также считается авторитетным за зону, но саму зону "подтягивает" напрямую с мастера, и после истечения TTL зоны и невозможности обновить ее (подтянуть с мастера), зона считается скисшей.
-hint. "указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)". Как я понял, это необходимо указывать только если предусматриваются рекурсивные запросы, верно?
-forward. "указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону". Вообще масло масляное, не понял зачем это нужно, тем более если указан hint, т.е. корневые сервера для рекурсивных запросов известны?

Также не ясно, если известны корневые сервера, зачем указывать forwarders (forwarders { 8.8.8.8; };)? Лишь на тот случай, если запрос остался у них в кэше и это сократит путь запроса?
5. Есть в статье такая строка :"При этом, если необходимо разрешить кэширование (то есть рекурсивные запросы) для локальной сети, то необходимо раскомментировать параметры forwarders и allow-recursion и закомментировать recursion no;.", почему кэширование = рекурсивные запросы?

Спасибо тем, кто прочитает эту стену текста и ответит.
Спасибо сказали:
Аватара пользователя
skeletor
Сообщения: 1224

Re: bind9 на debian 7.2.

Сообщение skeletor »

1) http://www.freename.com.ua/?faq=24 , http://habrahabr.ru/post/137587/ . очень много вопросов сразу отпадёт.
2) Нет, нельзя. Это разные типы запросов, просто немножко похожи
3) Точно не скажу, но думаю для служебного использования, вроде резолвинга localhost/127.0.0.1/broadcast
4)
- master = да
- slave =

Notes:

The master DNS for each zone is defined in the 'masters' statement of the zone clause and allows slaves to refresh their zone record when the 'expiry' parameter of the SOA Record is reached. If a slave cannot reach the master DNS when the 'expiry' time has been reached it will stop responding to requests for the zone. It will not use time-expired data.
The file parameter is optional and allows the slave to write the transferred zone to disc and hence if BIND is restarted before the 'expiry' time the Slave server will use the saved data. In large DNS systems this can save a considerable amount of network traffic.


-hint = где-то так.

The default BIND behaviour is to cache and this is associated with the recursion parameter (the default is 'recursion yes'). There are many configuration examples which show caching behaviour being defined using a type hint statement in a zone declaration. These configurations confuse two distinct but related functions. If a server is going to provide caching services then it must support recursive queries and recursive queries need access to the root servers which is provided via the 'type hint' statement.


- forward = Допустим, у вас внутренняя зона user.local, которую обслуживает Windows сервера с ActiveDirectory. Как сказать вашему главному DNS серверу, что все запросы на резолвинг blabla.user.local пересылать на этот виндовый сервер? Вы конечно можете настроить slave зону, но иногда проще создать forward-зону.

5) Это личное мнение автора статьи. Лучше читать авторитетные источники:

If recursion is set to 'yes' (the default) the server will always provide recursive query behaviour if requested by the client (resolver). If set to 'no' the server will only provide iterative query behaviour - normally resulting in a referral. If the answer to the query already exists in the cache it will be returned irrespective of the value of this statement. This statement essentially controls caching behaviour in the server. The allow-recursion statement and the view clauses can provide fine-grained control. This statement may be used in a view or a global options clause.
Спасибо сказали:
Аватара пользователя
McSim
Сообщения: 419
Статус: Экспериментатор
ОС: заGNU/Linux Debian

Re: bind9 на debian 7.2.

Сообщение McSim »

Немного дополню skeletorа.
nokogerra писал(а):
02.02.2015 07:38
1. Чем все таки отличаются домен и зона, следующий пример из справочника не дает четкого понимания:

В 2х словах, зона - это то, что описано в файле зоны. т.е. зона в себе содержит то (те ресурсные записи), что прописаны в файле зоны. Домен - это то, что определяется доменным именем и является древовидной иерархией. Домен может состоять из различных файлов зон.
В целом, в повседневной жизни эти понятия
nokogerra писал(а):
02.02.2015 07:38
2. Разница между типами запросов:
итеративный в качестве ответа возвращает ip-адрес или адрес NS, авторитетного за нужную зону.
рекурсивный в качестве ответа может вернуть также ip-адрес, NS авторитетного за нужную зону, а также, DNS, к которому был произведен запрос, может обратиться к другим DNS-серверам. Так вот к каким, в той же зоне или вообще к любым? Или имеется в виду обычный рекурсивный запрос "по нисходящей" - сначала к корневому, потом к TLD, и т.д.? Если так, то, например итеративный запрос к корневому серверу в таком случае может считаться частью рекурсивного запроса?

В общем случае, рекурсивный запрос можно считать как набор итеративных, но эта формулировка не всегда применима и корректна. Все же правильней разделять эти два типа запросов.

nokogerra писал(а):
02.02.2015 07:38
3. Зачем нужны зоны "127.in-addr.arpa", "0.in-addr.arpa", "255.in-addr.arpa" и "localhost"? В качестве объяснения вот что было сказано: "Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону." Как я понимаю это актуально только в том случае, если dns будет принимать рекурсивные запросы, в случае только итеративных иметь описание этих зон не обязательно, верно? Также я не представляю себе примера таких "трансляций случайных запросов", может кто привести пример?

Если выполнить nslookup 127.1.1.1, то bind без зоны "127.in-addr.arpa" отправится разрешать это имя к корневым серверам. А при наличии этой зоны, он просмотрит локальные записи зоны "127.in-addr.arpa" и вернет ошибку, либо не ошибку, если зона будет содержать эту запись. Т.о. корневые сервера не будут получать ненужные запросы для указанных зон.

nokogerra писал(а):
02.02.2015 07:38
4. Не до конца осознал разницу между типами зон (type).Также не ясно, если известны корневые сервера, зачем указывать forwarders (forwarders { 8.8.8.8; };)? Лишь на тот случай, если запрос остался у них в кэше и это сократит путь запроса?

Да, именно для обращения к серверам, которые находятся ближе, кэшируют и теоретически могут отвечать быстрей. По остальным типам все ответил skeletor.

nokogerra писал(а):
02.02.2015 07:38
5. Есть в статье такая строка :"При этом, если необходимо разрешить кэширование (то есть рекурсивные запросы) для локальной сети, то необходимо раскомментировать параметры forwarders и allow-recursion и закомментировать recursion no;.", почему кэширование = рекурсивные запросы?

Да, это не совсем корректно написано. Но при разрешении рекурсивных запросов - они будут сохраняться в локальном кэше в соответствии с TTL.

Спасибо сказали: