Как работает DNS сервер?

Что такое и как работает DNS сервер ?

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

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

Как было раньше, или если бы не DNS сервер…

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

C:\Windows\System32\drivers\etc\hosts

файл hosts

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

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

  • файл для нормальной работы в сети должен был редактироваться: какие-то записи добавлялись, какие-то затирались. И представьте себе, что это нужно было бы проделывать ВРУЧНУЮ
  • прикиньте, каким бы стал этот файл сегодня, когда мы гуляем по сети беспрепятственно, посещая десятки, а то и сотни хостов ежедневно, даже не подозревая, что такие существовали до сей минуты. Hosts файл разросся бы до гигабайт и бесконечно!

Впрочем, идея с заменой цифрового адреса на символьный пришла почти сразу. Так появилась мысль, а затем и техническое решение создать сетевой сервер ИМЁН. И когда в сети появляется DNS Система Доменных Имён, остальным компьютерам в этой сети нужно знать лишь две вещи:

  • цифровой адрес самого сервера DNS
  • человеку-понятный адрес нужного компьютера

Теперь, чтобы узнать истинный IP адрес нужного компьютера-сервера-сайта (а это по-прежнему адрес в виде ХХХ.ХХХ.ХХХ.ХХХ), наш компьютер спрашивает об этом DNS сервер в форме:

как работает dns сервер

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

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

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

Глобальная DNS

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

RFC 1034

RFC 1035

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

структура dns

  • Корневой сервер имён, он же ROOT сервер — представлен символом ТОЧКА «.«.
  • Домены верхнего уровня (Top Level Domens — TLD) — делятся внутри на Общие домены (gTLD) типа .com.net.org.edu и т.п. и Национальные домены (ccTLD) типа .us, .uk, .ru, .fr и т.п.
  • Домены второго уровня (Secondary Level Domain — SLD) — это остальная часть доменов, которые раздаются коммерческими или государственными организациями. Характерный вид: наличие справа от главного имени адреса ещё одной точки:

сайт.msk.ru    сайт.spb.ru  и т.д.

Таким образом, структура DNS выглядит так:

  • Корневой уровень
  • Домены верхнего уровня
  • Домены второго уровня
  • Поддомены
  • Конечные хосты

В состав такой иерархии вводится понятие доменов третьего уровня, чьё место в URL сразу слева от имени второго домена. Так часто именуют поддомены на ресурсах, которые играют роль специального раздела основного сайта.

Теперь вы знаете, какие DNS серверы принимают участие, когда вы обращаетесь к моему блогу:

доменные имена в адресе сайта

Каждая ветка или пункт доменной системы закреплён за ответственной организацией, которая отвечает за его администрирование. Так что привыкайте к следующему понятию в DNS системе: авторитетный источник. Авторитетной мы будем называть именно ту организацию, которая ответственна именно за конкретную часть DNS цепочки или DNS узла.

Структура DNS 

icann Корневые сервера имён, которые главенствуют над другими в иерархии DNS, объединяют в себе работу чуть более десятка организаций «под эгидой» ICANN («Корпорацией по управлению доменными именами и IP-адресами»). Всего существует 13 корневых серверов со специальными адресами. Официально ICANN не является коммерческой организацией, а другие конторы юридически с ICANN не связаны. Такая разобщённая структура была нарочно придумана для того, чтобы система была максимально независима от давления из-вне, хотя в числе авторитетных организаций есть те, которые работают напрямую с министерством обороны США. Так что «эгида» очень условна. Самой ICANN принадлежит один из таких серверов, и она отвечает за распределение адресов в зоне gTLD. У ICANN есть право делегирования полномочий другим организациям, которые авторизуют отдельные узлы цепочек DNS на основании подписанных с ICANN договоров.

А что такое WWW в начале адреса?

Традиционное в прошлом WWW слева от адреса — не более, чем часть ИМЕНИ ХОСТ-КОМПЬЮТЕРА, к которому вы собираетесь обратиться. Строенная W используется сайтами как дань традиции, никакой ресурс более не обязан упоминать в своём названии заветные некогда WWW. Так что блоги

computer76.ru

и

www.computer76.ru

могут оказаться разными ресурсами, а я свой мог бы, к примеру, легко назвать:

zyx.computer76.ru

При обработке двух первых из примера запросов DNS, скорее всего, сработает безошибочно, направив куда нужно. Однако применение www слева от адреса может дать некоторые преимущества: это может быть дополнительный субдомен в числе остальных для расширения функционала сайта, но с каноническим видом URL. С точки зрения развития или популяризации ресурса разговоров по поводу WWW ведётся немало, однако факт есть факт: специально настроенный ресурс, доступный (как администрации сайта необходимо и выгодно) с WWW и без WWW — часто либо пустая трата сил, либо требующая вложений операция, которая сама по себе «просто так» смысла не имеет.

Набираем адрес в строке или DNS сервер в работе

Чтобы там не заявляли, но основным сервером, который будет направлять вас при поиске нужного ресурса (где бы он не находился), будет один из тринадцати корневых забугорных серверов. Любой из вновь подключаемых серверов верхнего уровня ПО УМОЛЧАНИЮ знает IP адреса каждого из них, и дополнительного сервера ему не требуется. И теперь цепочка

поиск — запрос — ответ

выглядит так (напрягайте память — все аббревиатуры и понятия из текста выше сейчас понадобятся):

  • набираем в браузере нужный адрес (или щёлкаем по ссылке — без разницы)
  • операционная система, получившая сигнал от браузера на выход в сеть, быстренько заглядывает в /etc/hosts файл за дополнительными правилами или разрешениями, а затем в файл /etc/resolv.conf за IP адресом закреплённого за этим компьютером адресом DNS
  • DNS сервер, получивший запрос, шерстит свою базу в поисках адреса. Если находит, возвращает пользователю в браузер (часто на этом цепочка и заканчивает свой срок жизни). Если нет, он звонит корневому серверу
  • корневой сервер передаёт запрос на подходящий TLD DNS-сервер «.XXX» в форме:

«Тут один DNS ищет сайт.xxx: найдёшь — вернёшь ответ сам»

Все TLD сервера, в свою очередь, знают IP адреса всех SLD серверов. Так, если француз искал блог computer76.ru, то корневой сервер делегирует поиск другим авторизованным серверам, которые контролируют работу зоны .RU. Продолжаем пример с французом.

  • цепочку запроса подхватывает один из TLD RU-зоны серверов, который отвечает за работу моего домена (доменного имени) — computer76.ru. Сайт обнаружился.
  • теперь TLD сервер для зоны .RU выдаёт французу ссылку на адрес того DNS сервера, который отвечает за адрес найденного сайта (за домен)
  • DNS сервер для computer76.ru выдаёт клиенту готовый IP адрес блога. Цепочка замкнулась, француз — на сайте.

А вот как это выглядит на практике. И, на манер француза, ищущего русский сайт, постараюсь обнаружить ресурс, о котором его DNS ничего не знает. Для примера я возьму один из своих сайтов-сателлитов, который находится на поддомене от UCOZ с бесплатной «парковкой»:

zdesnetproblem.ucoz.ru

Loading root server list (static data):
-> a.root-servers.net (198.41.0.4)
-> b.root-servers.net (192.228.79.201)
-> c.root-servers.net (192.33.4.12)
-> d.root-servers.net (128.8.10.90)
-> e.root-servers.net (192.203.230.10)
-> f.root-servers.net (192.5.5.241)
-> g.root-servers.net (192.112.36.4)
-> h.root-servers.net (128.63.2.53)
-> i.root-servers.net (192.36.148.17)
-> j.root-servers.net (192.58.128.30)
-> k.root-servers.net (193.0.14.129)
-> l.root-servers.net (199.7.83.42)
-> m.root-servers.net (202.12.27.33)

Sending request to «a.root-servers.net» (198.41.0.4)

Received referral response — DNS servers for «ru»:
-> a.dns.ripn.net (193.232.128.6)
-> e.dns.ripn.net (193.232.142.17)
-> f.dns.ripn.net (193.232.156.17)
-> d.dns.ripn.net (194.190.124.17)
-> b.dns.ripn.net (194.85.252.62)

Sending request to «f.dns.ripn.net» (193.232.156.17)

Received referral response — DNS servers for «ucoz.ru»:
-> ns3.ucoz.ru (190.115.19.142)
-> ns1.ucoz.ru (195.216.243.104)
-> ns2.ucoz.ru (213.174.157.200)

Sending request to «ns3.ucoz.ru» (190.115.19.142)

Received authoritative (AA) response:
-> Answer: A-record for zdesnetproblem.ucoz.ru = 195.216.243.23
-> Authority: NS-record for ucoz.ru = ns2.ucoz.ru
-> Authority: NS-record for ucoz.ru = ns3.ucoz.ru
-> Authority: NS-record for ucoz.ru = ns1.ucoz.ru
-> Additional: A-record for ns1.ucoz.ru = 195.216.243.104
-> Additional: A-record for ns2.ucoz.ru = 213.174.157.200
-> Additional: A-record for ns3.ucoz.ru = 190.115.19.142

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

Успехов.

Запись опубликована в рубрике Чтобы знать. Добавьте в закладки постоянную ссылку.

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

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

три × 5 =