Какие требуются ресурсы для отслеживания разрешения dns имен

Обновлено: 06.07.2024

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

Что такое DNS?

DNS - это часть семейства протоколов и утилит TCP/IP. Microsoft и другие компании предлагают различные версии DNS, работающие на разнообразных операционных системах (в основном на вариантах Unix). Слово domain в названии DNS относится к доменам в Internet, а не к доменной модели NT.

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

Приведенное выше описание применимо к последовательным (итерационным) запросам, которые DNS выполняет от сервера к серверу. DNS также может выполнять рекурсивный запрос, при котором сервер имен доменов передает результаты поиска непосредственно исходному клиенту.

WINS или DNS?

И WINS, и DNS выполняют разрешение имен, которое представляет собой процесс преобразования компьютерного имени в адрес. WINS преобразовывает внутренние имена NetBIOS в IP-адреса, а DNS преобразует в IP-адреса Internet-имена. Если ваша сеть охватывает только вашу компанию и в ней используются только системы компании Microsoft (например, на базе NetBIOS), DNS вам абсолютно ни к чему; все, что необходимо для разрешения имен предлагает WINS. Однако, если вы подключены к Internet, вам следует подумать о том, какой тип связи имеет смысл реализовывать. Если ваши пользователи будут получать доступ к внешним серверам в Internet, необходимо предоставить им возможности, которые выходят за рамки поиска адреса в Internet. Если же, напротив, вы планируете предоставлять ресурсы, к которым будут обращаться пользователи вне вашей сети, следует в своей базе данных DNS сконфигурировать серверы (например, все машины, которые содержат ресурсы для совместного использования) как хосты.

Даже если же вы решили, что непосредственно в данный момент DNS вам не нужна, я думаю, что вы все же захотите узнать о ней чуть подробнее. В Win2K система WINS будет объединена с DNS для того, чтобы в определенной степени автоматизировать процесс конфигурирования DNS, сейчас выполняемый вручную. DNS станет частью Active Directory (AD) и потребует использования протокола разрешения имен.

Установка

Как WINS и DHCP, DNS должна работать на системе NT Server. Установите все три сервиса, выбрав ярлык Service в апплете Network из Control Panel. Вы должны установить их на компьютере, имеющем фиксированный IP-адрес. После того, как вы инсталлировали программное обеспечение DNS и перезагрузили систему, вы увидите, что в группу программ Administrative Tools добавлен DNS Manager.

Конфигурация DNS

Экран 1: Конфигурирование сервера DHCP с IP-адресом сервера DNS

Чтобы использовать DNS, все клиенты должны знать, как связаться с сервером DNS. Вам необходимо только сконфигурировать клиент так, чтобы он мог получить адрес от сервера DHCP. Для корректной работы, конечно же, вам необходимо сконфигурировать сервер DHCP с IP-адресом сервера DNS (как показано на Экране 1). Более подробно процесс конфигурации этой и других опций изложен в статье "Конфигурирование DHCP".

Если конфигурируемый клиент является клиентом DHCP, то больше ничего делать не нужно. Если вы вручную присваиваете IP-адреса, то выберите апплет Network на Control Panel, а затем укажите на ярлык Protocols. Выберите TCP/IP, а затем нажмите на кнопку Properties, после чего появится диалоговое окно TCP/IP Properties. Для установки вручную адреса сервера DNS Server выберите ярлык DNS, как показано на Экране 2.

Экран 2: Конфигурирование адреса сервера DNS на клиенте вручную

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

Если клиент, который вы конфигурируете, должен предоставлять ресурсы внешним пользователям, вам придется также добавить имя домена в диалоговое окно, показанное на Экране 2. Отметим, что эта запись представляет собой имя домена Internet, а не имя домена NT. Обычно, вы можете оставить это диалоговое окно пустым. После того, как вы закончили конфигурацию TCP/IP, перезагрузите свой компьютер.

Конфигурация сервера DNS

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

Во-первых, запустите DNS Manager из папки Administrative Tools. Когда вы впервые его запускаете, то в нем есть только одна запись - Server List, который, в свою очередь, пуст. Указав на Server List, нажмите правую клавишу мыши, а затем выберите опцию New Server. В появившемся диалоговом окне введите имя или IP-адрес вашего сервера DNS. Это должен быть именно IP-адрес сервера, а не его имя, если вы администрируете сервер DNS с другого компьютера. DNS добавит сервер в список. Ниже списка серверов вы увидите запись, соответствующую кэш DNS. Нажмите два раза на пиктограмму кэш, а затем откройте все записи, располагающиеся под ней, как показано на Экране 3.

Экран 3: Просмотр DNS Manager

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

До создания зоны для вашего домена стоит подумать об организации нескольких зон обратного поиска (reverse lookup zone). Эти зоны преобразуют IP-адреса в имена. Если вы сначала создадите эти зоны, они будут очень полезны. При добавлении записей в доменную зону, которые связывают имена доменов с IP-адресами, зоны обратного поиска могут автоматически возвращать эту связь, то есть предоставляют имя, ассоциированное с каждым из IP-адресов.

Экран 4: Добавление зоны обратного поиска.

Экран 5: Добавление первичной зоны.

Теперь вы готовы к тому, чтобы добавить первичную зону. Снова выберите опцию New Zone, нажмите на кнопку Primary, а затем на Next. Введите имя зоны и для генерации файла нажмите Tab. После чего, для завершения процесса создания зоны, нажмите на кнопку Finish.

Экран 5 показывает, что DNS автоматически добавила две записи к базе данных - запись Start of Authority (SOA) и запись Name Server (NS). Запись SOA указывает, какой компьютер является доверенным сервером вашего домена. То есть в случае появления противоречивой информации DNS будет использовать данные, предоставляемые именно этим сервером. Для каждого сервера имен в зоне должна существовать своя запись NS.

Добавление адресов хостов

Экран 6: Просмотр записей о ресурсах в базе данных DNS.

Вы должны добавить записи для каждого хостового компьютера, к которому сервер DNS будет обращаться. Щелкните правой клавишей мыши на зоне и выберите опцию New Host. Введите имя и IP-адрес хоста для того, чтобы создать запись Address (A). Поднимите флажок записи Check the Pointer (PTR) для того, чтобы разрешить генерацию записи обратного поиска, а после этого нажмите кнопку Add Host. Вы можете также добавить псевдоним, щелкнув правой клавишей мыши на зоне, выбрав New Resource Record и добавив запись Canonical Name (CNAME). На Экране 6 показан результат таких действий. Вы можете добавить записи других ресурсов, но их описание выходит за рамки данной статьи.

WINS и DNS

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

Когда вы используете DHCP, вы часто устанавливаете и WINS. На последнем уровне при поиске имени, когда DNS обычно связывает имя хоста с IP-адресом, DNS просто передает свой запрос системе WINS. Поскольку WINS динамическая и компьютеры сами регистрируются в базе данных WINS, то в WINS имеются новые IP-адреса, которые и возвращаются DNS. Затем DNS воспроизводит этот IP-адрес как результат запроса на разрешения имен в DNS. Таким образом WINS позволяет избежать огромной работы по обновлению сервера DNS. Следовательно, WINS станет частью динамической DNS в операционной системе Win2K.

Для конфигурования DNS так, чтобы она использовала WINS, щелкните правой клавишей мыши по имени зоны, выберите Properties, а затем ярлык WINS Lookup в диалоговом окне. Поднимите флажок Use WINS Resolution и введите IP-адрес сервера WINS. Вам необходимо указать IP-адрес, даже если DHCP, WINS и DNS поддерживает один и тот же сервер. Теперь DNS будет использовать WINS в качестве последнего уровня при поиске имен.

Дополнительные ресурсы

Я надеюсь, что прочитав статью до этого места, вам захотелось больше узнать о DNS. Прекрасными темами для углубленного изучения являются вторичные зоны, преобразование зон и кэширование. Наиболее полной книгой по DNS можно назвать книгу Paul Albitz, Cricket Liu and Mike Loukides, DNS and BIND, Third Edition (O'Reilly & Associates, 1998). К другим полезным материалам относятся книги Paul Albitz, Matt Larson, and Cricket Liu, DNS on Windows NT (O'Reilly & Associates, 1998); Drew Heywood, Networking with Microsoft TCP/IP, Second Edition (New Riders, 1997); Mark Minasi and Todd Lammle, Mastering TCP/IP for NT Server (Sybex, 1997). Кроме того, обратите внимание на статьи, указнные во врезке "Статьи по данной теме в журнале Windows NT Magazine".

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

регистрация и проверка сетевых имен;

установление и разрыв соединений;

связь с гарантированной доставкой информации;

связь с негарантированной доставкой информации;

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Небольшая памятка о сути широковещательных запросов.

Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

Пример работы кэша для разрешения имени узла «хр».

Что происходило при этом с точки зрения сниффера.

В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

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

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Операционная система Windows пытается разрешить имена в следующем порядке:

проверяет, не совпадает ли имя с локальным именем хоста;

смотрит в кэш DNS распознавателя;

если в кэше соответствие не найдено, идет запрос к серверу DNS;

если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

Для удобства проиллюстрирую алгоритм блок-схемой:

Алгоритм разрешения имен в Windows.

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.

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

При попытке запуска команды ping servername система проделает следующее:

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Суффиксы DNS и их порядок в выводе ipconfig /all.

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

Это поведение иногда приводит в замешательство начинающих системных администраторов.

При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

Решение проблем с соединениями в сетях Windows (часть 3)

Когда вы вводите эту команду, Windows отправит ping запрос на адрес 127.0.0.1. Независимо от IP адреса вашей машины, Windows всегда будет использовать 127.0.0.1 в качестве адреса локального хоста. Таким образом, альтернативой вышеприведенной команде является команда:

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

Рисунок A: Вы должны увидеть результат успешно выполненного запроса ping, когда опрашиваете адрес локального хоста

