Корневая зона dns что это

Обновлено: 06.07.2024

Корневая зона DNS является верхним уровнем DNS - зоной в иерархическом пространстве имен системы доменных имен (DNS) в Интернете .

До 1 октября 2016 года за корневой зоной контролировала Интернет-корпорация по присвоению имен и номеров (ICANN), которая делегировала управление дочерней компании, действующей в качестве Управления по присвоению номеров в Интернете (IANA). Услуги по распространению предоставляются Verisign . До этого ICANN выполняла обязанности по управлению под надзором Национального управления электросвязи и информации (NTIA), агентства Министерства торговли США . Ответственность за надзор перешла к глобальному сообществу заинтересованных сторон, представленных в структурах управления ICANN.

Комбинация ограничений в определении DNS и в некоторых протоколах, а именно практический размер нефрагментированных пакетов протокола дейтаграмм пользователя (UDP), привела к практическому максимуму 13 адресов корневых серверов имен, которые могут быть размещены в ответах на запросы имен DNS. Однако корневая зона обслуживается несколькими сотнями серверов в более чем 130 точках во многих странах.

СОДЕРЖАНИЕ

Инициализация службы DNS

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

С адресом единственного функционирующего корневого сервера вся остальная информация DNS может быть обнаружена рекурсивно, и может быть найдена информация о любом доменном имени.

Избыточность и разнообразие

Корневые DNS-серверы необходимы для функционирования Интернета, поскольку большинство Интернет-сервисов, таких как World Wide Web и электронная почта, основаны на доменных именах. DNS-серверы - потенциальные точки отказа для всего Интернета. По этой причине несколько корневых серверов распределены по всему миру. Размер пакета DNS в 512 октетов ограничивает ответ DNS тринадцатью адресами, пока расширения протокола ( см. Механизмы расширения для DNS ) не снимут это ограничение. Хотя при использовании сжатия меток в пакет такого размера можно уместить больше записей, тринадцать было выбрано в качестве надежного ограничения. С момента появления IPv6 , Интернет-протокола, пришедшего на смену IPv4 , предыдущие методы были изменены, и дополнительное пространство заполняется серверами имен IPv6.

Управление

Содержимое файла корневой зоны Интернета координируется дочерней компанией ICANN, которая выполняет функции Управления по распределению номеров Интернета (IANA). Verisign создает и рассылает файл зоны различным операторам корневого сервера.

В 1997 году, когда Интернет был передан из-под контроля правительства США в частные руки, NTIA взяло на себя управление корневой зоной. В документе Министерства торговли 1998 г. говорилось, что агентство было «привержено переходу, который позволит частному сектору взять на себя лидерство в управлении DNS» к 2000 г., однако никаких шагов для осуществления перехода предпринято не было. В марте 2014 года NTIA объявило о переходе координирующей роли «глобальному сообществу заинтересованных сторон».

По словам помощника министра торговли по связи и информации Лоуренса Э. Стриклинга, март 2014 года был подходящим временем для начала передачи этой роли глобальному интернет-сообществу. Этот шаг был предпринят после давления в результате разоблачений о том, что Соединенные Штаты и их союзники занимались слежкой. Однако председатель правления ICANN отрицал, что они были связаны, и сказал, что процесс перехода продолжается уже давно. Президент ICANN Фади Шехаде назвал этот шаг историческим и сказал, что ICANN будет двигаться в направлении контроля с участием многих заинтересованных сторон. Различные видные деятели в истории Интернета, не связанные с ICANN, также приветствовали этот шаг.

Объявление NTIA не сразу повлияло на то, как ICANN выполняет свою роль. 11 марта 2016 г. NTIA объявило, что оно получило предлагаемый план передачи своей координирующей роли корневой зоне и рассмотрит его в течение следующих 90 дней.

Предложение было принято, и 30 сентября 2016 г. истек возобновленный контракт ICANN на выполнение функции IANA, что привело к передаче ответственности за надзор глобальному сообществу заинтересованных сторон, представленных в структурах управления ICANN. В качестве компонента плана перехода была создана новая дочерняя компания под названием Public Technical Identifiers (PTI) для выполнения функций IANA, включая управление корневой зоной DNS.

Подписание корневой зоны

С июля 2010 года корневая зона была подписана с помощью подписи DNSSEC , обеспечивая единую привязку доверия для системы доменных имен, которая, в свою очередь, может использоваться для обеспечения привязки доверия для другой инфраструктуры открытых ключей (PKI). Раздел DNSKEY корневой зоны периодически повторно подписывается с ключом подписи ключа корневой зоны, выполняемым проверяемым образом перед свидетелями на церемонии подписания ключа . KSK2017 с ID 20326 действителен с 2020 года.

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

За последнее несколько лет география корневых серверов DNS была существенно расширена. Ещё совсем недавно рабочие узлы корневых серверов были в основном сконцентрированы в Европе и США, то сегодня они появляются в странах Азии, Африки, Южной Америки. В этом году один из узлов сервера K-Root был установлен даже в Иране, с которого до сих пор не сняты до конца западные санкции.

Вопрос расширения корневой системы DNS актуален и для России. Определённый вклад в его решение удалось внести и нам: в августе этого года у нас был размещён один из узлов корневого DNS-сервера K-Root. В этой статье мы расскажем о его архитектуре и об участии в конкурса на его размещение.

Корневые DNS-серверы: краткая справка

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

Начиная с начала 2000-х годов в системе корневых серверов используется технология Anycast. Это способствовало существенному расширению её географии и повышению уровня надёжности. Вокруг каждого корневого сервера выстроена система обслуживающих узлов, расположенных по всему миру.

Операторoм системы серверов K-root является некоммерческая организация RIPE NCC. Рассмотрим подробнее, как устроена система K-root с архитектурной точки зрения.

Архитектура системы K-root

Весной этого года система K-root перешла на новую, модернизированную архитектуру. Чтобы лучше понять суть всех последних изменений, рассмотрим вкратце, как всё было устроено раньше.

роутер, который анонсировал сети k.root участникам точки обмена трафиком;
два NS-сервера для обработки запросов;
коммутатор.

В новой архитектуре понятие “локальный узел” отсутствует вообще. Вместо него используется понятие “удалённый узел” (hosted node).
Удалённые узлы организованы на базе серверов Dell. Никакого сетевого оборудования в составе удалённых узлов нет.
Серверы, на которых установлено специализированное ПО, сами устанавливают BGP-сессию с маршрутизаторами предоставляющего хостинг оператора и анонсируют префиксы K.Root от имени AS25152. Благодаря технологии Anycast различие между основным и удалёнными узлами, по сути, нивелируется.

Для управления конфигурациями используется Ansible (презентация инженера RIPE NCC), что позволяет ускорить и автоматизировать процессы развёртывания ПО. В качестве рабочего ПО используются BIND, NSD и Knot.

Узнать, какой именно сервер установлен на ближайшем к вам узле k.root, можно с помощью утилиты dig:

Для анонсирования префиксов используется exabgp.

Технические требования к локальным узлам

модель семейства Dell Power Edge 2xx (предпочтительнее — R320 или R420);
минимум 16 ГБ оперативной памяти;
многоядерный процессор;
минимум 2 Ethernet-порта c суммарной пропускной способностью 2 ГБ/c;
RAID-контроллер PERC H310
два SATA-диска ёмкостью 500 ГБ каждый;
наличие интегрированного контроллера удалённого доступа iDRAC 7 Enterprise;
наличие у сервера двух блоков питания;
выделение IP-адресов (как IPv4, так и IPv6).

Хостинг К-root: как это получилось у нас

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

О планах по расширению системы K-root мы узнали в апреле 2015 года. Среди кандидатов на расположение новых узлов системы K-root проводился конкурс, в ходе которого оценивались технические и организационные возможности потенциальных хостеров. Немаловажным критерием отбора на этом конкурсе является наличие хорошей связности. Только хорошая связность может быть гарантией того, что новый сервер сможет обслуживать большое количество клиентов.

Мы оформили все необходимые документы, и вскоре наша кандидатура была одобрена.

После этого мы заказали сервер, соответствующий предъявляемым RIPE NCC требованиям, и к августу ону же был установлен в одном из наших дата-центров.

Размещение узла K-root — проект абсолютно некоммерческий. Перед установкой сервера мы подписали с RIPE NCC протокол о взаимопонимании (образец на английском языке можно посмотреть здесь), в котором прямо указывается, что обе стороны выражают заинтересованность в улучшении связности системы DNS — и при этом ни слова о денежно-коммерческой составляющей.

Договор о хостинге узла K-root имеет бессрочный характер. И мы, и RIPE NCC заинтересованы в развитии партнёрских отношений.

Что это нам даёт

Какие преимущества даёт участие в этом некоммерческом проекте нам?

Единственным очевидным преимуществом является пресловутый плюс в карму: мы внесли пусть небольшой, но всё-таки вклад в развитие системы 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, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

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

Комбинация ограничений в DNS и некоторых протоколах, а именно практический размер нефрагментированных пакетов протокола дейтаграмм пользователя (UDP), привела к решению ограничить количество корневых серверов до тринадцати адресов серверов. Использование произвольной адресации позволяет фактическому количеству экземпляров корневых серверов быть намного больше и составляет 1086 по состоянию на 2 июля 2020 года.

СОДЕРЖАНИЕ

Корневой домен

Корневой домен содержит все домены верхнего уровня Интернета. По состоянию на июль 2015 года он содержит 1058 TLD, в том числе 730 общих доменов верхнего уровня (gTLD) и 301 домен верхнего уровня с кодом страны (ccTLD) в корневом домене. Кроме того, домен ARPA используется для технических пространств имен при управлении адресацией в Интернете и другими ресурсами. TEST домен используется для тестирования многоязычных доменных имен .

Операция резольвера

Когда компьютеру в Интернете необходимо разрешить доменное имя, он использует программу распознавания для выполнения поиска. Преобразователь разбивает имя на метки справа налево. Первый компонент (TLD) запрашивается с помощью корневого сервера для получения ответственного полномочного сервера. Запросы для каждой метки возвращают более конкретные серверы имен, пока сервер имен не вернет ответ на исходный запрос.

На практике большая часть этой информации не меняется очень часто в течение нескольких часов, и поэтому она кэшируется промежуточными серверами имен или кешем имен, встроенным в приложение пользователя. Поэтому запросы DNS к корневым серверам имен могут быть относительно нечастыми. Опрос, проведенный в 2003 году, показал, что только 2% всех запросов к корневым серверам были законными. Неправильное или несуществующее кэширование было причиной 75% запросов, 12,5% - для неизвестных TLD, 7% - для поиска с использованием IP-адресов, как если бы они были доменными именами, и т. Д. Некоторые неправильно настроенные настольные компьютеры даже пытались обновить корневой сервер записи для TLD. Аналогичный список наблюдаемых проблем и рекомендуемых исправлений опубликован в RFC 4697.

Хотя любая локальная реализация DNS может реализовывать свои собственные частные корневые серверы имен, термин «корневой сервер имен» обычно используется для описания тринадцати хорошо известных корневых серверов имен, которые реализуют домен корневого пространства имен для официальной глобальной реализации в Интернете Система доменных имен. Ресолверы используют небольшой файл root.hints размером 3 КБ, опубликованный Internic, для начальной загрузки этого начального списка адресов корневых серверов.

Адреса корневых серверов

Изначально десять серверов находились в США; все теперь работают с произвольной адресацией. Изначально три сервера располагались в Стокгольме (I-Root), Амстердаме (K-Root) и Токио (M-Root) соответственно. У старых серверов было собственное имя до того, как была введена политика использования аналогичных имен. Благодаря Anycast большинство физических корневых серверов теперь находятся за пределами США, что обеспечивает высокую производительность во всем мире.

Карта тринадцати серверов логических имен, включая экземпляры anycasted, по состоянию на конец 2006 г.

Также существует несколько альтернативных систем пространств имен с альтернативным корнем DNS, использующих собственный набор корневых серверов имен, которые существуют параллельно с основными серверами имен. Первый, AlterNIC , вызвал большое количество прессы.

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

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

Контроль корневого сервера

Консультативный комитет системы корневых серверов DNS - это комитет ICANN . В соответствии с уставом ICANN полномочия над работой корневых серверов имен системы доменных имен передаются Консультативному комитету системы корневых серверов DNS.

Файл корневой зоны

Файл корневой зоны - это небольшой (около 2 МБ ) набор данных, публикация которого является основной целью корневых серверов имен. Его не следует путать с файлом root.hints, используемым для начальной загрузки резолвера.

Содержимое файла корневой зоны представляет собой список имен и числовых IP-адресов полномочных DNS-серверов для всех доменов верхнего уровня (TLD), таких как com, org, edu, и доменов верхнего уровня с кодом страны . 12 декабря 2004 г. было указано 773 различных официальных сервера для ДВУ. Позже количество TLD сильно увеличилось. По состоянию на июль 2020 года корневая зона состояла из 1511 TLD (не считая 55 неназначенных доменов, 8 удаленных и 11 тестовых доменов). Другие серверы имен пересылают запросы, для которых у них нет никакой информации об авторитетных серверах, на корневой сервер имен. Корневой сервер имен, используя свой файл корневой зоны, отвечает ссылкой на полномочные серверы соответствующего TLD или указанием на то, что такой TLD не существует.

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