Domain name system

Domain Name System DNS — это сетевая система, содержащая информацию о каждом web-сайте в Интернете. Каждый сайт имеет свой уникальный IP-адрес, имеющий вид 111.222.111.222, а также доменное имя, например merionet.ru. Человеку гораздо проще запомнить доменное имя сайта, нежели набор цифр входящих в IP-адрес. Для этих целей и была разработана система DNS. Подобно записной книжке, в ней хранится таблица соответствия доменного имени сайта и его IP-адреса.

В DNS используется иерархическая древовидная структура серверов и имен. Самый верхний уровень это “root”, представляющий из себя точку (.) и следующий за ним домен верхнего уровня (Top Level Domain). Эти домены бывают двух типов:

  • Generic Top Level Domain (gTLD)
  • Например: .com (коммерческие web-сайты), .net(web-сайты сетевых структур), .org (вэб- сайты организаций), .edu (web-сайты образовательных структур)

  • Country Code Top Level Domain (ccTLD)
  • Например: .ru (Россия), .us (США), .uk (Великобритания), .in (Индия)


Что такое Domain Name System

Данные, которые сообщают веб-серверу, как ответить на ваш запрос называются DNS записи или Zone Files. Каждая запись содержит информацию о конкретном объекте. DNS-сервер использует записи, чтобы отвечать на запросы хостов из определенной доменной зоны. Например, запись address mapping (A) отвечает за связку host name и IP-адреса, а запись reverse-lookup pointer (PTR), за связку IP-адреса и host name. Стоит отметить, что в терминологии DNS очень много различных записей, мы же приведем основные:

  • A Record — Содержит информацию об определенном доменном имени и соответствующем IP-адресе. DNS-сервер обращается к данной записи, чтобы ответить на запрос, содержащий доменное имя. Ответом будет IP-адрес, указанный в записи.
  • PTR Record — Связывает IP-адрес с определенным доменным именем.
  • NS (Name Server) Record — Связывает доменное имя со списком DNS-серверов, отвечающих за данный домен.
  • MX (Mail Exchange) Record — Связывает доменное имя со списком серверов почтового обмена для данного домена. Например, при отправке письма на адрес example@merionet.ru, данное письмо будет перенаправлено на сервер, указанный в MX записи.


Типы запросов DNS

В терминологии DNS существует три типа запросов:

  1. Recursive – Такие запросы можно представить так: “Какой IP-адрес у a.merionet.ru?”
  2. При получении recursive запроса, DNS-сервер выполняет следующие действия:

    • Хост отправляет локальному DNS-серверу запрос “Какой IP-адрес у a.merionet.ru?”
    • DNS-сервер проверяет наличие записи a.merionet.ru в локальных таблицах и не находит ее.
    • DNS-сервер отправляет запрос IP-адреса a.merionet.ru к root-серверу
    • Root-сервер отвечает, что надо обратиться к TLD серверу, отвечающий за домен .ru
    • DNS-сервер, получив ответ от root-сервера, отправляет recursive запрос одному из ccTLD-серверов, отвечающих за домен .ru
    • TLD-сервер отвечает, что нужно обратиться к серверу, отвечающему за домен merionet.ru
    • DNS-сервер отправляет запрос IP-адреса a.merionet.ru к серверу, отвечающему за домен merionet.ru
    • Сервер обращается к A Record и находит там соответствующий IP-адрес для a.merionet.ru
    • Таким образом, хост получает запрашиваемую страницу по адресу a.merionet.ru
  3. Второй тип DNS-запросов – это Iterative запросы. Данные запросы передаются между DNS-серверами, когда один из них не имеет соответствующих записей. Таким образом, инициатор запроса будет контактировать с сервером, который имеет нужную запись
  4. Последний тип запросов – Inverse. Собственно из названия данного запроса понятно, что они работают по инверсному принципу, то есть при известном IP-адресе запрашивается информация о доменном имени.
  • Что такое Domain Name System
  • dns
  • 461
  • 6


  • Да
  • Нет

wiki.merionet.ru

Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста, так и средствами централизованной службы. На раннем этапе развития Internet на каждом хосте вручную создавался текстовый файл с известным именем hosts. Этот файл состоял из некоторого количества строк, каждая из которых содержала одну пару «IP-адрес — доменное имя», например 102.54.94.97 — rhino.acme.com.


По мере роста Internet файлы hosts также росли, и создание масштабируемого решения для разрешения имен стало необходимостью.

Таким решением стала специальная служба — система доменных имен (Domain Name System, DNS). DNS — это централизованная служба, основанная на распределенной базе отображений «доменное имя — IP-адрес». Служба DNS использует в своей работе протокол типа «клиент-сервер». В нем определены DNS-серверы и DNS-кли-енты. DNS-серверы поддерживают распределенную базу отображений, а DNS-клиен-ты обращаются к серверам с запросами о разрешении доменного имени в IP-адрес.

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


Для каждого домена имен создается свой DNS-сервер. Этот сервер может хранить отображения «доменное имя — IP-адрес» для всего домена, включая все его поддомены. Однако при этом решение оказывается плохо масштабируемым, так как при добавлении новых поддоменов нагрузка на этот сервер может превысить его возможности. Чаще сервер домена хранит только имена, которые заканчиваются на следующем ниже уровне иерархии по сравнению с именем домена. (Аналогично каталогу файловой системы, который содержит записи о файлах и подкаталогах, непосредственно в него «входящих».) Именно при такой организации службы DNS нагрузка по разрешению имен распределяется более-менее равномерно между всеми DNS-серверами сети. Например, в первом случае DNS-сервер домена mmtru будет хранить отображения для всех имен, заканчивающихся на mmt.ru: wwwl.zil.mmt.ru, ftp.zil.mmt.ru, mail.mmt.ru и т. д. Во втором случае этот сервер хранит отображения только имен типа mail.mmt.ru, www.mmt.ru, а все остальные отображения должны храниться на DNS-сервере поддомена zil.

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


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

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

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

· DNS-клиент обращается к корневому DNS-серверу с указанием полного доменного имени;

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

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


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

Во втором варианте реализуется рекурсивная процедура:

· DNS-клиент запрашивает локальный DNS-сервер, то есть тот сервер, который обслуживает поддомен, к которому принадлежит имя клиента;

· если локальный DNS-сервер знает ответ, то он сразу же возвращает его клиенту; это может соответствовать случаю, когда запрошенное имя входит в тот же поддомен, что и имя клиента, а также может соответствовать случаю, когда сервер уже узнавал данное соответствие для другого клиента и сохранил его в своем кэше;

· если же локальный сервер не знает ответ, то он выполняет итеративные запросы к корневому серверу и т. д. точно так же, как это делал клиент в первом варианте; получив ответ, он передает его клиенту, который все это время просто ждал его от своего локального DNS-сервера.

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

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


Выводы

· В стеке TCP/IP используются три типа адресов: локальные (называемые также аппаратными), IP-адреса и символьные доменные имена. Все эти типы адресов присваиваются узлам составной сети независимо друг от друга.

· IP-адрес имеет длину 4 байта и состоит из номера сети и номера узла. Для определения границы, отделяющей номер сети от номера узла, реализуются два подхода. Первый основан на понятии класса адреса, второй — на использовании масок.

· Класс адреса определяется значениями нескольких первых бит адреса. В адресах класса А под номер сети отводится один байт, а остальные три байта — под номер узла, поэтому они используются в самых больших сетях. Для небольших сетей больше подходят адреса класса С, в которых номер сети занимает три байта, а для нумерации узлов может быть использован только один байт. Промежуточное положение занимают адреса класса В.

· Другой способ определения, какая часть адреса является номером сети, а какая номером узла, основан на использовании маски. Маска — это число, которое используется в паре с IP-адресом; двоичная запись маски содержит единицы в тех разрядах, которые в IP-адресе должны интерпретироваться как номер сети.

· Номера сетей назначаются либо централизованно, если сеть является частью Internet, либо произвольно, если сеть работает автономно.


· Процесс распределения IP-адресов по узлам сети может быть автоматизирован с помощью протокола DHCP.

· Установление соответствия между IP-адресом и аппаратным адресом (чаще всего МАС — адресом) осуществляется протоколом разрешения адресов ARP, который для этой цели просматривает ARP-таблицы. Если нужный адрес отсутствует, то выполняется широковещательный ARP-запрос.

· В стеке TCP/IP применяется доменная система символьных имен, которая имеет иерархическую древовидную структуру, допускающую использование в имени произвольного количества составных частей. Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен. Доменные имена назначаются централизованно, если сеть является частью Internet, в противном случае — локально.

· Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста с использованием файла hosts, так и с помощью централизованной службы DNS, основанной на распределенной базе отображений «доменное имя — IP-адрес».

studopedia.ru

Уровни DNS

Дерево DNS принято делить по уровням: первый, второй, третий и так далее. При этом начинается система с единственного корневого домена (нулевой уровень). Интересно, что про существование корневого домена сейчас помнят только специалисты, благодаря тому, что современная DNS позволяет не указывать этот домен в адресной строке.
рочем, его можно и указать. Адресная строка с указанием корневого домена выглядит, например, так: «site.test.ru.» – здесь корневой домен отделен последней, крайней справа, точкой. Как несложно догадаться, адреса с использованием DNS записываются в виде последовательности, отражающей иерархию имен. Чем «выше» уровень домена, тем правее он записывается в строке адреса. Разделяются домены точками. Разберем, например, строку www.site.nic.ru. Здесь домен www – это домен четвертого уровня, а другие упомянутые в этой строке домены расположены в домене первого уровня RU. Например, site.nic.ru – это домен третьего уровня. Очень важно понимать, что привычный адрес веб-сайта, скажем, www.test.ru, обозначает домен третьего уровня (www), расположенный внутри домена второго уровня test.ru.

Ключевые характеристики DNS

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

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

DNS важна для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS. DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности

  • поддержка динамических обновлений
  • защита данных (DNSSEC) и транзакций (TSIG)
  • поддержка различных типов информации

Как работает DNS

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня — org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторизированным сервером DNS, на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Рассмотрим на примере работу всей системы. Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер знает только IP-адрес сервера DNS, обычно это один из серверов интернет-провайдера. Он спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org?». Сервер DNS обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 поддерживает доменную зону org.» Браузер направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 поддерживает доменную зону wikipedia.org.» Наконец, браузер отправляет свой запрос к третьему DNS-серверу (который является авторизированным сервером для домена wikipedia.org), и получает ответ — IP-адрес. Этот процесс называется рекурсивным поиском.

Имя хоста и IP-адрес не тождественны — хост с одним IP может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки. Запрос на определение имени обычно не идёт дальше кэша DNS, который помнит (ограниченное время) ответы на запросы, проходившие через него ранее. Организации или провайдеры могут по своему усмотрению организовывать кэш DNS. Обычно вместе с ответом приходит информация о том, сколько времени следует хранить эту запись в кэше. Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию. Существует 13 корневых серверов, расположенных по всему миру и привязанных к своему региону, их адреса никогда не меняются, а информация о них есть в любой операционной системе. Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.

Записи DNS

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей[2]:

  • имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
  • тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
  • класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети[3],
  • TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
  • длина поля данных (RDLEN),
  • поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

  • Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
  • Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
  • Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
  • Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
  • Запись NS (name server) указывает на DNS-сервер для данного домена.
  • Запись PTR (point to reverse) или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
  • Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
  • SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Зарезервированные доменные имена

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Интернациональные доменные имена

Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

Программное обеспечение DNS

Серверы имен:

  • BIND (Berkeley Internet Name Domain)
  • djbdns (Daniel J. Bernstein’s DNS)
  • MaraDNS
  • NSD (Name Server Daemon)
  • PowerDNS
  • OpenDNS
  • Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
  • MyDNS

Примечания

  1. Текущая версия корневой зоны всегда находится по адресу: ftp://ftp.internic.net/domain/named.root
  2. RFC 5395 — Domain Name System (DNS) IANA Considerations
  3. Детали по возможным значениям поля: http://tools.ietf.org/html/rfc5395#section-3.2

Документы RFC

  • RFC 1034 — Domain Names — Concepts and Facilities
  • RFC 1035 — Domain Names — Implementation and Specification
  • RFC 1912 — Common DNS Operational and Configuration Errors
  • RFC 1591 — Domain Name System Structure and Delegation
  • RFC 1713 — Tools for DNS Debugging
  • RFC 2606 — Reserved Top Level DNS Names

Интересное

  • Домен.РФ – советы по регистрации от профессионалов
  • DNS безалаберность Вконтакте и других компаний
  • Установка и настройка авторитетного DNS сервера на основе решения PowerDNS
  • Как улучшить анализ и управление сетевым трафиком, наблюдая за DNS

ru.bmstu.wiki

DNS (Domain Name System – система доменных имен) – иерархическая система имен, основанная на распределенной системе базы данных, служащая для разрешения символьных имен в IP-адреса.

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

Становление DNS

На заре становления Интернета (тогда еще он назывался ARPANET), проблема разрешения (трансляции) доменных имен в IP-адреса решалась ведением длинных списков, в которых символьное имя соответствовало IP-адресу. Пережиток этого метода мы можем наблюдать в файле «hosts», который расположен в папке %SystemRoot%system32driversetc.

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

В итоге, в 1983 году Джоном Постелом (Jon Postel) и Полом Мокапетрисом (Paul Mockapetris) была разработана система доменных имен (Domain Name System). Актуальную на данный момент спецификацию DNS можно найти в документах RFC 1034 и RFC 1035, которые датируются 1987 годом.

Терминологический минимум

Домен (Domain – область) – именованная область пространства иерархических имен.

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

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

Следует помнить, что уровни домена считаются справа налево.

Поддомен (Subdomain) – дочерний домен, являющийся частью родительского домена.

Допускается деление поддоменов на 127 уровней, при этом каждая DNS метка не должна превышать 63 символа. Такое деление на поддомены возможно до тех пор, пока полное имя домена не будет превышать длину в 255 символов.

Resolver – это набор программного обеспечения, используемое для разрешения доменных имен.

Функционирование DNS

В качестве примера рассмотрим домен www.volokh.info.

Отметим, что в конце символьного имени ставится точка, которую зачастую опускают, но иногда она требуется в описаниях DNS.

При запросе адреса www.volokh.info., браузер обращается к локальному DNS-серверу, IP-адрес которого зачастую прописан в свойствах подключения Интернет сети. У DNS-сервера запрашивается информация о соответствии символьного имени домена www.volokh.info. IP-адресу. Получив запрос, DNS-сервер проверяет локальный кэш и, в случае отсутствия данных о требуемом домене, сообщает клиенту IP-адрес корневого домена, например 198.41.0.4.

В случае если у корневого DNS-сервера не имеется требуемой информации по домену info., то корневой DNS-сервер сообщает IP-адрес DNS-сервера, ответственного за домен первого уровня. Таким образом, запрос начинает спускаться вниз по иерархии уровней доменов, до тех пор, пока не будет найден DNS-сервер, ответственной за домен www.volokh.info.

Найденный DNS-сервер сообщает клиенту IP-адрес требуемого домена, и клиент подключается к серверу по IP-адресу 50.6.23.170.

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

DNS-запрос может быть рекурсивным и итеративным.

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

Рекурсивный метод запроса справедлив том случае, когда браузер запрашивает у DNS-сервера IP-адрес домена «www.volokh.info.»

1. DNS-сервер, не найдя записей в локальном кэше, обращается к корневому домену «.»;

2. Корневой домен, в свою очередь, сообщает IP-адрес DNS-сервера, ответственного за домен «info.» и DNS-сервер опрашивает уже его;

3. Ответственный сервер за домен «info.» сообщает DNS-серверу IP-адрес сервера, который может сообщить IP-адрес для домена «volokh.info»;

4. DNS-сервер, запросивший IP-адрес домена, опрашивает сервер, ответственный за домен «www.volokh.info.», который, в свою очередь, возвращает нужный IP-адрес;

5. DNS-сервер возвращает IP-адрес клиенту, после чего происходит подключение к серверу по имени 50.6.23.170.

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

Для наглядности, на рис. 1 приведены оба метода запросов:

Recursive and iterative DNS query

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

1. Resolver, для разрешения символьного имени «www.volokh.info.», посылает запрос на свой DNS-сервер;

2. DNS-сервер, получив запрос, отсылает в ответ IP-адрес корневого домена;

3. Resolver посылает запрос разрешения имени корневому DNS-серверу и получает в ответ адрес сервера, ответственного за зону «info.»;

4. Получив адрес DNS-сервера, ответственного за зону «info.», resolver отправляет DNS-запрос этому серверу;

5. DNS-сервер, получив запрос разрешения имени, сообщает адрес сервера, ответственного за домен «volokh.info.»;

6. Resolver посылает запрос серверу, ответственному за домен «www.volokh.info.», который, в свою очередь, возвращает нужный IP-адрес;

7. Resolver, получив IP-адрес для домена «www.volokh.info.», осуществляет подключение к серверу по имени 50.6.23.170.

В случае рекурсивного запроса, DNS-сервер может не опрашивать другие DNS-сервера при условии, если у него в кэше есть информация о требуемом домене.

Зарезервированные доменные имена

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

Список зарезервированных доменов верхнего уровня (top-level domain) состоит из четырех имен: «.test», «.example», «.invalid» и «.localhost».

Помимо перечисленных выше доменов верхнего уровня, зарезервированы доменные имена второго уровня: «example.com», «example.net» и «example.org».

Использование зарезервированных доменных имен позволит избежать конфликтов с существующими доменными именами.

Технические детали DNS

Существует несколько основных реализаций DNS-серверов: BIND, Microsoft DNS Server , PowerDNS и NSD.

BIND (Berkeley Internet Name Domain) – является самой распространенной реализацией DNS-сервера и используется практически всеми корневыми DNS-серверами.

Другие реализации серверов менее распространенны и в основном используются внутри крупных предприятий.

Для ответов на запросы, протокол DNS использует 53 порт протокола UDP (User Datagram Protocol). TCP (Transmission Control Protocol) используется в том случае, когда размер получаемых данных от DNS-сервера превышает 512 байт. При этом, данные также передаются через 53 порт протокола TCP.

Выводы

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

Вся структура Domain Name System является иерархической. Существуют домены первого, второго, третьего и т.д. уровней.

Для повышения эффективности работы DNS, DNS-серверы кэшируют полученные DNS-ответы.

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

2011-07-16 18:49

Понравился сайт? Расскажи о нем друзьям:

Comments to Notes: 0

volokh.info

Иерархия имен в DNS

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

DNS сервера

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

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

Система доменных имен

Иерархия доменных имен начинается с корневого домена без имени (или еще как его называют «домен точка»), далее идут домены верхнего уровня или домены первого уровня. Домены верхнего уровня поделены на три зоны:

  • arpa это специальный домен, используемый для сопоставления адрес — имя
  • Семь трехсимвольных доменов называются общими (generic) доменами или организационными (organizational) доменами.
  • Двухсимвольные домены, так называемые домены стран или географические домены (ru – Российская федерация, kz — Казахстан), основанные на кодах стран, в соответствии с ISO 3166.

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

in-addr.arpa — специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Имена в домене IN-ADDR.ARPA образуют иерархию цифр, которые соответствуют IP-адресам. Правда, записываются эти имена в обратном порядке относительно написания IP-адреса.

Например, доменное имя just-networks.ru, которое имеет адрес 91.106.203.89 должна быть описана в домене in-addr.arpa как 89.203.106.91.in-addr.arpa, то есть адрес записывается в обратном порядке.

Типы записей DNS

Основные типы записей используемые в протоколе DNS

    • A запись (address record IPv4 ) или запись адреса — основная запись, выполняет связующую роль между именем хоста (just-networks.ru) и IP адресом (5.101.153.37). Если меняется только А запись, то это значит, что наш сайт физически будет размещен на другом хостинге, а все остальные записи останутся работать на старом хостинге.
Название Тип записи Адрес
just-networks.ru A 5.101.153.37
    • AAA запись (address record IPv6 ) или запись адреса — аналогична записи A, только для IPv6.
Название Тип записи Адрес
just-networks.ru AAA FFEA::CA28:1210:4362
    • CNAME запись (canonical name record) или каноническая запись имени (псевдоним) — используется для перенаправления на другое имя (по аналогии с ссылками), частным примером использования CNAME записи, является создание доменных имен для ftp, mail, ssh, например
Название Тип записи Адрес
ftp.just-networks.ru CNAME www.just-networks.ru
mail.just-networks.ru CNAME www.just-networks.ru
ssh.just-networks.ru CNAME www.just-networks.ru
    • MX запись (mail exchange) или почтовый обменник, указывает те сервера, с которыми будет осуществлен обмен для данного домена. То есть определяет сервер, который будет обрабатывать почту для вашего домена. В случае отсутствия MX-записи, запрашивается A-запись
Название Тип записи Адрес
www.just-networks.ru MX mx1.beget.ru
www.just-networks.ru MX mx2.beget.ru
    • NS запись (name server) указывает на DNS сервер текущего домена, так называемые authoritative DNS-серверы. Смена NS-записи, при переходе на другой хостинг, всечёт за собой смену всех записей, соответственно нужно или указывать новые записи или копировать со старого сайта (например, для сохранения почты, нужно скопировать MX-запись со старого хостинга). При неправильном изменении NS записи домена, может привести к остановке работы сайта.
Название Тип записи Адрес
www.just-networks.ru NS ns1.beget.ru
www.just-networks.ru NS ns2.beget.ru
    • TXT запись текстовая запись содержащая 254 байта любой текостовой информации, в основном используется для подтверждения принадлежности домена для севрисов yandex, google.
Название Значение
yandex validate value for yandex

just-networks.ru

Поиск по имени (Hostname Resolution)

Как описано выше, адресация в TCP/IP сети крутится вокруг 32 разрядных номеров. Однако, Вам будет трудно запомнить даже некоторые из них. Поэтому, хосты чаще известны под «обычными», имена типа gauss или strange. Поэтому требуются программы для получения IP адреса по имени машины Этот процесс назван Hostname resolution.

Приложение, которое хочет найти IP адрес по данному имени хоста, не должен пытаться сделать это собственными силами Вместо этого, оно обращается к библиотечным функциям, которые для этого и написаны, они называются gethostbyname (3) и gethostbyaddr (3). Традиционно, эти и ряд других процедур были сгруппированы в отдельной библиотеке названной resolver; в Linux, это часть стандартной libc.

На маленькой сети, подобной Ethernet, или даже на нескольких, не очень трудно поддерживать таблицу, сопоставляющую имена хоста к IP адресам. Эта информация обычно хранится в файле /etc/hosts. При добавлении или перемещении хоста, или при переназначении адресов, все что Вы должны сделать — это изменить файл hosts на всех хостах. Очевидно, что это будет достаточно трудно в сетях с большим количеством машин.

Одно из решений этой проблемы — NIS, Сетевая Информационная Система разработанная Sun Microsystems, названное YP, или Желтыми Страницами. NIS хранит hosts файл (и другую информацию) в базе данных на главном хосте, от которого клиенты могут восстановить свои файлы если это необходимо. Все еще, Этот способ подходит только для сетей среднего размера, потому что он требует поддерживать полную базу данных как на центральной машине, так и на всех остальных.

В Internet, первоначально информация об адресах хранилась в единственном файле HOSTS.TXT. Этот файл поддерживался в NIC, и должен был загружаться всеми участвующими участками. Когда сеть выросла, возникло несколько проблем. Постоянное обновление и постоянная перекачка файла HOSTS.TXT регулярно требовали все больше ресурсов, нагрузка на сервер, который этим занимался стала слишком высока. Но еще большей проблемой стало придумывание новых (не совпадающих с преждними) имен. Вот почему, в 1984 г, введена новая схема — DNS, разработанная Paul Mockapetris и решившая обе проблемы одновременно.

DNS организовывает имена хостов по областям(domain). Область — набор как-то связанных участков, это могут быть машины одной сети (на пример все машины в университетском городке, или всех хосты в BITNET), все они могут принадлежать определенной организации (типа американского правительства), или они просто географически близки. Например, университеты сгруппированы в edu области, с каждым Университетом или Коледжом, использующим отдельную подобласть, в которой и находятся все его хосты. Groucho Marx Университету можно давать groucho.edu область, Отделу математики — maths.groucho.edu. Хост на данной сети к имени области добавляет свое имя и таким образом получает свое полное имя в Internet erdos был бы известен как erdos.maths.groucho.edu.

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

В зависимости от местоположения в иерархии имени, область может быть названа top-level, second-level, или third-level (верхнеуровневой, второго уровня, или третьего уровня). Больше количество уровней встречается редко. Вот несколько верхних областей, которые Вы можете часто увидеть:

  • edu ( Главным образом США ) образовательные учреждения подобно университетам, и т.д..
  • com Коммерческие организации, компании.
  • org некоммерческие организации. Часто частные UUCP сети находятся в этой области.
  • net Gateways и другие административные хосты в сети.
  • mil американские военные учреждения.
  • gov американские правительственные учреждения.
  • uucp Официально, все имена участков прежде используемые как UUCP имена без областей, были перемещены в эту область.

Технически, первый четыре из них принадлежат американской части Internet, но там встречаются и не американские участки. Это особенно верно для net области. Однако, mil и gov используются исключительно в США.

Вне США, каждая страна вообще использует собственную область, названую по имени страны и состоящая из двух букв определенных в ISO-3166. Финляндия, например, использует fi область, fr используется Францией, de Германией, au Австралией и т.д.. Ниже этой высокопоставленной области, NIC каждой страны может свободно раздавать имена хостам. Австралия, например, имеет области второго уровня подобные международным высшим областям, названным com.au, edu.au, и так далее. Другие, подобно Германии, не используйте этот дополнительный уровень, но используют слегка длинные имена, которые непосредственно относятся к организациям управляющих специфической областью. Например, на пример ftp.informatik.uni-erlangen.de.чонечно, эти национальные области не подразумевают что хост расположенный ниже фактически расположен в той же стране; это только сигнализирует что хост регистрировался в NIC этой страны . Шведский изготовитель мог бы иметь отделение в Австралии, и все же регистрировать все хосты в se области.

Теперь, организация пространства имен в иерархии имен областей приятно решает проблему уникальности имен; с DNS, имя хоста должно быть уникально только в пределах одной области Кроме того, полностью квалифицированные имена весьма легко запомнить. Но DNS делает не только это: он позволяет Вам передать работу с подобластями местным администраторам. Например, администратор в Groucho Вычислительном Центре мог бы создать подобласть для каждого отдела; мы уже столкнулись с подобластями физиков и математиков. Когда он решит, что сеть в Отделе Физики слишком большая и хаотичная, чтобы справиться с ней из вне , он может просто передать контроль над physics.groucho.edu областью администраторам этой сети. Тогда они свободны использовать, любые имена хостов и назначать их IP адреса в пределах подсети без вмешательства сверху.

Так, пространство имени раздроблено на зоны, которая управляется своей областью. Обратите Внимание На различие между зоной и областью: область groucho.edu затрагивает все машины в Groucho Marx Университете, в то время как зона groucho.edu включает только хостов которые работают в компьютерном центре непосредственно, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu. На картинке 3.6.2, начало зоны отмечено маленьким кружочком справа от имени области.

На первый взгляд, все эти суета с областями и зонами кажется делает поиск адреса ужасно сложным делом. В конце концов, если нет центрального органа контролируещего какие имена связаны с каким адресом, тогда как — скромное приложение должно его узнавать?!

Теперь начинается действительно техническая часть описания DNS. Если Вы хотите выяснять IP адрес erdos, тогда, DNS говорит, иди и спроси людей, которые управляют им, и они ответят Вам.

Фактически, DNS — гигантская распределенная база данных. Это осуществлено посредством так называемых серверов имен(name server), которые снабжают всех информацией о данной области или нескольких областях сразу. Для каждой зоны имеются по крайней мере два сервера имен, которые содержат всю информацию относительно хостов в этой зоне. Чтобы получить IP адрес erdos, все что Вы должны сделать — обратится к серверу имен зоны groucho.edu, который и передаст Вам требуемые данные.

Легко сказать, а как это сделать, подумали вы. Так как найти сервер имен в Groucho Marx Университет? В случае если ваш компьютер не оборудован address-resolving oracle, DNS также обеспечивает это. Когда ваше приложение хочет найти информацию относительно erdos, оно входит в контакт с местным сервером имен, который проводит так называемый итерационный опрос. Сначала он посылает запрос серверу имен об области корня, спрашивая о адресе erdos.maths.groucho.edu. Сервер имен корня сообщает, что это имя не принадлежит зоне его полномочий, но вместо этого отсылает к edu области. Таким образом, он предлагает Вам войти в контакт с сервером имен зоны edu для получения большего количества информации, и прилагает список всех серверов имен edu вместе с их адресами. Ваш местный сервер имен пошлет запрос одному из них, например a.isi.edu. Также как серверу имен корня, a.isi.edu знает что люди groucho.edu управляют свей зоной сами, и направит Вас на их сервера. Местный сервер имен запросит одного из них, который наконец распознает имя, как принадлежащее к его зоне, и вернет IP адрес.

Кажется, что для поиска одного IP адреса тратится слишком много ресурсов. но это не сравнимо меньше, чем при преждней схеме с HOSTS.TXT. Но все еще имеются места для усовершенствования этой схемой.

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

Конечно, сервер имен не будет хранить эту информацию всегда, а отбросит ее через некоторое время. Этот интервал времени назван time to live(временем жизни), или TTL. TTL задается администратором данной зоны.

Сервера имен, которые содержат всю информацию относительно хостов в пределах данной зоны названы авторитарными для этой зоны и иногда упоминаются как master name servers. Любой запрос относительно хоста в пределах этой зоны будет в конце концов передан одному из этих серверов. Чтобы обеспечить адекватную картину зоны, эти сервера должны быть хорошо синхронизированы. Это достигается с помощью создания одного главного сервера, который загружает зональную информацию из файлов данных, а другие вторичные сервера через равные интервалы времени качают эти данные с главного сервера.

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

Конечно, Вы можете также создать сервер имени, который не будет авторитарным для любой области. Этот тип серверов используется чтобы проверять запросы от местных приложений и кэшировать ответы. Поэтому его называют caching-only сервером. 3.6.5 База данных DNS

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

Единица информации в DNS базе данных названа resource record (записью ресурса), или RR. Каждая запись имеет определенный тип, описывающий тип данных, которые в ней записаны, и определяющий тип сети, к которой она применяется. Последний используется при определении схемы адресования, типа IP адресов (IN класс), или адресов в Hesiod сетях (используемые в MIT), и др. Основной записью ресурсов является запись, которая связывает полное имя области с IP адресом.

Конечно, хост может иметь больше чем одно имя. Однако, одно из этих имен должно быть определенно как официальное, или каноническое имя хоста, в то время как остальные просто псевдонимы. Различие между ними в том, что каноническое имя хоста связано с А записью, в то время как другие только с записью типа CNAME, которая указывает на каноническое имя хоста.

Мы не будем приводить здесь все типы записей, а сделаем это позже, в другой главе, здесь же ограничимся кратким примером. Картинка 3.6.5 показывает часть базы данных области которая загружена на сервере имен для зоны physics.groucho.edu. Кроме A и CNAME записи, Вы можете видеть специальную, занимающую несколько строк, запись сверху файла. Это — SOA запись ресурса, расшифровывается Start of Authority (Начало Власти), которая содержит общую информацию относительно зоны, для которой этот сервер является авторитарным. Она включает, например, время жизни для всех записей.

Обратите Внимание что все имена в файле с примером, которые не заканчиваются точкой интерпретируются относительно groucho.edu области. Специальное имя «@», используемое в SOA записи при обращении к имени данной области.

Мы видели, что сервера имен для groucho.edu области так или иначе должен знать хоть что-то относительно зоны физиков так, чтобы направлять запросы серверам имен. Это обычно достигается парой записей: NS запись дается FQDN, и А запись, ассоциирующая его имя с IP адресом. Так как эти записи появляются вместе, они часто называются склеенными записями. Это — фактически единственный случаи записи, в которой родительская зона держит информацию относительно хостов в зоне подчиненного. Склеенные записи указывающие на сервера имен для physics.groucho.edu показаны на рисунке

Authoritative Information on physics.groucho.edu

@ IN SOA { niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 1034 ;

serial no 360000 ;

refresh 3600 ;

retry 3600000 ;

expire 3600 ;

default ttl — 51 — } ;

Name servers IN NS niels IN NS gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23;

Theoretical Physics (subnet 12) niels IN A 149.76.12.1 IN A 149.76.1.12 nameserver IN CNAME niels otto IN A 149.76.12.2 quark IN A 149.76.12.4 down IN A 149.76.12.5 strange IN A 149.76.12.6 … ;

Collider Lab. (subnet 14) boson IN A 149.76.14.1 muon IN A 149.76.14.7 bogon IN A 149.76.14.12 …

Фрагмент файла amed.hosts для Отдела Физики.

После обнаружения IP адреса, принадлежащего хосту, иногда желательно выяснять каноническое имя хоста, соответствующее данному адресу. Это называется reverse mapping(обратное отображение) и используется несколькими сервесами, чтобы проверить идентичность клиента. При использовании единственного hosts файла, обратный поиск заключается просто в проверке этого файла. В DNS, конечно не проводится просмотр всего адресного пространсва. Вместо этого, создана специальная область, inaddr.arpa, она содержит IP адреса всех хостов. в перевернутой dotted-quad записи Например, IP адрес 149.76.12.4 соответствует имени 4.12.76.149.in-addr.arpa. Тип записи ресурса, связывающий это имя с именем, называется PTR. Zone data for the groucho.edu zone.

@ IN SOA { vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 ;

serial no 360000 ;

refresh 3600 ;

retry 3600000 ;

expire 3600 ;

default ttl } …. ;

Glue records for the physics.groucho.edu zone physics IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 …

Фрагмент файла named.hosts для GMU.

Создание зоны полномочий обычно означает что ее администраторам дают полный контроль над тем как назначать адреса и имена хостов. Так как они обычно управляют одной или более IP сетями или подсетями, одна DNS зона может охватывать несколько IP сетей. Отдел Физики, например, включает подсети 149.76.8.0, 149.76.12.0, и 149.76.14.0.

Как следствие, новые зоны должны быть записаны в in-addr.arpa области:

8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, и 14.76.149.in-addr.arpa.

Иначе, установка нового хоста в Collider лаборатории требовала бы обращения к родительской области чтобы отметится в ее in-addr.arpa файле. Зональная база данных для подсети

12.76.149.in-addr.arpa domain. @ IN SOA { niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 233 360000 3600 3600000 3600 }

2 IN PTR otto.physics.groucho.edu.

4 IN PTR quark.physics.groucho.edu.

5 IN PTR down.physics.groucho.edu.

6 IN PTR strange.physics.groucho.edu.

Фрагмент файла named.rev для подсети

76.149.in-addr.arpa domain. @ IN SOA { vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 360000 3600 3600000 3600 } … ;

subnet 4: Mathematics Dept.

1.4 IN PTR sophus.maths.groucho.edu.

17.4 IN PTR erdos.maths.groucho.edu.

23.4 IN PTR gauss.maths.groucho.edu. … ;

subnet 12:

Physics Dept, separate zone

12 IN NS niels.physics.groucho.edu.

IN NS gauss.maths.groucho.edu. niels.physics.groucho.edu.

IN A 149.76.12.1 gauss.maths.groucho.edu.

IN A 149.76.4.23 …

Фрагмент файла named.rev для сети

Одно важное следствие этого то, что зоны могут создаваться только как наборы IP сетей, и, даже круче, количество нулевых битов в netmasks должно выть кратно 8.

Все подсети в Groucho Marx Университете имеют netmask 255.255.255.0, так что in-addr.arpa зона может быть создана для каждой подсети. Однако, если netmask 255.255.255.128, создание зон для подсети 149.76.12.128 будет невозможно, потому что нет никакой возможности сообщить DNS, что 12.76.149.in-addr.arpa область была раздроблена на две зоны, с именами хостов располагающимися от 1 до 127, и 128 до 255, соответственно.

adminbook.ru

2018: Впервые в истории интернета обновлены ключи шифрования для защиты DNS

11 октября 2018 года состоялась первая в истории интернета и долгожданная замена криптографических ключей, защищающих систему доменных имен (DNS). Этот процесс, как сообщили в [[Internet Corporation for Assigned Names and Numbers ICANN|Корпорации по управлению доменными именами и IP-адресами (ICANN)]], прошла без неполадок.

Криптографические ключи появились в 2010 году по инициативе ICANN. Они применялись в расширении DNS Security (DNSSEC). Изначально в DNS-серверах не была предусмотрена проверка подлинности ответов, чем пользовались злоумышленники: они могли перехватить запрос компьютера пользователя, который пытался установить IP-адрес своего «места назначения», и заменить его на неправильный. Таким образом, пользователь, сам того не замечая, мог подключиться к серверу мошенников. Чтобы избежать этого, в 2010 году было выпущено расширение DNSSEC, которое согласились установить многие крупные интернет-провайдеры.

ICANN планировала менять ключи каждые пять лет. В первый раз смена ключей должна была произойти в 2015 году, но ее откладывали из-за низкого уровня готовности интернет-провайдеров.

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

Никаких сбоев не замечено. Мы уделяли особое внимание ряду участков, где такие сбои могли бы произойти, но никаких проблем не возникло, — заявил представитель ICANN Брэд Уайт (Brad White), добавив, что обновление прошло успешно.

Вице-президент ICANN по исследовательской деятельности Мэтт Ларсон уверен, что такое обновление криптографических ключей станет обычным делом для операторов.[1]

2017: Минкомсвязи поручили создать «независимый интернет» для стран БРИКС

В ноябре 2017 года Совет безопасности России поручил Минкомсвязи совместно с МИД РФ до 1 августа 2018 года проработать вопрос создания собственной системы корневых серверов доменных имен, или DNS, в странах БРИКС (Бразилия, Россия, Индия, Китай и Южная Африка). Иными словами, пишет РБК, Совбез поручил сделать интернет в этих странах не зависимым от международных организаций и воздействия извне.

«В рамках существующего интернета независимости достигнуть нельзя, все равно информация по корневым серверам будет расходиться из одной точки — IANA. Таким образом, создание системы корневых серверов доменных имен, независимой от международных администраторов, эквивалентно созданию альтернативного интернета, независимого от существующего», — цитирует издание представителя «Технического центра Интернета» (ТЦИ), который поддерживает DNS-структуру российского сегмента сети.

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

2014: Передача функций контроля за управлением корневой зоной DNS от правительства США

В декабре 2014 года Межотраслевая рабочая группа ICANN подготовила предложения по передаче функций контроля за управлением корневой зоной DNS от правительства США интернет-сообществу. С инициативой передачи этих функций выступила весной нынешнего года Национальная администрация по телекоммуникациям и информации (NTIA), входящая в состав Министерства торговли США. Межотраслевая рабочая группа из 119 членов представила два варианта передачи функций.

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

Другой вариант предполагает создание новой структуры, надзирающей за деятельностью ICANN по управлению доменной системой и управляемой представителями интернет-сообщества. Авторы предложений подчеркивают, что речь идет о некоммерческой структуре с минимальным числом сотрудников. Таким образом, межотраслевая рабочая группа стремится, очевидно, избежать того, чего опасаются многие наблюдатели – создания «еще одной ICANN для надзора над ICANN».

Структура, условно обозначенная в документе как Contract Co, и возьмет на себя функции NTIA по контролю за управлением корневой зоной DNS. Выработка условий контракта с Contract Co и надзор за соблюдением его исполнения будут возложены на комитет Multistakeholder Review Team, сформированный из числа делегатов всех сообществ, чьи интересы представляет ICANN. Механизмы формирования этого комитета пока не определены и, вероятно, станут предметом жарких дискуссий, поскольку к максимальному представительству в нем будут стремиться самые разные группы с зачастую противоположными интересами.

Также будет сформирован новый постоянный комитет Customer Standing Panel, куда войдут представители регистратур общих и национальных доменов верхнего уровня – как главные «потребители услуг» корневой зоны DNS. Он будет транслировать комитету Multistakeholder Review Team пожелания регистратур, обеспечивая тем самым подотчетность ICANN перед ними. Наконец, предполагается и создание независимого апелляционного комитета, куда могут быть поданы жалобы на любые решения, связанные с управлением корневой зоной DNS, включая, очевидно, и решения о делегировании либо снятии с делегирования доменов.

Предложения опубликованы на сайте ICANN, комментарии к ним принимаются до 22 декабря 2014 года. Окончательное предложение правительству США по передаче функций контроля над управлением корневой зоной DNS должно быть сформулировано летом 2015 года.

Ключевые характеристики DNS

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

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

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.

Дополнительные возможности

  • поддержка динамических обновлений
  • безопасные соединения (DNSsec)
  • поддержка различных типов информации (SRV-записи)

Терминология и принципы работы

Ключевыми понятиями DNS являются:

  • Зона — логический узел в дереве имён. Право администрировать зону может быть передано третьим лицам, за счёт чего обеспечивается распределённость базы данных. При этом персона, передавшая право на управление в своей базе данных хранит информацию только о существовании зоны (но не подзон!), информацию о персоне (организации), управляющей зоной, и адрес серверов, которые отвечают за зону. Вся дальнейшая информация хранится уже на серверах, ответственных за зону.
  • Доме́н — название зоны в системе доменных имён (DNS) Интернета, выделенной какой-либо стране, организации или для иных целей. Структура доменного имени отражает порядок следования зон в иерархическом виде; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости), корневым доменом всей системы является точка (‘.’), следом идут домены первого уровня (географические или тематические), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org домен первого уровня — org, второго wikipedia, третьего ru). На практике точку в конце имени часто опускают, но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).
  • Поддомен (англ. subdomain) — имя подчинённой зоны. (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.
  • DNS-сервер — специализированное ПО для обслуживания DNS. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
  • DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
  • Ответственность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: ответственные (когда сервер заявляет, что сам отвечает за зону) и неответственные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
  • DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным. Нерекурсивный запрос либо возвращает данные о зоне, которая находится в зоне ответственности DNS-сервера (который получил запрос) или возвращает адреса корневых серверов (точнее, адрес любого сервера, который обладает большим объёмом информации о запрошенной зоне, чем отвечающий сервер). В случае рекурсивного запроса сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует. На практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кеше и не устарела, сервер может не запрашивать DNS-серверы). Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и осмысленный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса корневых серверов).
  • Субдомен — дополнительное доменное имя 3-го уровня в основном домене. Может указывать как на документы корневого каталога, так и на любой подкаталог основного сервера. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.

Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов.

Рекурсия

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае имеет место рекурсия: сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является авторитетным для зоны org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является авторитетным для зоны wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

  • браузер отправил известному ему DNS-серверу т. н. рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;
  • DNS-сервер, получив запрос от клиента, последовательно отправлял итеративные запросы, на которые получал от других DNS-серверов ответы, пока не получил авторитетный ответ от сервера, ответственного за запрошенную зону.

В принципе, запрошенный сервер, мог бы передать рекурсивный запрос «вышестоящему» DNS-серверу и дождаться готового ответа.

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

Обратный DNS-запрос

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Записи DNS

Наиболее важные типы DNS-записей:

  • Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес — 192.0.34.164
  • Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес — 2001:7fd::1
  • Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя
  • Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
  • Запись NS (name server) указывает на DNS-сервер для данного домена.
  • Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
  • Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и взаимодействия DNS-серверов.
  • Запись SRV (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber.

Зарезервированные доменные имена

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Интернациональные доменные имена

Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

Программное обеспечение DNS

Серверы имен:

  • BIND (Berkeley Internet Name Domain)
  • djbdns (Daniel J. Bernstein’s DNS)
  • MaraDNS
  • NSD (Name Server Daemon)
  • PowerDNS
  • Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
  • MyDNS

Атаки на DNS-серверы

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

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

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

Информация о домене

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

Регистрация домена

Регистрация домена — процедура получения доменного имени. Заключается в создании записей, указывающих на администратора домена, в базе данных DNS. Порядок регистрации и требования зависят от выбранной доменной зоны. Регистрация домена может быть выполнена как организацией-регистратором, так и частным лицом[2], если это позволяют правила выбранной доменной зоны.

www.tadviser.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector