Разбираясь с DNS

Понимание DNS приходит с опытом

Недавно в нашей сети стали возникать блуждающие ошибки разрешения имен DNS. Отлавливать спорадические ошибки разрешения имен — занятие неблагодарное, тем более что с неполадками в DNS я не сталкивался достаточно давно и мои навыки слегка «запылились». Я бы предпочел сразиться с дюжиной других проблем, чем с этой. О существовании службы DNS легко забыть, пока она не начнет давать сбой, — все просто работает, как должно, — Internet, почтовый клиент, почтовый сервер, контроллеры домена. Прошло несколько лет с тех пор, как мне в последний раз довелось устранять проблемы с DNS, так что я расценил возникшие ошибки как знак свыше: пора вспомнить полезные навыки.

Поскольку DNS является основой нормального функционирования среды AD, а также тем звеном, которое соединяет в цепочку все сети в Internet, умение точно обнаруживать источник неполадок в DNS и устранять причину ошибки имеет огромное значение для сопровождения корпоративной сети. Сначала мы рассмотрим особенности решения проблем DNS, не связанные с AD, а затем посмотрим, что привносит AD.

Разрешение имен

Вся иерархия DNS строится от корневого домена (root domain). Корневой домен поддерживается 13 главными отдельными серверами, работа которых обеспечивается коммерческими, правительственными и образовательными учреждениями. В предельном случае эти корневые серверы участвуют в процессе разрешения всех публичных имен в Internet. Когда сетевой компьютер обращается к хосту с именем download.beta.example.com, в первую очередь он должен получить IP-адрес этого хоста. Этот процесс может потребовать до 10 различных запросов DNS, начиная с первого, с которым компьютер обращается к серверу, настроенному как сервер DNS. Стандартный процесс разрешения имен изображен на рис. 1.

Как видно из рисунка, локальный сервер DNS для определения соответствующего IP-адреса использует рекурсивные запросы — один из двух видов запросов DNS (второй тип называется итеративным). Каждый публичный сервер DNS, на который попадает запрос, либо выдает конечный результат (выполняет разрешение имени), если ему известен ответ, либо отправляет на связанный с ним вышестоящий сервер DNS, пытаясь определить неизвестный адрес. Поскольку корневой сервер DNS ничего не знает о конечных индивидуальных хостах в Internet, каковым является компьютер beta.example.com, он сообщает, что ничего не знает о подобном адресе, но советует опросить сервер, обслуживающий домен .com. По мере того как рекурсивный процесс продолжается, разрешение имени может произойти на одном из этапов, и результатом запроса будет либо искомый IP-адрес, либо отказ.

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

О кэшировании

Вернемся к изображенному на рис. 1 процессу разрешения имен, но на этот раз допустим, что локальный сервер DNS уже обращался к почтовому серверу для домена example.com, прежде чем обратиться к download.beta.example.com. В этом случае локальный сервер DNS уже обладает информацией о том, как находить ответственный за домен example.com сервер DNS (по крайней мере, он был таковым несколько минут назад). В этом случае можно обратиться непосредственно к серверу DNS домена example.com вместо того, чтобы вновь обращаться к серверу корневого домена. В этом случае шаги 2, 3, 4 и 5 в процессе разрешения имени окажутся необязательными, благодаря чему коммуникационный трафик снижается на 40%.

Кэширование выполняется на всех уровнях иерархической инфраструктуры DNS. Забегая вперед, скажу, что, если кто-нибудь еще в локальной сети обратится к тому же хосту download.beta.example.com, локальный сервер DNS сможет обработать запрос из локального кэша, поскольку нужный хост уже был недавно найден, и таким образом остаются только шаги 1 и 10 из схемы, приведенной на рис. 1. Это соответствует 80-процентному сокращению коммуникационного трафика.

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

Эта иерархия кэширования, которая выполняется на каждом сервере и клиенте, вовлеченном в процесс разрешения имен DNS, поддерживает работоспособность DNS во всем Internet. Однако кэширование во время поиска и устранения неисправностей может и помешать.

Техника поиска и устранения ошибок

Понимание принципов взаимодействия и кэширования DNS позволит тратить меньше времени на поиск и устранение неисправностей. Давайте рассмотрим, как работает механизм разрешения имен DNS при попытке разрешения имени DNS в IP-адрес. Как показано на экране 2, в первую очередь выполняется проверка имени в локальном кэше, и, если искомый адрес уже известен, он сразу возвращается, и никакого сетевого трафика не генерируется, в противном случае выполняется стандартная процедура разрешения имен. Это кажется очевидным, но все же следует знать, что именно происходит в кэше.

Экран 2. Свойства протокола TCP/IP для сетевого адаптера по умолчанию

В кэше хранятся два основных типа записей — те, которые были найдены в результате запросов к серверу DNS, и те, что были предварительно загружены из файла \%systemroot% system32driversetchosts. Записи первого типа устаревают по истечении определенного интервала времени TTL (Time To Live), который задается в полученном от сервера DNS ответе.

Для просмотра содержимого кэша и определения оставшегося времени можно запустить из командной строки команду ipconfig /displaydns. В качестве примера я запустил поисковый запрос на www.google.com, а затем выполнил проверку ipconfig /displaydns. Как показано на экране 1, запись имеет значение TTL, равное 248 секундам. На момент выполнения запроса DNS время хранения информации TTL о домене google.com составляло 5 минут — что, впрочем, неудивительно для компании, которая имеет обширное и динамически изменяющееся присутствие в Internet. Более статичные организации обычно имеют более длительное значение TTL, например один день (86 400 секунд). В любом случае эта запись будет сохраняться в кэше в течение 5 минут, и, если обратиться к google.com повторно, Windows не будет направлять запрос к серверу DNS, а возьмет адрес из кэша.

Помимо кэширования положительных ответов, Windows также запоминает отрицательные ответы. Отрицательный ответ заключается в том, что сервер DNS считает себя ответственным за данный домен, но у него нет записи о хосте, требуемой в запросе. Хотя в отрицательных ответах не содержится сведений о TTL, Windows запоминает эти ответы на период времени от 5 до 15 минут, в зависимости от используемой версии Windows и дополнительных настроек. Более подробно об управлении кэшированием отрицательных ответов с помощью настроек реестра рассказано во врезке «Управление положительным и отрицательным кэшированием».

Те, кому пришлось столкнуться с проблемами разрешения имен в своей сети, могут очистить кэш DNS с помощью команды ipconfig /flushdns (и вовсе не обязательно править реестр). Очистка кэша DNS — это однократная операция, которая удаляет из памяти все сохраненные значения и позволяет начать все с чистого листа. Очистку кэша можно повторить в любой момент. При этом следует иметь в виду, что, если у вас имеется локальный сервер DNS, он, скорее всего, запоминает все адреса, к которым обращаются компьютеры сети. Чтобы очистить кэш DNS на серверах DNS, стоит воспользоваться оснасткой DNS консоли управления MMC. Для запуска в меню «Пуск» нужно выбрать «Программы», «Администрирование», DNS. Щелкните правой кнопкой мыши на имени сервера DNS и выберите Clear Cache.

Очистка кэша DNS — хорошее средство отладки для тех, кто занимается тестированием в сети чего-либо, связанного с разрешением имен, если нежелательные события произошли за последние 5-15 минут. Следует иметь в виду, что при очистке кэша DNS Windows автоматически сразу загружает в кэш адреса из файла \%systemroot%system32driversetchosts.

О хостах

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

Например, когда несколько серверов отвечают на одно и то же имя, а требуется, чтобы мой компьютер подключался к одному конкретному, я могу использовать файл hosts. Рассмотрим случай, когда несколько серверов доступа Microsoft Outlook Web Access используют общий адрес URL, который задается DNS. Если пользователи начинают жаловаться на возникновение случайных ошибок OWA, как определить, какой из серверов тому причиной? Файл hosts позволяет отказаться от услуг разрешения имен DNS и подставить требуемый адрес — для этого необходимо всего лишь внести в файл hosts значение, оно попадет в кэш и будет присутствовать там постоянно. Файл hosts имеет простой формат — в одной строке указываются IP-адрес и символьное имя. Служба разрешения имен обновляет значение в кэше автоматически при сохранении файла hosts, так что изменения вступают в силу немедленно.

Многосерверные/ многоадаптерные конфигурации

Рассмотрим подробнее схему, приведенную на рис. 2. Мы рассмотрели шаги, выполняемые в тех случаях, когда запрос может быть разрешен из локального кэша. Но если локальный кэш не позволяет выполнить разрешение запроса, то как дальше осуществляется процесс разрешения имени? Windows продолжает процесс разрешения имен, выдавая рекурсивные запросы DNS к серверам, указанным в качестве предпочтительных (настройка сервера DNS выполняется в параметрах протокола TCP/IP для каждого сетевого адаптера, как показано на экране 2). Если Windows не получает никакого ответа от предпочтительного сервера DNS в течение секунды, этот же запрос передается по остальным сетевым интерфейсам с интервалом ожидания 2 секунды. Если ответа по-прежнему нет, Windows выполняет три повторные попытки получить ответ на запрос. Каждый следующий раз устанавливается более длительный интервал ожидания (2, 4 и 8 секунд соответственно), после чего выполняется обращение ко всем остальным серверам DNS по всем имеющимся сетевым интерфейсам. Общее время разрешения адреса DNS не должно превышать 17 секунд.

Каков механизм выбора предпочтительного и приемлемого сетевого адаптера (в Microsoft используют термин under consideration — «рассматриваемый»). Техническая документация Microsoft дает расплывчатые ответы в вопросах разрешения имен. Например, если все серверы DNS для определенного адаптера были опрошены и ни один из них не ответил, данный адаптер исключается из рассмотрения на 30 секунд. Можно предположить, что при этом адаптер временно исключается из категории «приемлемый» на указанный интервал времени, хотя в документации об этом не говорится. Кроме того, в документации Microsoft указано, что служба разрешения имен DNS запоминает время отклика серверов DNS и может выбирать предпочтительный сервер в зависимости от скорости получения ответа на запросы, — видимо, такой же подход используется и для определения предпочтительного адаптера.

Утверждение Microsoft о том, что служба разрешения имен может изменять порядок следования предпочтительных серверов DNS, противоречит настройкам, которые можно найти в расширенных окнах настроек DNS для сетевых адаптеров, где порядок следования определяется администратором при задании конфигурации. В большом количестве документов Microsoft дана другая информация. Поэтому я не очень доверяю сведениям о том, в каком порядке служба разрешения имен обращается к серверам DNS при разрешении имен. Когда мне приходится заниматься поиском и устранением неисправностей, я пользуюсь инструментами типа Network Grep (Ngrep) и WinDump для проверки отправляемых компьютером запросов DNS и серверов, которым эти запросы адресованы.

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

Nslookup

Теперь, разобрав принципы выполнения запросов DNS и то, каким образом служба разрешения имен DNS направляет запросы DNS через установленные в компьютере сетевые интерфейсы, можно задействовать утилиту командной строки Nslookup, которая, безусловно, является одним из основных инструментов решения проблем с DNS и поиска и устранения неисправностей.

Nslookup может запускаться в неинтерактивном режиме и позволяет тестировать поиск и разрешение имен хостов с использованием стандартной службы разрешения имен Windows. Пример:

nslookup www.windowsitpro.com

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

nslookup www.windowsitpro.com 10.0.0.1

Это понадобится, если нужно убедиться, что получаемые ответы исходят именно от данного сервера DNS.

Чтобы более детально вникнуть в процесс разрешения имен, можно запустить Nslookup в интерактивном режиме, который позволяет выбирать сервер, тип запроса (рекурсивный или итеративный) и детализацию отладочной информации. Рассмотрим для примера несколько сценариев обнаружения неисправностей.

Таблица

Как уже упоминалось, в некоторых случаях процесс разрешения имен вынужден пройти всю цепочку до корневых серверов доменов Internet, если ни один другой сервер по пути прохождения запроса не располагает кэшированной информацией, имеющей заданный интервал TTL. Можно выполнить полное прохождение цепочки, чтобы определить, где процесс прерывается. Для воспроизведения этого процесса с помощью Nslookup можно вызвать итеративный (нерекурсивный) запрос поиска для целевого домена, указав при этом один из корневых доменных серверов (список корневых доменов приведен в таблице) в качестве целевого сервера, а затем вручную проследовать по каждому направлению, которое возвращается до получения итогового результата.

Я выполнил поиск для полного доменного имени компьютера (FQDN) www.windowsitpro.com, настроив Nslookup для использования итеративных запросов. В приглашении я ввел параметр Set Norecurse, затем указал корневой сервер с помощью параметра Server и выполнил запрос. Следуя по адресам серверов, я проследил всю цепочку, указывая вручную целевой сервер при каждой итерации. Такой способ дает значительно больше информации для поиска и устранения неисправностей, чем выполнение стандартного запроса к локальному серверу DNS и анализ данных, которые приходят в ответ.

Если для решения задачи не требуется выполнять полный итеративный опрос, а просто нужна более подробная информация о прохождении запросов и возвращаемой информации, можно задействовать ключи Set Debug или Set D2 для отображения отладочной информации о выполнении запроса DNS. На экране 3 приведен результат исполнения примера запроса разрешения имени www.windowsitpro.com. Аналогично ключ Set Type позволяет использовать Nslookup для быстрого поиска определенных типов записей в домене по их типу. Для поиска почтовых серверов требуется указать ключ MX (Mail Exchange), а для серверов имен — NS (Name Server).

Добавим немного AD

Теперь, когда мы познакомились с концепциями кэширования, последовательного и рекурсивного выполнения запросов, а также с приемами диагностики проблем разрешения имен в Internet, не составит большого труда разобраться с теми особенностями, которые привносит AD. Интеграция DNS и AD происходит на двух уровнях: во-первых, DNS является основным механизмом, с помощью которого компьютеры в сети находят другие хосты в среде AD, во-вторых, данные DNS — список существующих хостов и их адреса IP — реплицируются между серверами DNS через механизм репликации AD. Механизмы репликации AD обсуждались на страницах журнала достаточно подробно, так что рассмотрим дополнительную информацию, которая содержится в записях DNS в среде AD.

Записи AD содержат сведения о динамической регистрации, которые создаются автоматически клиентскими компьютерами, серверами и рабочими станциями в среде AD и содержат имя компьютера и его адрес IP. Клиент службы DHCP выполняет процесс регистрации при запуске службы даже в том случае, если адрес присваивается статически. В соответствующих свойствах IP клиент службы DHCP регистрирует свой адрес на серверах DNS, для работы с которыми он настроен. Если вы установили дополнительные сетевые интерфейсы, предназначенные для выполнения специальных задач (например, выделенная сеть для выполнения резервирования на ленточные библиотеки), причем эти интерфейсы не должны отвечать на приходящие по ним запросы клиентов, процесс автоматической регистрации может создать проблемы с разрешением этих имен DNS.

Например, эти специальные сетевые адаптеры могут быть зарегистрированы с адресами IP в DNS, в то время как было нежелательно, чтобы эти сетевые адреса выдавались в качестве возможных вариантов при разрешении имен. Если это все-таки случилось, можно отменить регистрацию сетевого интерфейса. Для этого необходимо выполнить редактирование дополнительных свойств DNS для данного интерфейса и снять флажок Register this connection?s address in DNS («Зарегистрировать это соединение в DNS»), как показано на экране 4. В противном случае Windows обязательно попытается зарегистрировать в DNS все имеющиеся сетевые интерфейсы.

Экран 4. Запрет на регистрацию имени в DNS

Помимо автоматической регистрации этих записей хостов (записи типа А), Windows выполняет для контроллеров доменов регистрацию дополнительных записей сервера (записи SRV). Запись SRV определяет тип участия компьютера в AD при обработке специальных задач аутентификации. Записи SRV не являются уникальными для AD, напротив, это стандартный тип записей DNS, определяющий зарегистрированные в домене службы, хосты, на которых эти службы могут быть найдены, используемые порты и протоколы. Аналогично тому, как записи почтовой службы MX указывают, что служба SMTP может быть найдена на определенном порту (т. е. порт 25) на данном сервере, записи SRV предоставляют ссылку для любого типа служб на любой системе. Например, запись SRV, определяющая хост example.com как Web-сервер, может иметь следующий вид:

_http._tcp.example.com SRV 0 0 80
 www.example.com

Рассматривая этот пример, можно сделать следующие заключения: служба TCP, известная как HTTP, доступна в домене example.com; она доступна по порту 80 для хоста с именем www.example.com. В среде AD контроллер домена регистрирует четыре типа записей SRV на серверах DNS, на работу с которыми он настроен:

_ldap._tcp.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.example.com
SRV 0 0 88 dc.example.com
_ldap._tcp.dc._msdcs.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.dc._msdcs.example.com
SRV 0 0 88 dc.example.com

Эти записи позволяют клиентам AD определять, где найти службы LDAP и Kerberos, которые необходимы в домене example.com для обнаружения других ресурсов AD и аутентификации доступа к этим ресурсам. Эти четыре примера записей SRV сообщают зависящим от AD клиентам о контроллере домена dc.example.com (гипотетический контроллер домена example.com), который будет использоваться для всех видов аутентификации.

С помощью оснастки DNS MMC следует сделать эти записи доступными для серверов DNS. Необходимо также иметь возможность просматривать их с клиента с помощью Nslookup.

Знания — в жизнь

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

Дуглас Тумбс - Редактор журнала Windows IT Pro. help@toombs.us

Ошибка маленькая — проблемы большие

Администратор сети Скотт Рассел расследует мистическую ошибку DNS

«Я дважды переустановил сервер DNS в соответствии с имеющейся документацией, но это не помогло. В конце концов я связался с провайдером и узнал, что головная компания поменяла записи DNS и MX на всех серверах...»

Когда в 8 вечера Скотту Расселу позвонил ИТ-администратор с прежнего места работы, он понял, что это не просто дань вежливости. Два дня назад у них в компании перестало работать подключение к Internet. Сотрудники не могли пользоваться электронной почтой через корпоративный сервер Exchange и регистрироваться в сети Windows 2000 Server. Специалисты по ИТ испробовали все, что могли, но безуспешно. Скотт согласился помочь, и скоро выяснилось, что все дело в ошибке настройки DNS. Рассел работает в области ИТ более 10 лет, в настоящее время он является администратором сети в канадской компании ABC Window Company. Старший редактор Windows IT Pro Энн Грабб побеседовала со Скоттом Расселом о том, как ему удалось определить источник проблемы и восстановить работоспособность компании.

Да, у них ничего не работало: они не могли регистрироваться в сети, пользоваться Internet и электронной почтой. Когда я был там сетевым администратором, мы создали два домена — внешний домен company.com для Web и SMTP и внутренний домен company.net. Мы не регистрировали домен .net, поскольку он был внутренним. Наш провайдер обеспечивал работу Web-сайта компании и держал у себя внешние записи DNS и MX.

Прибыв на место, я в первую очередь проверил настройки DNS, дабы убедиться, что все в порядке. В компании имеется три контроллера домена и два сервера DNS, которые я настраивал, когда работал сетевым администратором — там использовалась служба Windows DNS, интегрированная со службой каталога AD. Я дважды переустановил сервер DNS по той документации, которую подготовил перед уходом. Это был довольно трудоемкий процесс.

Надо было разобраться, почему DNS не мог разрешить IP-адрес контроллера домена для локального домена company.net. Мы задействовали утилиту Traceroute для адреса IP, который мы использовали, как нам казалось, и выяснилось, что в результате возвращается совершенно другой внешний IP-адрес. У нас не было никаких предположений относительно того, что происходит, хотя адрес был из того же диапазона, что и наш. Первым делом мы подумали о внешнем вторжении в сеть.

Ну, во-первых, я зашел на сайт поддержки Microsoft (http://www.support.microsoft.com) и провел там почти два с половиной часа. Пока я изучал материалы сайта, мне пришло в голову, что кто-нибудь мог просто зарегистрировать это доменное имя. Тогда я решил позвонить провайдеру. Через три часа мне сообщили, что неизвестный адрес принадлежит их материнской компании. В этот момент выяснилось, что материнская компания зарегистрировала доменное имя, совпадающее с нашим локальным доменом .net.

Обратившись к ним, мы убедились, что так оно и есть. Они зарегистрировали домен .net и изменили все записи DNS, включая и MX, ничего не сообщив своим пользователям.

Сначала я запросил у провайдера новый IP-адрес и информацию о зонах для их DNS. Затем потребовалось зарегистрировать нашу запись DNS в качестве вторичного сервера DNS для их сервера DNS, чтобы мы смогли зарегистрироваться в системе и выполнить необходимые изменения. Я добавил вторичную зону в нашу запись DNS и настроил их DNS в качестве вторичного DNS у нас, так что наш сервер DNS смог распознавать внешние имена company.com корректно.

С этого момента у нас появилась возможность работать с Internet. Затем нам потребовалось реплицировать вторичную зону DNS в AD. Когда мы это сделали, все стало работать нормально, пользователи получили возможность регистрироваться на сервере и работать с электронной почтой.

Во-первых, при возникновении проблем с Internet нужно обязательно обращаться к локальному провайдеру и его материнской компании. Прежде чем менять настройки своих серверов DNS, надо узнать у технического персонала провайдера, не изменяли ли они что-либо в конфигурации. Учитывая нынешние тенденции слияния и поглощения компаний, такое случается сплошь и рядом. Я надеюсь, наш провайдер тоже усвоил, что, изменив свои настройки, следует сообщать об этом клиентам.

И конечно, я хорошо запомнил свою ошибку с использованием домена .net. Теперь для всех внутренних настроек DNS я использую суффикс .local.

Энн Грабб - Старший редактор в Windows IT Pro. Она имеем более чем двадцатилетний опыт работы, является автором и редактором статей, книг и других материалов по компьютерной и юридической тематике. agrubb@windowsitpro.com

Управление положительным и отрицательным кэшированием

Кэширование в Windows выполняется в соответствии с установленными по умолчанию значениями, которые могут варьироваться в зависимости от используемой версии Windows и дополнительных настроек. Для управления кэшированием применяются два параметра реестра.

Раздел HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServices DNSCacheParameters содержит параметры, управляющие продолжительностью хранения в кэше положительных и отрицательных ответов. Эти значения в версиях Windows Server 2003, Windows XP и Windows 2000 слегка отличаются.

Для положительного кэширования в Windows 2000 этот параметр называется MaxCacheEntryTtlLimit, в Window XP и 2003 он называется MaxCacheTtl. Оба параметра указывают максимальный срок, в течение которого положительные ответы могут храниться в кэше. Если этот параметр определен, по умолчанию его значение равно 86400 секундам (1 день). Это значение имеет преимущество перед всеми возможными значениями TTL, которые превышают данное значение. Поэтому, если оставить значение по умолчанию, Windows будет сохранять положительные ответы не более одного дня, даже если указанное значение TTL равно, скажем, пяти дням. Установив значение параметра равным одной секунде, можно практически предотвратить кэширование положительных ответов DNS.

Кэширование отрицательных ответов управляется параметром NegativeCacheTime в Windows 2000, а в Windows XP и 2003 — MaxNegativeCacheTtl. Значение по умолчанию составляет 300 секунд (5 минут) для Windows 2000 и 900 секунд (15 минут) для XP и 2003. Отрицательные ответы, возвращаемые сервером DNS, будут сохраняться в кэше именно такое время, так что, если после первой неудачной попытки сервер DNS получит нормальное разрешение имени, он все равно будет возвращать отказ на этот адрес до того момента, пока не закончится TTL отрицательного ответа. Если вы подключаете новые компьютеры, отрицательное кэширование действительно может вызвать проблемы в случае попытки найти компьютер до того, как запись о его присутствии будет распространена в сети.

Более подробные сведения об этих процедурах можно найти в статьях базы знаний Microsoft «How to Disable Client-Side DNS Caching in Windows 2000» (http://support.microsoft.com/default.aspx?scid=kb;en-us;245437) и «Disable Client-Side DNS Caching in Windows XP and Windows Server 2003» (http://support.microsoft.com/default.aspx?scid=kb;en-us;318803).

Инструменты для поиска и устранения ошибок DNS

В статье, посвященной поиску и устранению неисправностей в работе службы DNS, невозможно обойти вниманием сайт DNSstuff.com (http://www.dnsstuff.com). Этот сайт разработан и поддерживается Р. Скотт Пери. Здесь бесплатно предоставляются средства для работы с DNS, IP-адресами, доменами и т.д., предназначенные для простого и удобного поиска и устранения неисправностей с использованием Web-служб. Эти инструменты позволяют выполнить разрешение имен в IP-адреса, обратный поиск (reverse lookup), поиск WHOIS, а также проверку выбранных адресов IP на вхождение в базу адресов — известных источников спама. Я считаю DNSstuff.com чрезвычайно удобным инструментом для отладки DNS у клиентов.

Примечательно, что предлагаемый этими средствами вариант поиска хоста позволяет автоматически выполнить итеративный запрос DNS, начиная с корневых серверов, и пройти весь путь до конечного имени хоста с использованием удобного и красивого Web-интерфейса. Это избавляет от необходимости выполнять данную процедуру вручную с помощью Nslookup и позволяет продемонстрировать клиентам результаты в гораздо более удобной и понятной форме. Вдобавок DNSstuff.com содержит функцию опроса основных Internet-провайдеров для проверки, не выдают ли они различные кэшированные ответы на один и тот же запрос DNS.