Опрос адреса локального хоста ничего не дает для диагностирования проблем взаимодействия с удаленным узлом. Однако он позволяет убедиться в том, что локальный стек TCP/IP работает корректно. Если вы опросите адрес локального хоста и получите отчет об ошибке, говорящий о том, что с опрашиваемым узлом нет связи, это практически всегда означает неправильную настройку TCP/IP, или что определенная часть локального TCP/IP стека повреждена. На собственном опыте могу сказать, что обычно эту проблему можно решить путем удаления существующего TCP/IP протокола с компьютера, и повторного введения этого протокола.

Опрос основного шлюза

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

Предположив, что узлы, с которыми вы хотите связаться, расположены в удаленной сети или другом сегменте вашей корпоративной сети, то в этом случае вам нужно попробовать опросить основной шлюз. Это можно выполнить простым добавлением IP адреса основного шлюза в команду ping. К примеру, если вы посмотрите на рисунок B, вы заметите, что в моей конфигурации TCP/IP адрес основного шлюза будет 147.100.100.100. После этого я просто опрашиваю (ping) этот адрес. В результате этого проводится проверка того, что локальная машина может связаться с основным шлюзом. Это также говорит вам о том, что коммуникации на локальном узле работают, как должно, по крайней мере, на уровне IP адреса.

Рисунок B: Опрос основного шлюза проверяет, что IP пакеты могут достичь основного шлюза сети

Опрос DNS сервера

Итак, к настоящему моменту мы убедились в том, что коммуникация на уровне IP между локальным компьютером и основным шлюзом работает. Однако это не гарантирует того, что имена узлов разрешаются в IP адреса. В первой части этой серии я показывал, как можно использовать полное доменное имя (FQDN) в сочетании с командой ping для проверки того, что DNS сервер выполняет свою работу. Существует пара других способов, с помощью которых вы легко можете проверить разрешение DNS имен.

Во-первых, вы можете опросить IP адрес DNS сервера, как показано на рисунке C. Это не гарантирует того, что разрешение имен работает корректно, однако это позволяет убедиться в том, что локальная машина корректно взаимодействует с DNS сервером.

Рисунок C: Следует убедиться в том, что узел может взаимодействовать с вашим DNS сервером

Во-вторых, вы можете использовать команду Nslookup, чтобы убедиться в том, что разрешение имен работает корректно. Для этого просто введите команду Nslookup, за которой должно идти полное доменное имя удаленного узла. Команда Nslookup должна суметь разрешить полное доменное имя в IP адрес, как показано на рисунке D.

Рисунок D: Команда Nslookup говорит вам, способен ли ваш DNS сервер разрешать имя хоста

Вышеприведенный рисунок сначала может ввести в заблуждение, если вы не привыкли к работе с командой Nslookup. Изначально, кажется, что в этом окне есть отчет об ошибке. Однако если присмотреться, видно, что первая часть вернувшейся информации относится к локальному DNS серверу. Это можно сказать, так как указанный IP адрес совпадает с IP адресом DNS сервера. Однако, нижний раздел вернувшейся информации предоставляет вам IP адреса того узла, который вы запрашивали. Если этот IP адрес есть в списке, DNS запрос был успешным.

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

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

Если вы встретитесь с несовпадением IP адреса, это может указывать на заражение клиента вредоносным ПО, либо это может указывать на заражение DNS. DNS заражение – это процесс, в котором кэш DNS наполняется недействительными или неправильными IP адресами.

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

Пример выполнения этой команды показан на рисунке E.

Очень важно помнить, что только тот факт что DNS кэш содержит неточные IP адреса не означает, что имеет место DNS заражение. Иногда узлам присваиваются новые IP адреса, а DNS КЭШу требуется определенное время, чтобы узнать о внесенных изменениях.

Рисунок E: Если подозреваете, что ваш DNS кэш может содержать неточную информацию, то его нужно сбросить

Заключение

В этой части я объяснил, как можно убедиться в том, что стек локального протокола TCP/IP работает корректно. Затем я рассказал о том, как тестировать способность локального узла связываться с DNS сервером и сервером основного шлюза, и как тестировать разрешение имени хоста. В следующей части этой серии статей я расскажу о других распространенных проблемах, которые можно обнаружить с помощью команды ping, а также начну разговор о проблемах маршрутизации.

Автор: Брайн Позей (Brien Posey)

Постовой

Семейство Лада 110 – это современное продолжение классического стиля ОАО АВТОВАЗ, воплощённое в различных кузовных версиях – седан, хэтчбек, универсал – от непринуждённо-классической до спортивно-динамичной. Автомобили этого семейства дебютировали много лет назад, но до сих пор являются самыми продаваемыми моделями сегмента рынка, ориентированного на российского потребителя.

Этот пост October 29, 2008 at 7:47 pm опубликовал molse в категории Настройка компьютера, Общие статьи для сисадминов. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

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

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

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

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

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

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

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

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

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

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

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

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

Очистка кэша 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 и серверов, которым эти запросы адресованы.

Nslookup

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИТ-администратор с вашей предыдущей работы попросил помочь устранить проблему, которую они не могли решить два дня. В чем же было дело?

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

Как же вы определили, кому принадлежит этот IP-адрес?

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

Какие рекомендации вы могли бы дать коллегам по цеху с учетом уроков, извлеченных из этой истории?

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

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

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

Читайте также: