Служба dns

В своё время открыл для себя простую истину: хочешь запомнить что-то — веди конспект (даже при чтении книги), а хочешь закрепить и систематизировать — донеси до людей (напиши статью). Поэтому, после двух лет работы в системной интеграции (сфере, которую я в бытность свою системным администратором, считал просто рогом изобилия для жаждущих прокачки специалистов), когда я понял, что знания постепенно вытесняются навыками правки документации и конфигурированию по мануалам и инструкциям, для поддержания формы я начал писать статьи о базовых вещах. Например вот — о DNS. Делал тогда я это больше для себя, но подумал — вдруг кому пригодится.

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

Содержание:

1. Основные сведения
2. Немного о формате сообщения DNS
3. TCP и UDP
4. DNS в Windows Server 2008 и 2012
5. DNS и Active directory
6. Источники информации

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

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

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

Итеративный и рекурсивный запросы.

Понятно, что отдельно взятый DNS-сервер не знает обо всех доменах в интернете. Поэтому, при получении запроса на неизвестный ему адрес, например metro.yandex.ru, инициируется следующая последовательность итераций:

DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.

Клиент обращается к держателю зоны ru с тем же запросом.

DNS-сервер зоны RU ищет у себя в кэше соответствующую запись и, если не находит, возвращает клиенту адрес сервера, являющегося полномочным для домена второго уровня — в нашем случае yandex.ru

Клиент обращается к DNS yandex.ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

2. Немного о формате сообщения DNS

Сообщение состоит из 12-байтного заголовка, за которым идут 4 поля переменной длины.

Заголовок состоит из следующих полей:

Формат DNS-сообщения

Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.

Флаги — 16-битовое поле, поделенное на 8 частей:

• QR (тип сообщения), 1-битовое поле: 0 обозначает — запрос, 1 обозначает — отклик.
• opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения — это 1 (инверсный запрос) и 2 (запрос статуса сервера).
• AA — 1-битовый флаг, который означает «авторитетный ответ» (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.
• TC — 1-битовое поле, которое означает «обрезано» (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.
• RD — 1-битовое поле, которое означает «требуется рекурсия» (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query). Мы рассмотрим примеры обоих типов запросов в следующих примерах.
• RA — 1-битовое поле, которое означает «рекурсия возможна» (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).


• 0 — Это 3-битовое поле должно быть равно 0.
• rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Пример (получен с помощью WinDump при выполнении команды ping www.ru):

IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)
IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)

Первая строка — запрос: имя моего ПК, 51036 — случайно выбранный порт отправки, 53- заранее известный порт DNS-сервера, 36587 — идентификатор запроса, + — «требуется рекурсия», А — запрос записи типа А, знак вопроса означает, что это запрос, а не ответ. В скобках — длина сообщения в байтах.

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

На слуху сведения о том, что DNS работает по протоколу UDP (порт 53). Это действительно по умолчанию так — запросы и ответы отправляются по UDP. Однако, выше упоминается наличие в заголовке сообщения флага TC (Truncated). Он выставляется в 1, если размер отклика превысил 512 байт — предел для UDP-отклика — а значит был обрезан и клиенту пришли только первые 512 байт. В этом случае клиент повторяет запрос, но уже по TCP, который ввиду своей специфики, может безопасно передать большие объёмы данных.

Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

В очень крупных организациях с крайне большими зонами, использующих для хранения данных DNS доменные службы Active Directory, перезапуск DNS-сервера может длиться час или более, пока данные DNS извлекаются из службы каталогов. При этом DNS-сервер недоступен для обслуживания клиентских запросов все время, пока длится загрузка зон доменных служб Active Directory.
DNS-сервер с ОС Windows Server 2008 теперь во время перезагрузки загружает данные зоны из доменных служб Active Directory в фоновом режиме, благодаря чему может при этом обрабатывать запросы данных из других зон. При запуске DNS-сервера выполняются следующие действия:

• определяются все зоны, которые должны быть загружены;
• из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
• загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
• начинается обработка запросов и удаленных вызовов процедур (RPC);
• создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса.

едство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.

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

После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.

Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).

Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

habr.com

Литература

• DNS (структура, обработка запросов, ресурсные записи) Семенов Ю.А. (ГНЦ ИТЭФ)
• Лабиринт Internet. Павел Храмцов, Электронинформ, 1996.
• Технологии Интернет (DNS, DHCP, электронная почта и sendmail, информационные сервисы, CGI ),
• Администрирование сети и сервисов InterNet. Учебное пособие, П.Б. Храмцов, 1997.

Служба DNS

2.1 Для чего это нужно?

Числовая IP-адресация не неудобна для человека. Запомнить наборы цифр гораздо труднее, чем слова. Для облегчения стали использовать соответствия числовых адресов именам машин.

Например, для нашего сервера существуют следующие соответствия:

127.0.0.1 localhost
195.208.44.20 ipm.kstu.ru
195.208.44.20 www.ipm.kstu.ru

Длина имени не более 63 символов

Сначала такие соответствия просто сами записывали в файл, брали у знакомых и копировали с FTP-серверов.

Это файлы имеет название hosts, и находится в каталогах:

• Для UNIX — /etc/hosts

• Для Windows — C:windowssystem32driversetchosts

Можете сами изменить его, например, внеся запись:

195.208.44.20 ipm

Теперь вы можете, просто набрав в браузере ipm попасть на сервер www.ipm.kstu.ru. Таким образом, вы можете записать любой сервер.

Однако такой способ присвоения символьных имен был хорош до тех пор, пока Internet был маленьким. По мере роста сети стало затруднительным поддерживать большие списки имен на каждом компьютере. Для того, что бы решить эту проблему, были придумана служба DNS (Domain Name System).

2.2 Принципы организации DNS

Первый стандарт DNS определен в RFC0883 (Domain names: Implementation specification P.V. Mockapetris Nov-01-1983) и RFC0882 (Domain names: Concepts and facilities P.V. Mockapetris Nov-01-1983)

Последняя версия RFC1034 (Domain names — concepts and facilities P.V. Mockapetris Nov-01-1987) и RFC1035 (Domain names — implementation and specification P.V. Mockapetris Nov-01-1987)

Система доменных адресов строится по иерархическому принципу. Администрирование начинается с доменов верхнего, или первого, уровня.

Первые домены верхнего уровня были рассчитаны на США:

• gov — государственные организации

• mil — военные учреждения

• edu — образовательные учреждения

• com — коммерческие организации

• net — сетевые организации

Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа:

• uk — Объединенное королевство

• jp — Япония

• au — Австралия

• ch — Чехия

• su — СССР

• ru — Россия

• и т.п.

IANA — The Internet Assigned Numbers Authority (Управление назначением адресов в Internet) — организация, осуществляющая контроль над распределением доменов первого уровня. Сервер http://www.iana.org/ .

Базу можно посмотреть по адресу whois.iana.org.

Через WWW-интерфейс http://whois.iana.org/

Вслед за доменами первого уровня следуют домены, либо географические (kazan.ru, tatarstan.ru), либо организации (kstu.ru). В настоящее время практически любая организация или физическое лицо может получить свой собственный домен второго уровня (сервер РосНИИРОС — www.ripn.net ).

Далее идут домены третьего уровня, например :

efir.kazan.ru

ipm.kstu.ru

www.kstu.ru — тоже домен третьего уровня.

Систему доменной адресации можно представить следующим образом:

Дерево доменных имен.

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

Система доменных имен — это сервис прикладного уровня, значит, использует транспорт TCP и UDP.

Порт по умолчанию — 53.

Сервис DNS строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен — resolver, а в качестве сервера DNS-сервер (BIND …).

Взаимодействие клиент и сервера по протоколу DNS.

Например, когда мы хотим обратиться к серверу ipm.kstu.ru, ваш браузер, используя resolver, поступает следующим образом:

1. ищет запись ipm.kstu.ru в файле hosts, если не находит, то,

2. посылает запрос на известный DNS-кэширующий сервер (как правило, локальный), если на этом сервере запись не найдена, то,

3. сервер DNS-кэширующий обращается к DNS-ROOT серверу с запросом адреса DNS сервера отвечающего за домен первого уровня ru, если получает адрес, то,

4. сервер DNS-кэширующий обращается к DNS серверу, отвечающего за домен первого уровня ru, с запросом адреса DNS сервера отвечающего за домен второго уровня kstu.ru, если получает адрес, то,

5. сервер DNS-кэширующий посылает запрос на DNS сервер, отвечающий за домен второго уровня kstu.ru, если получает адрес, то,

6. сервер DNS-кэширующий адрес кэширует и передает клиенту

7. клиент обращается по IP адресу — 195.208.44.20

На схеме это выглядит так:

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

2.3 Некоторые типы DNS-серверов

Первичный — сервер, содержащий полную информацию о зоне.

Вторичный — сервер, содержащий копию полной информации о зоне, полученную с первичного сервера.

Кэширующий — содержит записи, которые уже были запрошены

2.4 Формат DNS-сообщения

Формат DNS-сообщения. Слова по 32 бита.

Флаги DNS-сообщения (подробно поле флаги)

QR — Операция:
0 Запрос
1 Отклик

Тип запроса —
0 стандартный
1 инверсный
2 запрос состояния сервера

AA — Равен 1 при ответе от сервера, в ведении которого находится домен, упомянутый в запросе.

TC — Равен при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 байт, но прислано только первые 512.

RD — Равен 1, если для получения ответа желательна рекурсия.

RA — Равен 1, если рекурсия для запрашиваемого сервера доступна.

Нули — Зарезервировано на будущее..

Тип отклика —
0 нет ошибки
1 ошибка в формате запроса
2 сбой в сервере
3 имени не существует

2.5 Некоторые виды записей в DNS

SOA (Start Of Authorisation) — Начало Полномочий.

Запись SOA, обозначает начало зоны. Для каждой зоны должна быть только одна запись SOA.

Синтаксис:

{name} {ttl} addr-class SOA Origin Person in charge

Пример для зоны kstu.ru:

kstu.ru IN SOA ns.kstu.ru. admin.kstu.ru. (

19970315 ; Serial

3600 ; Refresh

300 ; Retry

3600000 ; Expire

3600) ; Minimum

Пояснения:

kstu.ru ({name}) — имя зоны

IN (addr-class) — Запись относится к InterNet.

SOA — вид записи.

ns.kstu.ru (Origin) — первичный сервер зоны.

admin.kstu.ru. (Person in charge) — ответственный за зону. Почтовый адрес лица (admin@kstu.ru), ответственного за зону.

В скобки заключаются параметры, растянутые на несколько строк:

19970315 ; Serial

Серийный номер версии; должен увеличиваться при каждом изменении в зоне — по нему вторичный сервер обнаруживает, что надо обновить информацию. Обычно пишется в виде <год><месяц><число><номер>.

3600 ; Refresh

Временной интервал в секундах, через который вторичный сервер будет проверять необходимость обновления информации.

300 ; Retry

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

3600000 ; Expire

Временной интервал в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей.

3600 ) ; Minimum

Значение времени жизни информации на кэширующих серверах ((ttl) в последующих записях ресурсов).

NS — Сервер Имен

Описывает вторичные DNS-сервера или DNS-сервер которому делегируется подзона.

Синтаксис:

{name} {ttl} addr-class NS Name-servers-name

Пример описания вторичных DNS-серверов:

IN NS ns1.kstu.ru.

IN NS ns2.kstu.ru.

IN NS ns3.kstu.ru.

Пример описания DNS-сервера (ns.ipm.kstu.ru), которому делегируется подзона ipm.kstu.ru:

ipm.kstu.ru. IN NS ns.ipm.kstu.ru.

A — Адрес

Описывает имя указанного IP-адреса

Синтаксис:

{name} {ttl} addr-class A address

Пример:

ipm.kstu.ru. IN A 195.208.44.20

www.ipm.kstu.ru. IN A 195.208.44.20

HINFO — Информация о Хосте

Содержит некоторую информацию о машине, обычно — тип процессора и операционной системы.

Синтаксис:

{name} {ttl} addr-class HINFO Hardware OS

Hardware — тип процессора

OS — операционная система

Пример:

ipm.kstu.ru. IN HINFO "Celeron-600" "RedHat linux"

CNAME (Canonical Name) — Каноническое имя

Указывает псевдоним для официального имени хоста

Синтаксис:

alias {ttl} addr-class CNAME Canonical-name

Пример псевдонимов для хоста ipm.kstu.ru:

www.ipm.kstu.ru. IN CNAME ipm.kstu.ru.

fuzzy.kstu.ru. IN CNAME ipm.kstu.ru.

www.fuzzy.kstu.ru. IN CNAME ipm.kstu.ru.

MX (Mail Exchange) — Почтовый Коммутатор

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

Синтаксис:

name {ttl} addr-class MX preference value mail exchange

preference value — значение приоритета, более низкие числа показывают более высокий приоритет, а приоритеты одинаковые отправители должны использовать в произвольном порядке хосты MX для равномерного распределения нагрузки.

Пример:

mail.kstu.ru. IN MX 0 mail1.kstu.ru.

mail.kstu.ru. IN MX 20 mail2.kstu.ru.

mail.kstu.ru. IN MX 10 mail3.kstu.ru.

0, 10, 20 — указывают приоритет для отправки почты.

Если mail1.kstu.ru не доступен, то почта посылается на mail3.kstu.ru, если и он не доступен то на mail2.kstu.ru.

TXT — Текст

Запись TXT содержит текстовые данные любого вида.

Синтаксис:

name {ttl} addr-class TXT string

Пример:

ipm.kstu.ru. IN TXT "Текстовая информация"

RP — Ответственная Персона

Ответственный за хост. Почтовый адрес лица (admin@ipm.kstu.ru), ответственного за хост.

Синтаксис:

owner {ttl} addr-class RP mbox-domain-name TXT-domain-name

mbox-domain-name — это доменное имя, определяющее почтовый ящик ответственного человека

TXT-domain-name — это имя домена, для которого существует запись TXT

Пример:

www.ipm.ru. IN RP admin.ipm.kstu.ru. ipm.kstu.ru.

ipm.kstu.ru. IN TXT "tel: 34-54-34, fax: 34-54-34"

Пояснение:

www.ipm.ru. — хост за который он отвечает

admin.ipm.kstu.ru — его e-mail (admin@ipm.kstu.ru)

ipm.kstu.ru — это имя записи TXT, которая может содержать телефоны этого лица.

2.6 Программа NSLookUp.

Программа nslookup предназначена для тестирования работы DNS сервера.

Можно использовать как с командной строки, так и в таких программах как CyberKit.

moodle.kstu.ru

Что такое DNS и для чего он нужен

На сервере DNS хранится информация о доменах. Для чего это нужно? Дело в том, что компьютеру не понятны наши с вами буквенные обозначения сетевых ресурсов. Вот, например, yandex.ru. Мы называем это адресом сайта, а для компьютера это всего лишь набор символов. Зато компьютер прекрасно понимает IP-адреса и как к ними обращаться. IP-адреса представлены как четыре числа из восьми символов в двоичной системе счисления. Например, 00100010.11110000.00100000.11111110. Для удобства, двоичные IP-адреса записывают в виде тождественных десятичных чисел (255.103.0.68).

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

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

Как узнать, включён ли DNS-сервер на компьютере

Узнать, включён ли DNS-сервер на вашем компьютере и его адрес можно через «Панель управления».

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

   

2. Появится окно, в нём будет список, где надо найти пункт «Протокол интернета версии 4 (TCP/IPv4)». Откройте свойства этого протокола.

   

3. В свойствах, во вкладке «Общие» будет отмечено «Использовать DNS сервер», если подключение через DNS-сервер включено.

   

4. IP-адрес DNS-сервера будет указан ниже.

Как установить

1. Точно так же, как и в предыдущем пункте, откройте «Панель управления» -> «Сеть и интернет» -> «Просмотр состояния сети и задач». Затем откройте свойства вашего подключения к сети. В появившемся окне откройте свойства «Протокола интернета версии 4 (TCP/IPv4)».
2. Во вкладке «Общие» установите отметку на «Использовать DNS сервер».

   

3. Затем введите IP-адреса основного и альтернативного DNS-серверов. IP-адреса серверов можно найти в интернете. Например, на этой странице: http://www.comss.ru/list.php?c=securedns.
4. Будьте осторожны при выборе: используйте надёжные DNS-сервера. Например, прекрасно подойдут Яндекс.DNS или Google Public DNS. Они бесплатны и надёжны.

Видео: настройка ДНС-сервера

Зачем нужно менять DNS-сервер

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

Кроме того, стандартные DNS-сервера обладают только функциями определения IP-адресов и преобразования их в символьные, но никакой функции фильтрации у них нет. Сторонние DNS-сервера крупных компаний (например, Яндекс.DNS) лишены этих недостатков. Их сервера всегда расположены в разных местах, и ваше подключение идёт через ближайший. Благодаря этому скорость загрузки страниц увеличивается.

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

У них есть встроенный антивирус и чёрный список сайтов. Так что мошеннические сайты и сайты, содержащие вредоносное ПО, будут блокированы, и вы не сможете случайно подхватить вирус.

Сторонние DNS-сервера позволяют обходить блокировки сайтов. Звучит немного абсурдно, ведь мы сказали, что DNS-сервера призваны блокировать нежелательные ресурсы. Но дело в том, что интернет-провайдеры вынуждены запрещать в своих DNS-серверах доступ к сайтам, запрещённым Роскомнадзором. Независимые DNS-сервера Goggle, Яндекса и прочие этого делать совсем не обязаны, поэтому различные торрент-трекеры, социальные сети и прочие сайты будут доступны для посещения.

Как настроить/изменить DNS

1. Чтобы изменить или настроить параметры DNS-сервера, зайдите в «Панель управления» -> «Сеть и интернет» -> «Просмотр состояния сети и задач». Затем откройте свойства подключения, в списке выберите «Протокол интернета версии 4 (TCP/IPv4)» и нажмите «Свойства».

   

2. Нажмите кнопку «Дополнительно», а затем откройте вкладку DNS, чтобы настроить DNS-сервер.

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

Можно настроить DNS-суффиксы. Если вы этого не знаете, то вам эти настройки и не нужны. DNS-суффиксы — очень сложная для понимания вещь и важна скорее самим провайдерам. Если в общих чертах, то все url-адреса делятся на поддомены. Например, server.domain.com. Так вот, com — домен первого уровня, domain — второго, server — третьего. По идее, domain.com и sever.domain.com абсолютно разные ресурсы, с разными IP-адресами и разным содержимым. Однако server.domain.com всё равно находится в пространстве domain.com, который, в свою очередь, находится внутри com. DNS-суффиксом при обращении к server является domain.com. Несмотря на то что IP-адреса разные, server можно найти только через domain.com. В Windows можно настроить, каким образом присваивать суффиксы, что даёт определённые преимущества для внутренних сетей. Что касается интернета, создатели DNS-серверов уже настроили всё необходимое автоматически.

Возможные ошибки и как их исправить

Что делать, если сервер не отвечает или не обнаружен

Что делать, если при попытке зайти на какой-либо сайт, появляется ошибка «Параметры компьютера настроены правильно, но устройство или ресурс (DNS-сервер) не отвечает»? Возможно, что на компьютере по каким-то причинам отключилась служба DNS. Возможно, DNS-сервер, который вы используете, перестал работать.

1. Для начала зайдите в «Панель управления» –> «Система и безопасность» –> «Администрирование» –> «Службы». В списке найдите «DNS-клиент» и щёлкните по нему дважды.

   

2. В окне посмотрите на состояние DNS-клиента, там должно значиться «Выполняется». Если служба отключена, включите её: для этого установите тип запуска «Автоматически».

   

3. Если служба включена, значит, проблемы на стороне DNS-сервера. Попробуем сменить DNS-сервер. Для этого откройте «Панель управления» -> «Сеть и интернет» -> «Просмотр состояния сети и задач». Откройте свойства подключения, затем свойства «Протокола интернета версии 4 (TCP/IPv4)». Нажмите «Использовать DNS сервер», если этот пункт у вас не отмечен, и введите IP-адрес DNS-сервера. Список публичных DNS-серверов можно найти в интернете. Например, можете ввести 8.8.8.8 — публичные сервера Google; или 77.88.8.1 — публичный DNS от Яндекса.

   

4. Обычно проблема решается таким образом. Если всё же не помогло, попробуйте 1) обновить драйвера вашего сетевого адаптера (сетевой карты) — просто скачайте их с официального сайта производителя адаптера, 2) проверьте соединение с интернетом, возможно, проблема с доступом к нему, 3) позвоните оператору связи, возможно, неполадки связаны с техническими работами.

Неправильно разрешает имена

Если DNS-сервер не разрешает имена либо разрешает имена неправильно, то возможны две причины:

1. DNS неправильно настроен. Если у вас точно всё настроено верно, то, возможно, ошибка в самом DNS-сервере. Поменяйте DNS-сервер, проблема должна решиться.
2. Технические неполадки на серверах оператора связи. Решение проблемы то же: использовать другой DNS-сервер.

DHCP-сервер: что это и в чём его особенности

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

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

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

www.remnabor.net

Зачем нужны DNS-сервера и что это такое?

Когда интернет только формировался, то было решено внедрить такую вещь, как домены. Фактически, это имя для узла сети (компьютера, сервера или в более общем смысле слова — хоста).

Дело в том, что на технологическом уровне все устройства в любой сети уже имеют уникальные имена (идентификаторы или IP), но они мало подходят для использования их людьми, ибо представляют из себя набор цифр (читайте про то, что такое АйПи и MAC адреса).

Система же доменных имен оперирует уже полноценными именами (буквы латиницы, цифры, тире и нижнее подчеркивание допускается при их формировании). Их гораздо легче запомнить, они несут смысловую нагрузку (доменное имя моего блога ktonanovenkogo.ru о чем-то уже говорит, а реальный его АйПи 109.120.169.66 малоинформативен) и ими проще оперировать.

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

Вот именно на этих ДНС-серверах (иногда их еще называют NS от Name Server, т.е server имен) и держится весь интернет (как плоский мир на трех китах, стоящих на черепахе). Сервер, если вы помните, это просто служебный компьютер не требующий непосредственного участия человека в своей работе (настроили его — он и пашет в режиме 24 на 7). И таких DNS-серверов в сети очень много.

Как работает DNS и причем тут файл Hosts?

На заре интернета ДНС вообще не существовало. Но как же тогда работала сеть? Как браузер понимал, что ktonanovenkogo.ru — это то же самое, что IP адрес 109.120.169.66? За это дело тогда (да и сейчас тоже) отвечал так называемый файл Hosts, где были прописаны все хосты тогда еще маленького интернета.

Такой файл находился (и сейчас находится) на каждом компьютере пользователя (на вашем тоже он есть) подключенного к сети (как его найти смотрите по приведенной выше ссылке).

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

109.120.169.66 ktonanovenkogo.ru

Любой браузер (что это такое?) на любом компьютере (даже сейчас) при вводе в адресную строку УРЛа (что это такое?) прежде всего обращается к файлу Hosts на предмет поиска там введенного доменного имени, и лишь не найдя там нужной записи обращается за этой информацией к ближайшему DNS-серверу (как правило, это сервак вашего интернет-провайдера).

Сейчас файл Hosts стал рудиментом (пережитком прошлого) и там обычно есть только одна запись (127.0.0.1 localhost) означающая, что локальным хостом нужно считать данный компьютер.

Правда иногда его используют вирусы и другие зловреды, чтобы вместо одного сайта вы попадали на другой (про фишинг слышали?) — ведь для этого достаточно добавить всего одну строчку в файл Hosts (можете сами прописать в нем, например, «109.120.169.66 yandex.ru» и вместо Яндекса браузер вам будет упорно открывать мой блог). Вот именно поэтому его целостность охраняют большинство антивирусов.

Как ДНС-сервера помогают браузеру ориентироваться в сети?

То есть сейчас всеми делами с адресацией в сети рулят именно ДНС-сервера, хотя по своей сути они очень похожи на файл Hosts, но только хранятся на них данные о многих миллионах адресов, да и размещены они удаленно.

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

Еще раз поясню цепочку «метаний» браузера при вводе в него Урл адреса сайта. Итак, сначала он обращается к файлу Hosts, потом к ближайшему ДНС-серваку. Он же в ответ передает нужную информацию (о том, какой именно IP адрес соответствует данному домену) нашему браузеру или запрашивает ее у вышестоящего NS-сервера, если такой информации у себя он не находит.

И лишь только после этого браузер обращается к самому сайту по только что узнанному IP адресу. Долго, правда? Но что делать? Иначе никак.

