LINUX.ORG.RU
решено ФорумAdmin

bind9 на debian 7.2., нубовопросы.

 ,


0

2

Доброго времени суток. Я практически не имел дел с 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; }wink.gif? Лишь на тот случай, если запрос остался у них в кэше и это сократит путь запроса?
5. Есть в статье такая строка :«При этом, если необходимо разрешить кэширование (то есть рекурсивные запросы) для локальной сети, то необходимо раскомментировать параметры forwarders и allow-recursion и закомментировать recursion no;.», почему кэширование = рекурсивные запросы?

Спасибо тем, кто прочитает эту стену текста и ответит.

Хорошо бы приводить ссылку, вдруг у кого возникнет желание почитать источник, откуда выдернуты фразы.

Пытаюсь ответить:

1. Все домены это субдомены, кроме корневого (домен точка). Поэтому когда говорят про домен автомотически подразумевают его подчинённые домены, например, «все университетские компьютеры в США находятся в домене ″.edu″. А зона, это то, что размещается на одном DNS-сервере, у неё есть запись SOA.

2. Я не знаю, про что писал автор, запросы отличаются флагом RD, в заголовке запроса. Который разрешает DNS-серверу самому выполнять какие-то запросы, прежде чем вернуть ответ, или не разрешает и сервер должен отвечать только на основании имеющихся у него данных.

Или имеется в виду обычный рекурсивный запрос

то есть что такое „ОБЫЧНЫЙ рекурсивный запрос“ вы понимаете, а что такое „рекурсивный запрос“ не понимаете?

3. Если на сервере описана зона ″127.in-addr.arpa″ и пр. то рекурсивный запрос к этой зоне равносилен итеративному.

А запросы возникают легко и непренуждённо, так как программы любят делать преобразование ИМЯ<->ip-адрес. Тот же самый ″telnet localhost 25″.

4. forward нужен чтобы отправить определённые запросы к определённому серверу, например, к центральному серверу внутри большой корпоративной сети по его локальному ip-адресу.

зачем указывать forwarders (forwarders { 8.8.8.8; }wink.gif?

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

5. DNS-сервер кеширует только ответы других серверов. Зоны, взятые из файлов или заполненые динамически к кешу не относятся. Без разрешения рекурсивных запросов сервер не будет создавать запросы к другим серверам.

mky ★★★★★ ()
Ответ на: комментарий от mky

Спасибо за ваш ответ.
Если интересно - вот статьи, которыми я руководствовался помимо Linux Network Administrators Guide:
http://www.k-max.name/linux/dns-server-bind/
http://www.k-max.name/linux/howto-dns-server-bind/
Также посоветовали http://www.zytrax.com/, после чего я вроде таки понял принцип использования $ORIGIN и $INCLUDE.

Одно уточнение по 4му вопросу: я имел в виду, что даже без указания forwarders на моем гипотетическом DNS при имеющемся описании корневой зоны (со списоком корневых NS) и разрешенных рекурсивных запросах, клиент все равно получит ответ, кто такой, например http://www.vmware.com, хотя и будет получать ответ дольше, т.к. на DNS провайдера (который обычно указывают в forwarders) этот ответ с вероятностью 99.9 % есть в кэше, верно?
p.s. я не вижу кнопку аля «поблагодарить за ответ» или здесь нет какой-либо кармы?

nokogerra ()
Ответ на: комментарий от nokogerra

все равно получит ответ, кто такой, например http://www.vmware.com, хотя и будет получать ответ дольше

В принципе, да, быстрее, но, именно, если у DNS-провайдера есть ответ в кеше и его DNS-сервер нормально справляется с нагрузкой.

P.S. кармы здесь нет и, надеюсь, не будет.

mky ★★★★★ ()
Ответ на: комментарий от mky

Спасибо за вашу помощь, ваши ответы мне помогли. Тему отмечу решенной.

nokogerra ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.