LXF97:Служба доменных имен

Текущая версия на 12:38, 21 октября 2008

[править] Служба доменных имен

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

[править] DNS: Cвязующее звено Интернета

Четырехбайтная адресация, лежащая в основе IP-протокола, на котором, помимо всего прочего, зиждется сеть Интернет, удоб- на для операционных систем, но слишком тяжела для слабого и изнеженного человеческого мозга. Поэтому «записная книжка», из которой в любое время можно было бы узнать, что сайт http://linuxformat.ru нужно искать по адресу 88.212.196.134, а почту для http://mail.ru отправлять на 194.67.23.20, всегда будет востребована.

Поначалу с ролью такой «записной книжки» превосходно справлялся простой текстовый файл HOSTS.TXT. За его формирование отвечал Сетевой информационный центр Стенфордского института, а администраторы и пользователи периодически скачивали его по FTP. Но по мере роста числа компьютеров, объединенных в единую сеть, такое решение стало абсолютно неэффективным.

В конечном итоге DNS (Domain Name System, система доменных имен) уверенно и, похоже, надолго, заняла место службы, снабжающей нас информацией о том, какой же IP-адрес соответствует интересующему нас доменному имени. Основным преимуществом DNS является ее распределенная природа – информация не концентрируется в одном месте, а разбросана по всему Интернету в соответствии с иерархической структурой пространства доменных имен.

Во главе этой иерархии размещается так называемый корневой домен, обозначаемый одиночной точкой. Из этого корня «растут» домены первого уровня – ru, uk, com, net, org и т.д. Для реального использования доступны домены, начиная со второго уровня. Внутри домена могут размещаться как отдельные хосты, так и поддомены. Например, http://www.ibm.com – хост в домене ibm.com, а http://austin.ibm.com – поддомен.

Здесь нужно ввести еще одно понятие – «зона». Зоной называют область пространства имен домена, которая администрируется независимо от остального пространства имен. Жесткой привязки к делению на поддомены здесь нет – поддомен может обслуживаться как автономная единица, т.е. иметь свою зону (в этом случае говорят о делегировании поддомена), а может входить в родительскую зону.

Так как же DNS позволяет узнать IP-адрес того или иного хоста, например, http://www.yandex.ru? Выглядит это примерно так. Клиент отправляет запрос близлежащему DNS-серверу (обычно это сервер провайдера, но мы увидим далее, что можно запустить и собственный). Этот сервер в общем случае не знает требуемый IP, и даже не представляет, где его искать. Поэтому обращается к одному из корневых DNS-серверов. Корневой сервер физически не в силах держать информацию обо всех доменах третьего (да даже и второго) уровня, так что все, что он может сделать, это послать нас... правильно, к DNS-серверу первого уровня, который обслуживает зону ru.

В дела отдельных доменов и этот сервер не вникает, так что адреса конкретных узлов не обслуживает. Зато он знает, какой DNS-сервер отвечает за домен http://yandex.ru. Туда он нас (точнее, сервер нашего провайдера) и отправит. А вот DNS-сервер домена http://yandex.ru уже просто обязан вернуть нам IP-адрес входящего в его зону ответственности хоста. Ну или послать... на этот раз просто послать, если искомый хост не существует в природе.

Таким образом, за каждый домен может отвечать свой администратор, настраивая DNS-сервер для его обслуживания, а вышестоящим серверам достаточно знать, что и кому они делегировали. За счет этого и обеспечивается потрясающая масштабируемость, сделавшая службу DNS столь эффективной.

[править] Желание клиента – закон

Начнем наше знакомство с клиентской части. Реализована она в виде стандартной библиотеки, и используем мы ее, можно сказать, ежеминутно, сами того не замечая. Если точнее, то используют ее те приложения, с которыми мы работаем – браузеры, FTP- и почтовые клиенты, различные сетевые серверы, да практически любые приложения, работающие в сети.

Настраивается клиент с помощью файла /etc/resolv.conf. В большинстве случаев достаточно указать там DNS-серверы, адреса которых предоставляет вам провайдер:

nameserver 1.2.3.4
nameserver 4.3.2.1

В современных дистрибутивах эта операция зачастую выполняется через графический интерфейс. Если для настройки сети используется DHCP-клиент, то он, как правило, и осуществляет «редактирование» /etc/resolv.conf. Т.е. обычный пользователь сталкивается с данным файлом не часто. Тем не менее, полезно знать, куда заглянуть в случае проблем.

Помимо упомянутой опции nameserver, в resolv.conf могут задавать ся и некоторые другие параметры, но сейчас они нам не слишком интересны. Подробности ищите на странице man resolv.conf(5).

[править] BIND: Узелок на память

Теперь поговорим о сервере. Наиболее распространенным пакетом, обеспечивающим работу службы DNS на Unix-подобных системах, в настоящее время является BIND (Berkeley Internet Name Domain). Посмотрим, какая от него может быть польза, даже если вы не располагаете собственным доменом.

• Метамодернизм в позднем творчестве В.Г. Сорокина
• ЛитРПГ - последняя отрыжка постмодерна
• "Ричард III и семиотика"
• 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
• Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
• Литература
• Метамодерн
• Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
• Как избавиться от комаров? Лучшие типы ловушек.
• Что делать если роблокс вылетает на windows
• Что делать, если ребенок смотрит порно?
• Почему собака прыгает на людей при встрече?
• Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
• О чем может рассказать хвост вашей кошки?
• Верветки
• Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
• Срок исковой давности как правильно рассчитать
• Дмитрий Патрушев минсельхоз будет ли преемником Путина
• Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
• Как правильно выбрать машинное масло в Димитровграде?
• Как стать богатым и знаменитым в России?
• Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
• Как стать мудрецом?
• Как правильно установить FreeBSD
• Как стать таким как Путин?
• Где лучше жить - в Димитровграде или в Ульяновске?
• Почему город Димитровград так называется?
• Что такое метамодерн?
• ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
• Тарифы на электроэнергию для майнеров предложено повысить

Установка сложностей никаких не представляет – даже если BIND не включен в состав вашего дистрибутива изначально, его, как правило, несложно найти в официальном репозитории. Скажем, в Ubuntu достаточно одной команды – sudo aptitude install bind9, и спустя 300 килобайт трафика один из лучших DNS-серверов в мире будет трудиться вам на благо.

Самое интересное то, что свежеустановленный BIND уже готов к работе в качестве кэширующего DNS-сервера. То есть он не отвечает ни за какую зону (за исключением localhost), но способен разрешать поступающие к нему запросы, сохраняя ответы в локальном кэше. При повторном запросе ответ уже будет возвращен из кэша, за счет чего достигается некоторая экономия трафика и времени.

Для управления сервером (его исполняемый файл носит название named) можно использовать стандартные средства вашего дистрибутива (скажем, сценарий /etc/init.d/bind9; в других дистрибутивах он может называться просто bind или named). Помимо этого, существует специальная утилита rndc (замечу, что, поскольку во время работы она взаимодействует с уже запущенным демоном named, то запускать его она как раз и не умеет). Чаще всего вы будете сталкиваться с командой rndc reload [zone], позволяющей перезагрузить зону (или все зоны) после внесения изменений. Состояние сервера вернет вам rndc status. Введите rndc без параметров, и вы узнаете обо всех ее возможностях. Чтобы начать использовать свой DNS-сервер, укажите его IP-адрес в /etc/resolv.conf.

[править] Пусть работает трактор в поле...

Как нетрудно догадаться, чтобы получить IP-адрес, соответствующий имени http://www.yandex.ru, кэширующий сервер будет вынужден итеративно обращаться к различным серверам, начиная с корневого, пока не получит искомое. Для крупного DNS-сервера это вполне нормальный режим работы (заодно пополняющий кэш сведениями о промежуточных серверах), но в нашей небольшой сети мы хотели бы максимально снизить нагрузку и трафик. В случае с BIND львиную долю нагрузки можно переложить на плечи DNS-сервера нашего провайдера, указав в конфигурационном файле named.conf (в Ubuntu его можно найти в /etc/bind) параметр forwarders в разделе options:

options {
. . . другие опции . . .
forwarders {
1.2.3.4; # IP-адрес DNS-сервера провайдера
};
// forward only;
};

Теперь все запросы, на которые наш сервер не сможет ответить из своего кэша, он будет пересылать DNS-серверу провайдера (можно указать и несколько), ожидая от последнего уже готового ответа. Раскомментировав строку forward only, мы вообще запретим нашему серверу самостоятельно искать ответ, даже если ни один из forward-серверов наш запрос не удовлетворит.

Раз уж мы здесь, рассмотрим конфигурационный файл named.conf чуть подробнее. Синтаксис у него, как видите, «Си-подобный», поэтому не забывайте завершать каждую опцию и блок точкой с запятой. Блок options содержит общие для сервера опции, для каждой обслуживаемой зоны должен присутствовать блок zone (обратите внимание на зоны, по умолчанию присутствующие в named.conf; зона «.» – подсказка серверу, где искать корневые серверы, чтобы с чего-то начать).

[править] Своя зона

Что еще можно сделать, имея собственный DNS-сервер? Ну, например, мы можем создать «локальную» зону для наших внутренних узлов. Скажем, чтобы по адресу http://webserver.local открывалась наша внутренняя интернет-страничка, а ftp://ftpserver.local вел на FTP-сервер. Конечно, можно прописать необходимые соответствия в /etc/hosts на каждом узле локальной сети, но зачем так усложнять себе жизнь?

Итак, в named.conf добавляем описание нашей «зоны»:

zone “local” {
type master;
file “/etc/bind/local.db”;
};

И в файл /etc/bind/local.db заносим информацию о наших узлах:

$TTL 3d
@ IN SOA admin.ns.local. (
1 ; Порядковый номер
2d ; Период обновления
1h30m ; Повторение попытки
1w ; Устаревание slave-зоны
1h ) ; Время жизни отрицательных ответов
;
IN NS ns.local.
ns IN A 192.168.0.254
webserver IN A 192.168.0.2
ftpserver IN CNAME webserver.local.

В подробности вдаваться не будем – если интересно, ответы на все вопросы вы найдете в замечательной документации (man 5 named.conf). Пока достаточно знать, что A-запись ставит в соответствие имя хоста его IP-адресу, а CNAME-запись позволяет указать для хоста дополнительное имя. NS указывает на DNS-сервер, отвечающий за данную зону (т.е. на наш сервер). Полные доменные имена обязательно должны заканчиваться точкой, имена без точки будут дополняться именем зоны. Ну и нужно знать про еще одну запись – PTR, отвечающую за «обратное» разрешение (т.е. поиск доменного имени по IP-адресу), для которого нужно создать еще и in-addr.arpa-зону:

zone “0.168.192.in-addr.arpa” {
type master;
file “/etc/bind/0.168.192.in-addr.arpa.db”;
};

Соответствующий файл 0.168.192.in-addr.arpa.db:

• Метамодернизм в позднем творчестве В.Г. Сорокина
• ЛитРПГ - последняя отрыжка постмодерна
• "Ричард III и семиотика"
• 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
• Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
• Литература
• Метамодерн
• Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
• Как избавиться от комаров? Лучшие типы ловушек.
• Что делать если роблокс вылетает на windows
• Что делать, если ребенок смотрит порно?
• Почему собака прыгает на людей при встрече?
• Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
• О чем может рассказать хвост вашей кошки?
• Верветки
• Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
• Срок исковой давности как правильно рассчитать
• Дмитрий Патрушев минсельхоз будет ли преемником Путина
• Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
• Как правильно выбрать машинное масло в Димитровграде?
• Как стать богатым и знаменитым в России?
• Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
• Как стать мудрецом?
• Как правильно установить FreeBSD
• Как стать таким как Путин?
• Где лучше жить - в Димитровграде или в Ульяновске?
• Почему город Димитровград так называется?
• Что такое метамодерн?
• ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
• Тарифы на электроэнергию для майнеров предложено повысить

$TTL 3d
@ IN SOA admin.ns.local. (
1 ; Порядковый номер
2d ; Период обновления
1h30m ; Повторение попытки
1w ; Устаревание slave-зоны
1h ) ; Время жизни отрицательных ответов
;
IN NS ns.local.
2 IN PTR webserver
254 IN PTR ns

Фигурирующую в самом начале SOA-запись можно, не вдаваясь в особые подробности, скопировать из какого-нибудь файла-примера – в ней задаются преимущественно различные таймауты, и значения по умолчанию обычно неплохо подходят. Точка с запятой начинает комментарий.

На всякий случай замечу, что файлы зон вы вольны называть как душе угодно. Просто для удобства принято, чтобы имя файла соответствовало обслуживаемой зоне: сразу видно, за что именно тот или иной файл отвечает, и не обязательно сверяться с named.conf.

Теперь машины нашей локальной сети будут получать нужные адреса при запросах к «зоне» local (при условии, что в настройках в качестве DNS-сервера указан наш), ну а запросы к другим зонам будут обслуживаться как в случае кэширующего сервера.

[править] Служить бы рад...

Рассмотрим еще один случай. Предположим, что пользователи вашей небольшой локальной сети активно работают с ресурсами, имена которых обслуживаются зоной вашего провайдера. Безусловно, использование кэширующего DNS-сервера поможет разгрузить и DNS-сервер провайдера, и ваш интернет-канал. Однако можно поступить еще лучше – настроить свой BIND в качестве slave-сервера для зоны провайдера. Подчиненный (slave) сервер DNS предназначен для резервирования основного сервера, т.е. он тоже занимается обслуживанием зоны, но с той разницей, что файл зоны он берет не с диска, а скачивает с основного (master) сервера. Если данные этой зоны меняются не часто, то, единожды загрузив файл зоны (выполнив трансфер зоны), вы сможете самостоятельно обслуживать запросы к ней без обращений к DNS-серверу провайдера. Описывается slave-зона столь же легко:

zone “your.provider.ru” {
type slave;
file “/var/bind/slaves/your.provider.ru.db”;
masters { 1.2.3.4; }; # IP-адрес провайдерского DNS-сервера
};

После перезагрузки сервера (например, командой rndc reload) у вас должен появиться указанный файл. Вручную создавать его не нужно; только позаботьтесь, чтобы каталог /var/bind/slaves принадлежал пользователю BIND или, как минимум, был доступен ему на запись. Теперь ваш сервер сможет авторитативно (то бишь компетентно, официально) отвечать на запросы, касающиеся зоны http://your.provider.ru, без дополнительных обращений к серверу провайдера. (Нужно заметить, что зачастую администраторы DNS-серверов по соображениям безопасности запрещают передачу зоны на произвольные узлы. Если это ваш случай, то попросите провайдера разрешить трансфер для вашего адреса – в конце концов, он тоже заинтересован, чтобы его сервер не беспокоили по пустякам.)

Кстати, то, что мы получили, на самом деле не настоящий slave-сервер, поскольку ни одна из NS-записей зоны http://your.provider.ru на него не ссылается. Так что «чужие» о нашем сервере ничего не узнают и не смогут им пользоваться – а нам оно и не надо... Если же вы настраиваете полноценный slave-сервер для делегированного вам поддомена, то укажите его в файле зоны в качестве NS-сервера наряду с основным:

@ IN NS ns.mydomain.ru.
IN NS slave.mydomain.ru.

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

[править] Другая точка зрения

Допустим, у вас есть делегированный вам домен http://mydomain.ru, который обслуживается вашим DNS-сервером. И здесь может возникнуть две интересные задачи. Во-первых, иногда нужно скрыть некоторую информацию от любопытных глаз, предоставляя ее лишь избранным. Например, ваша компания оказывает услуги доступа в Интернет, и вы хотите, чтобы ваш FTP-сервер посещали лишь ваши абоненты. (Да, это делается настройкой самого FTP-сервера, но было бы неплохо, чтобы посторонние о нем даже и не знали...) Можно ли предоставить адрес вашего сервера только пользователям конкретного домена?

Во-вторых, в локальной сети, как правило, используются «серые» IP-адреса, и обращение к «внешним» по отношению к ней ресурсам связано с трансляцией адресов. Но если ресурс работает на машине с несколькими сетевыми интерфейсами и доступен в том числе и по «серому» адресу, то такая трансляция уже несколько избыточна. Можно ли возвращать пользователям локальной сети «серый» адрес в ответ на запрос, не вынуждая их использовать альтернативные имена типа http://inner.mydomain.ru или тот же «домен» local?

В случае использования BIND9 ответы на оба вопроса будут положительны. В нем появилась одна замечательная штука – оператор view. Он позволяет разграничить «виды» одной и той же зоны для разных групп клиентов. Выглядит это примерно так:

view “clients” {
match-clients { 1.2.3/24; };
zone “mydomain.ru” {
type master;
file “/etc/bind/mydomain.clients.db”;
};
. . . прочие зоны . . .
};
view “others” {
match-clients { any; };
zone “mydomain.ru” {
type master;
file “/etc/bind/mydomain.db”;
};
. . . прочие зоны . . .
};

Такими настройками мы выделили два «вида» – для наших клиентов (сеть 1.2.3.0/24) и всех остальных. Осталось лишь подготовить различные файлы одних и тех же зон для разных «видов», и задача будет решена. Обратите внимание, что если вы приняли решение использовать «виды», то не должно быть ни одного оператора zone, не входящего в какой-нибудь оператор view.

[править] dnsmasq: не BIND’ом единым...

BIND является одним из самых мощных и настраиваемых DNS-серверов. Однако порой его возможности выглядят излишними, а кого-то могут и испугать...

Конечно, BIND нельзя назвать ресурсоемким приложением, особенно применительно к современному оборудованию. Да и настройки не столь обременительны, в чем я, надеюсь, вас убедил. Однако, если единственной задачей, возлагаемой на локальный DNS-сервер, является кэширование запросов пользователей, то для ее решения можно воспользоваться и более специализированным сервисом.

• Метамодернизм в позднем творчестве В.Г. Сорокина
• ЛитРПГ - последняя отрыжка постмодерна
• "Ричард III и семиотика"
• 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
• Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
• Литература
• Метамодерн
• Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
• Как избавиться от комаров? Лучшие типы ловушек.
• Что делать если роблокс вылетает на windows
• Что делать, если ребенок смотрит порно?
• Почему собака прыгает на людей при встрече?
• Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
• О чем может рассказать хвост вашей кошки?
• Верветки
• Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
• Срок исковой давности как правильно рассчитать
• Дмитрий Патрушев минсельхоз будет ли преемником Путина
• Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
• Как правильно выбрать машинное масло в Димитровграде?
• Как стать богатым и знаменитым в России?
• Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
• Как стать мудрецом?
• Как правильно установить FreeBSD
• Как стать таким как Путин?
• Где лучше жить - в Димитровграде или в Ульяновске?
• Почему город Димитровград так называется?
• Что такое метамодерн?
• ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
• Тарифы на электроэнергию для майнеров предложено повысить

Одним из таковых является кэширующий DNS-сервер dnsmasq (по совместительству он может выполнять и роли DHCP-сервера, раздавая машинам локальной сети IP-адреса и прочие сетевые настройки, необходимые для работы, и TFTP-сервера для обеспечения работы бездисковых станций, загружающихся по сети). Его установка выполняется столь же легко, как и BIND – многие дистрибутивы уже включают его в базовой поставке, если нет – почти наверняка вы найдете его в официальном репозитории. Для настройки используется файл /etc/dnsmasq.conf (в других дистрибутивах место расположения может быть иным). То, что конфигурационный файл содержит свыше 400 строк, не должно вас пугать – большую их часть составляют довольно подробные комментарии, да и значимые строки отвечают преимущественно за работу сервера DHCP. Основные же DNS-параметры сосредоточены в начале файла.

На что следует обратить внимание в настройках? Во-первых, dnsmasq руководствуется файлом resolv.conf, определяя, каким DNS-серверам следует перенаправлять запросы, которые не могут быть удовлетворены из кэша. При необходимости вы можете определить другой файл вместо /etc/resolv.conf в параметре resolv-file либо запретить его использование, раскомментировав параметр no-resolv. Параметрами server можно указывать «вышестоящие» DNS-серверы прямо в конфигурационном файле. Причем вы можете даже задавать различные серверы для отдельных доменов:

no-resolv
server=/provider.ru/1.2.3.4
server=4.3.2.1

Эти строки предписывают dnsmasq игнорировать сведения из /etc/resolv.conf и использовать сервер 1.2.3.4 для разрешения имен домена http://provider.ru, и сервер 4.3.2.1 для всех прочих запросов. Помимо выбора forward-серверов, вы можете указать пользователя и группу, от имени которых будет выполняться dnsmasq, конкретизировать интерфейсы, на которых dnsmasq будет ожидать запросы от пользователей и т.д.

Еще одна полезная особенность – по умолчанию dnsmasq при старте читает файл /etc/hosts и заносит найденную там информацию в свой кэш. Благодаря этому можно обеспечить разрешение локальных имен без необходимости синхронизировать /etc/hosts на всех машинах локальной сети. Если вам эта функция не нужна, отключите ее опцией no-hosts.

Помимо редактирования файла dnsmasq.conf, практически все параметры работы можно задать непосредственно в командной строке. Подробности – на man-страницах.

Как видите, собственный DNS-сервер может оказаться весьма полезной (ну, как минимум, интересной) штукой, даже если в вашей локальной сети всего пара машин, а о собственном домене вы и не помышляете. И настроить его совсем не сложно. Так что дерзайте!

[править] Другая точка зрения

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

Традиционно для тестирования работы DNS используются утилиты nslookup и dig. Первая издавна шла в составе пакета BIND, и пользоваться ею очень просто – укажите в качестве аргумента доменное имя, и утилита вернет IP-адрес и сведения о сервере, который использовался для разрешения имени. При необходимости вы можете указать любой DNS-сервер вторым аргументом, которому будет отправлен запрос:

amsand:~$ nslookup linuxformat.ru ns.mezon.ru
Server: ns.mezon.ru
Address: 83.68.34.21#53
Name: linuxformat.ru
Address: 88.212.196.134

Помимо командного режима, nslookup поддерживает и интерактивный – запустите ее без параметров, и вас встретит приглашение командной строки, где возможности тестирования DNS гораздо шире.

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

Одной из полезных особенностей этой утилиты является возможность задать в переменной окружения LOCALRES путь к альтернативному файлу вместо resolv.conf. Эта переменная никак не влияет на работу других программ, так что с помощью dig можно проверить работоспособность нового файла либо использовать альтернативный в особых случаях. LXF