Правда браузер «хитрит» и сохраняет всю полученную от ДНС серверов информацию в свой кеш, чтобы потом не терять время на эти запросы по поводу IP адреса сайта. Естественно, что кеш хранится не вечно, но часто посещаемые пользователем сайты благодаря этому в браузере будут открываться быстрее (кэш — это вообще вещь!).

Какую роль играют NS-сервера хостинга в DNS системе?

На приведенном выше рисунке показана сильно упрощенная схема, по которой не очень понятна роль отдельных уровней ДНС-серверов. Чуть ниже приведена более развернутая схема (хотя и опять же очень упрощенная).

Если вы владелец сайта, то знаете, что при покупке хостинга (или получении его бесплатно) вам выдают адреса NS-серверов (обычно их два), которые нужно будет прописать у вашего регистратора доменных (как это сделать описано чуть ниже). Например, мой хостер Инфобокс выдал мне два адреса (ns1.pa.infobox.ru и ns2.pa.infobox.ru).

Вопрос, как эти адреса NS участвуют в схеме определения IP-адреса по имени домена. Собственно, это показано на приведенном выше рисунке, но я все же поясню:

1. Как я уже писал выше, ваш компьютер при вводе в адресной строке Урла типа «ktonanovenkogo.ru» в первую очередь связывается с DNS-серверами вашего интернет-провайдера. Если в их кэше имеется IP адрес соответствующий данному домену, то он незамедлительно будет выдан браузеру и все на этом закончится. В смысле, браузер используя полученный АйПи обратится к моему блогу и откроет запрашиваемую вами страницу.
2. Если у вашего интернет-провайдера этой информации не найдется, то он обратится к одному из корневых ДНС-серваков (их не так уж и много и информация на них обновляется не часто — от одного до нескольких раз в сутки).
3. Корневые серваки не могут дать вам сразу пару «домен — IP», но зато могут сказать, где эту информацию наверняка можно найти. Т.е. они выдают интернет-провайдеру адреса тех ДНС-серверов, в которых прописана искомая информация об интересующем домене. В нашем случае это будут как раз те самые адреса NS хостера, где физически в данный момент расположены файлы сайта (ns1.pa.infobox.ru и ns2.pa.infobox.ru в моем случае).
4. Получив эту информацию ваш интернет-провайдер обратится по одному из полученных NS-адресов и найдет там информацию о том, какой АйПи-адрес на данный момент соответствует домену «ktonanovenkogo.ru».
5. ДНС-server вашего интернет-провайдера запомнит эту информацию в свой кэш (чтобы при следующих обращения не повторять всю приведенную выше цепочку запросов) и незамедлительно передаст искомый IP вашему браузеру.
6. И только после этого браузер сможет обратиться к виртуальному серваку моего хостинга, где расположен блог https://ktonanovenkogo.ru. В результате на экране вашего компьютера откроется одна из страниц моего сайта.

ktonanovenkogo.ru

Domain Name System — это сервис для преобразования доменных имен в ip адреса. Система DNS это, по сути сеть в сети. Тк если один dns сервер не знает правильного ip, то он спрашивает у другого и так далее, пока не получит ответ. Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.

dns :: DomainName -> IpAddress

Характеристики[править]

DNS обладает следующими характеристиками:

• Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
• Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
• Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
• Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
• Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

Термины[править]

• Домeн (англ. domain — область) — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имен. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вверху находится корневой домен (не имеющий идентификатора), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго wikipedia, третьего ru). На практике точку перед корневым доменом часто опускают («ru.wikipedia.org» вместо «ru.wikipedia.org.»), но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).
• Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определенному Доменному имени, узлу в дереве имен), тип и поле данных, формат и содержание которого зависит от типа.
• DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
• DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
• DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным.
• Зона — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имен (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже). Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации. Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имен DNS как структуру из зон, а не отдельных узлов/имен, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчиненных. На практике большинство зон 0-го и 1-го уровня (‘.’, ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчиненных уровней без выделения их в дочерние зоны.
• Делегирование — операция передачи ответственности за часть дерева доменных имен другому лицу или организации. За счет делегирования в DNS обеспечивается распределенность администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.

См вики

neerc.ifmo.ru