Primary dns suffix что это
Теперь поговорим о новых возможностях. Имеется довольно много отличий, которые вы увидите в DNS 2003. Вот их список .
- Круговая система обновлений (Round robin). В DNS обычно используется круговая система, когда у сервера запрашиваются ресурсные записи одинакового типа для одного и того же доменного имени. Если это вызывает проблемы, то вы можете отключить использование круговой системы для определенных типов записей. Для этого нужно внести следующие изменения в реестр.
- HKLM\System\CurrentControlSet\Services\DNS\Parameters\
- DoNotRoundRobinTypes
- Тип: REG_DWORD
- Допустимый диапазон значений: любой тип RR (SRV, A, NS)
И, наконец, если вы решили использовать разделы AD , то все объекты DNS удаляются из Глобального каталога ( Global Catalog ). DNSCMD не устанавливается по умолчанию; это должны сделать вы:
- Перейдите на свой дистрибутивный CD.
- Войдите в папку support\tools.
- Щелкните на suptools.msi. Произойдет запуск программы установки, после чего будут установлены средства поддержки (Support tools).
- Автоматическое конфигурирование DNS в DCPromo. Это позволяет автоматически задавать настройки ваших клиентов DNS, если выполняются следующие условия.
- Имеется какое-либо одно сетевое соединение.
- Предпочтительные и альтернативные настройки DNS совпадают.
- Настройки DNS имеются только по одному соединению.
- Автоматическое конфигурирование DNS в DCPromo. Это позволяет автоматически задавать настройки ваших клиентов DNS, если выполняются следующие условия.
В результате будут запрошены текущие серверы DNS , указанные в сетевых настройках, обновлены корневые подсказки, сконфигурированы серверы перенаправления запросов (forwarders) с помощью предпочтительных и альтернативных серверов DNS , заданы настройки DNS с адресом "обратной связи" 127.0.0.1 и затем сконфигурированы все предыдущие предпочтительные и альтернативные серверы DNS . Если все это проходит успешно, то в Event Viewer (Просмотр событий) записывается соответствующий журнал.
- Фиктивные (Stub) зоны. Мы рассматривали stub-зоны выше; по сути это делегированные дочерние зоны, содержащие SOA-записи, NS-записи и A-записи хостов. Они "склеивают" пространства имен. Сервер DNS может запрашивать сервер имен (NS) непосредственно вместо рекурсии. Изменения вносятся в зоны, когда происходит обновление или загрузка главной зоны. Локальный список главных зон определяет физически локальные серверы, из которых нужно выполнять пересылку.
- Серверы перенаправления запросов по условиям. Когда сервер DNS получает запрос от клиента, этот сервер выполняет локальный поиск, то есть просматривает информацию своей зоны или информацию, содержащуюся в его кэше. Если он не получает ответа, то перенаправляет данный запрос (если это задано) серверам DNS, для которых он был сконфигурирован. Перенаправление по условиям является более детальным в том смысле, что вместо простого перенаправления запроса любому серверу перенаправление выполняется в соответствии с конкретными доменными именами, заданными в этих запросах. Во вкладке Conditional Forwarders (Серверы перенаправления по условиям), для вызова которой нужно щелкнуть правой кнопкой на сервере в оснастке DNS management, показано, что соответствующие условия можно задавать по конкретному доменному имени или по IP-адресу сервера перенаправления данного домена
- Group policy (Групповая политика). Это средство конфигурирования клиентов. В среде со многими клиентами DNS не существует средства, с помощью которого можно было конфигурировать всех клиентов сразу, и это конфигурирование исторически выполнялось по отдельности для каждой системы. Такие вещи, как задание доменных суффиксов и может или не может клиент динамически обновлять свои записи, указывались вручную. Средство Group Policy позволяет конфигурировать группу клиентов идентичным образом посредством определенной групповой политики. В конкретные настройки включаются разрешение/отключение динамических обновлений, вывод списка серверов DNS для использования клиентом, предоставление списков суффиксов DNS и передача суффикса первичной DNS в процессе разрешения имен. Если вы разрешаете определенную проблему и при этом используете какую-либо групповую политику, то вам следует помнить, что групповая политика замещает любые другие настройки, например, локальные настройки и/или настройки DHCP. Если вам нужно, то вы можете обойти это правило через реестр, хотя это относится только к динамической регистрации:
- Имя. DoNotUseGroupPolicyForDisableDynamicUpdate
- Раздел (Key). HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- Тип данных. REG_DWORD
- Допустимый диапазон. 0x0 (использовать групповую политику) и 0x1 (использовать локальные настройки)
- По умолчанию (Default). 0x0
Записи реестра клиентской стороны
Ниже приводится более подробный список записей реестра клиентской стороны
Динамическое обновление (Dynamic Update)
Эта настройка политики определяет, включено ли динамическое обновление. Компьютеры, сконфигурированные для динамического обновления, автоматически регистрируют и обновляют свои ресурсные записи DNS с помощью сервера DNS
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Список поиска суффиксов DNS (DNS Suffix Search List)
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: разделенные запятой строки суффиксов DNS
Передача первичного суффикса DNS (Primary DNS Suffix Devolution)
Первичный суффикс DNS передается до тех пор, пока не будет разрешен запрос или суффикс DNS не будет иметь две метки (например, "skillet.com"). Первичный суффикс DNS не может быть передан менее чем двум меткам.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Эта настройка политики разрешает или запрещает клиенту регистрировать PTR-записи. В состоянии по умолчанию клиенты DNS, сконфигурированные для выполнения динамической регистрации DNS, пытаются выполнить регистрацию ресурсной PTR-записи, только если они успешно зарегистрировали соответствующую ресурсную A-запись. Чтобы включить эту политику, выберите Enable (Включить) и выберите одно из следующих значений.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0x0 (отключено), 0x1 (включено)
Интервал обновления регистрации (Registration Refresh Interval)
Эта настройка политики определяет интервал обновления регистрации ресурсных A- и PTR-записей для компьютеров. Эту настройку можно применять только к компьютерам, которые используют динамическое обновление. Если ресурсные записи DNS регистрируются в зонах с включенной очисткой, то значение этой настройки должно быть не больше, чем Refresh Interval (Интервал обновления), заданный для этих зон. Задание величины Registration Refresh Interval, превышающей Refresh Interval этих зон DNS может вызывать преждевременное удаление ресурсных A- и PTR-записей, что может вызвать определенную проблему.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: больше или равно 1800 (секунд)
Замена адресов в конфликтах (Replace Addresses in Conflicts)
Эта настройка политики определяет, будет ли клиент DNS, который пытается зарегистрировать свою ресурсную A-запись, замещать существующие ресурсные A-записи, содержащие конфликтные IP-адреса. Во время динамического обновления зоны, которая не использует Secure Dynamic Update (Защищенное динамическое обновление), клиент может обнаружить, что существующая ресурсная A-запись связывает DNS-имя хоста данного клиента с IP-адресом другого компьютера. Согласно конфигурации по умолчанию этот клиент DNS попытается заместить эту существующую A-запись той A-записью, которая связывает DNS-имя с IP-адресом клиента.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Эта настройка политики определяет, может ли компьютер, выполняющий динамическую регистрацию, регистрировать свои ресурсные A- и PTR-записи путем конкатенации своего имени (Computer Name) и суффикса DNS для конкретного соединения (в дополнение к регистрации этих записей путем конкатенации своего имени и первичного (Primary) суффикса DNS.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0x0 (отключено), 0x1 (включено)
Примечание. Если динамическая регистрация DNS отключена на компьютере (или отключена для конкретного сетевого соединения, к которому применяется эта настройка), то компьютер не будет пытаться выполнять динамическую регистрацию DNS для его A- и PTR-записей независимо от настройки этой политики.
Задание TTL (Срок действия) в A- и PTR-записях (TTL Set in the A and PTR Records)
Эта настройка политики указывает значение для поля TTL (time-to-live) ресурсных A- и PTR-записей, регистрируемых в компьютерах, к которым относится эта настройка.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0-4294967200 (секунд)
По умолчанию: 600
Уровень защиты обновлений (Update Security Level)
Эта политика указывает, какой вид обновлений для регистрации DNS-записей будут использовать компьютеры, к которым применяется эта настройка, – защищенные динамические обновления или стандартные динамические обновления. Чтобы включить эту настройку, выберите вариант Enable и выберите одно из следующих значений.
- Unsecure Followed By Secure (Защищенные после незащищенных). Если выбран этот вариант, то компьютеры отправляют защищенные динамические обновления, только если получают отказ в незащищенных динамических обновлениях.
- Only Unsecure (Только незащищенные). Если выбран этот вариант, то компьютеры отправляют только незащищенные динамические обновления.
- Only Secure (Только защищенные). Если выбран этот вариант, то компьютеры отправляют только защищенные динамические обновления.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Допустимый диапазон: 0 (UnsecureFollowedBySecure), 16 (OnlyUnsecure), 256 (OnlySecure)
Обновление зон доменов верхнего уровня (Update Top Level Domain Zones)
Эта настройка политики указывает, могут ли компьютеры, к которым применяется эта политика, отправлять динамические обновления зонам, имя которых содержит одну метку (т.е. зонам доменов верхнего уровня, например, "com").
По умолчанию клиент DNS, сконфигурированный для выполнения динамических обновлений, будет отправлять динамические обновления зоне или зонам DNS, которые является руководящими для его ресурсных записей DNS , кроме руководящих зон верхнего уровня и корневой зоны.
Если включить эту политику, то компьютеры, к которым применяется эта политика, будут отправлять динамические обновления любой зоне, которая является руководящей для его ресурсных записей, за исключением корневой зоны.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Значения: 0x0 (отключено) и 0x1 (включено)
Базовая поддержка для DNSSEC (RFC 2535)
Важно отметить, что Windows Server 2003 не полностью поддерживает стандарт DNSSEC , но его назначение – использовать криптографию для обеспечения защиты данных, когда информация зоны передается по проводам (или иным способом, например, в случае беспроводных соединений). Это важно, поскольку злоумышленник может перехватывать эту информацию, чтобы найти "стратегически" важные серверы для последующей подделки или компрометации этих серверов. Имеются открытые (public) и личные (private) ключи, которые связываются с этими зонами, чтобы в случае компрометации сервера DNS клиентские компоненты (resolver) все же могли аутентифицировать ресурсные записи из этих зон (например, эти ключи применяются к зонам, а не к серверу).
Эта служба использует с помощью личных ключей шифрованные цифровые подписи, которые отправляются как ресурсные записи от серверов DNS, где хранятся подписанные зоны. Эти записи принимаются клиентским компонентом (resolver), который может аутентифицировать их с помощью открытого ключа. Цифровые подписи и открытые ключи добавляются к подписанной зоне как ресурсные записи. Отметим, что если вы хотите использовать эту службу, то для этого нужно обратиться к реестру (ее нет в оснастке DNS).
Добавьте EnableDnsSec в поле DWORD .
Этому полю передается одно из трех значений в зависимости от того, что вы хотите сделать.
- 0x0 . Исключение ресурсных записей (RR) DNSSEC в ответах на запросы, если это не запись типа NXT, SIG или KEY. В этом случае соответствующие RR будут отправляться только в ответ на записи типа NXT, SIG или KEY.
- 0x2 . Включение ресурсных записей (RR) DNSSEC во все ответы.
- 0x1 (или пустое поле). Если вам нужно, чтобы записи DNSSEC включались в ответы для тех случаев, когда запрос клиента содержит OPT-запись, то добавьте 0x1 или оставьте это поле пустым.
Возможны случаи, когда у вас имеется сервер DNS с несколькими адаптерами ( multihomed ), но вы хотите, чтобы этот сервер DNS выполнял прием и отвечал только через один сетевой адаптер (NIC). Для такого компьютера (два сетевых адаптера, соединенных с различными сетями) существует еще одна задача безопасности: когда один из сетевых адаптеров соединен с Интернет, сконфигурировать DNS, чтобы она принимала запросы только из частной сети. Это можно сделать средствами GUI (графического интерфейса). Для этого используется консоль управления Microsoft. Загрузите оснастку DNS и перейдите в раскрывающееся меню Actions (Действия). Щелкните на кнопке Properties (Свойства). Щелкните на вкладке Interface (Интерфейс), выберите Only The Following IP Addresses (Только следующие IP-адреса) и добавьте свой IP-адрес. По окончании щелкните на кнопке Add.
Записи расширения для DNS (EDNSO)
Исходная спецификация для DNS ограничивала размер пакета 512 октетами. EDNS0 (RFC 2671) позволяет передавать пакеты большего размера. Когда сервер DNS получает запрос (используется протокол UDP), он ищет ресурсную OPT-запись клиента и изменяет свой ответ, чтобы можно было передать столько ресурсных записей, сколько указано этим клиентом в OPT-записи (размер UDP указывается в OPT-записи).
Ведение журналов DNS
Возможности ведения журналов DNS не изменились после Windows 2000, но работать с ними стало удобнее за счет использования графического интерфейса (GUI), который включен как часть оснастки Event Viewer. Вы можете задавать фильтрацию по пользователям, по компьютерам, по идентификаторам событий, по категориям или источникам событий от первого до последнего события и в соответствии с типами событий (обычная информация, предупреждения или ошибки). Ведение журнала DNS (DNS logging) представлено в оснастке DNS или в оснастке Event Viewer, включенной в окно Administrative Tools (Администрирование). Для выбора опций ведения журнала событий и отладки щелкните правой кнопкой на сервере в оснастке DNS и выберите пункт Properties. Появятся вкладки журнала отладки (Debug logging) и журнала событий ( Event logging ), и вы сможете выбрать нужные варианты. Это следующие варианты: Query (Запрос), Notify (Уведомление), Update (Изменение), Questions (Вопросы), Answers (Ответы), Send (Отправка), Receive (Получение), UDP, TCP, Full Packets (Полные пакеты) и Write Through (Сквозная запись).
В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в 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-курьезы из собственной практики – поделитесь в комментариях.
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
- Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
- Резолверпосылает запрос указанному серверу имен.
- Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
- Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
- Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
- пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
- и «вложенности» доменных имен.
- В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
- Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
- Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
- Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
- Запись заголовка — служебную информацию о запросе.
- Запись запроса — повторяет отправленный запрос.
- Запись ответа — собственно, сам ответ.
- Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
- Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.Наглядно приведенную схему можно представить командами:
Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Резюме
Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.
Что еще почитать:
Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.
Начиная с Windows 2000 и выше, групповую политику можно использовать для присвоения основного DNS-суффикса каждому подключенному компьютеру. DNS-суффиксы имеют столь важное значение по нескольким причинам. Во-первых, при правильной настройке это самый простой способ отказаться от использования WINS для разрешения имен. Во-вторых, DNS-суффиксы незаменимы для разрешения имен в сетях Active Directory, состоящих из сегментов, которые не поддерживают пиринговую передачу данных.
Настройки DNS-суффиксов содержатся в разделе групповой политики «Конфигурация компьютера | Политики | Административные шаблоны | Сеть | DNS-клиент» (Computer Configuration | Policies | Administrative Templates | Network | DNS Client). Здесь можно задать основной DNS-суффикс (Primary DNS Suffix) для разных учетных записей. На рис. A показан пример такой настройки.
Рисунок A. Нажмите на изображении для увеличения.После этого следует указать порядок просмотра DNS-суффиксов при поиске. Это необходимо для корректного разрешения имен в лесу и позволяет осуществлять сопоставление имен адресам в зонах DNS, не интегрированных с Active Directory. Поиск настраивается с помощью параметра «Порядок просмотра DNS-суффиксов» (DNS Suffix Search List) в том же разделе (рис. B).
Рисунок B. Нажмите на изображении для увеличения.Я бы порекомендовал делать эти настройки централизованно посредством групповой политики, вместо того чтобы использовать профили безопасности или настраивать каждую систему вручную. Такая конфигурация восполняет пробел, возникающий из-за того, что DHCP отдает управление DNS полностью на откуп клиентской системе. DHCP может назначать домены, но не может определять порядок просмотра суффиксов. Правда, чтобы воспользоваться описанным способом, DNS-конфигурация должна быть прозрачной и понятной самому администратору.
Автор: Rick Vanover
Перевод SVET
Оцените статью: Голосов"DNS Suffix Search List" vs. "Connection Specific DNS Suffix" vs. "Primary DNS Suffix" - what's the nedd of all 3?
Question
Which clients the article Configuring DNS Client Settings tells about in the phrase:
- "Configure a DNS suffix search list that DNS clients can use when they perform queries for unqualified domain names"
Can you explain when a single-NIC-ed client would need differing "DNS Suffix Search List", "Primary DNS Suffix" and "Connection Specific DNS Suffix" NIC's props?
For ex., [1, p.4-59] tells:
-
"When queries are submitted for unqualified names, the DNS Client service by
default first adds the primary DNS suffix to the unqualified name and then submits a query for this name. If that strategy does not work, the DNS Client service thenadds any connection-specific suffixes to the name and submits this new query.But where is here [in description text] "DNS Suffix Search List"?
Added later:
My question asks how or what's for "DNS Suffix Search List" is being used?
And possibly to give a staged example of scenario / need when all suffixes are different.In cited from [1, p.4-59] text the explanation of "DNS Suffix Search List" is missing.
In expalanations that I found and read so far,
all 3 kind of suffixes:
1)
"DNS Suffix Search List",
2)
"Connection Specific DNS Suffix",
3)
"Primary DNS Suffix"
are never explained together and sometimes contradict each another.MCSA/MCSE Self-paced Training Kit (exam 70-291):
implementing, managing, and maintaining a Microsoft Windows Server 2003 network infrastructure / J. C. Mackin, Ian McLean.
MS Press, 2004
ISBN 0735614393Answers
I did not ask how to enter, edit, find or visualize asuffixes.
My question was:
what is the algorithm/description of its use?
how do suffixes are being used?I'm not sure how to take this, i'm trying to be helpful. Please try to be open minded and fully read and comprhend what people are posting. Your continued questions comes across like people need to spoon feed you information. by cutting and pasting appropriate sections to this forum. In the future please take the time to fully read what people have suggested, the information is in there, its up to you to read and understand it.
Taken directly the think i posted i find this answers your question(s).
The default settings of Append primary and connection specific DNS suffixes and Append parent suffixes of the primary DNS suffix allows DNS to query parent DNS zones easily, and allows for an additional DNS zone (connection specific) to be provided manually or via DHCP. This will provide 3 - 4 DNS zones to query by default. This is usually more than enough for most companies. If you need more than what is provided by default then you must use the Append these DNS suffixes (in order) setting.
Things to note from the screen shot are
1) The Primary DNS setting is searched first
2) If specified, the connection specific DNS setting is search directly after the Primary DNS setting
3) The parent DNS setting(s) are appended and searched in order after the connection specific setting.
Note: If you select the Append these DNS suffixes (in order) setting and do not specify a list of DNS suffixes you will disable DNS search orders. This will allow only fully qualified DNS names to be resolved.
Читайте также: