Руководство по выживанию веб-девелопера: основы DNS

Каждый Web-разработчик должен знать основы DNS для понимания, диагностики, исправления и предупреждения неисправностей, — пишет proglib.io в своем переводе статьи «The Web Developer’s Guide to DNS«. Ну, поехали!

DNS

DNS отвечает за превращение имен хостов в понятный машине IP-адрес. Как это выглядит в dig:

[bash]$ dig pets.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> pets.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17431
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pets.com. IN A

;; ANSWER SECTION:
pets.com. 9708 IN A 72.52.10.14

;; Query time: 14 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Apr 08 21:03:43 PDT 2019
;; MSG SIZE rcvd: 53
[/bash]

Перейдем к секции QUESTION и ANSWER: мы указали pets.com и получили в ответ 72.52.10.14 – это работа DNS в действии. Теперь подробнее.

Кусочек модели OSI

Рассмотрим часть модели, с которой Web-девелопер будет иметь дело в течение 95% своего рабочего времени. Для HTTP данный стек выглядит так:

Веб-протоколы

Уровень приложения – самый верхний уровень, на нем обитает HTTP. Он упаковывает содержимое веб-страницы таким образом, чтобы браузеры пользователей смогли все понять. HTTP не описывает, как браузеру подключаться к серверу: с этим поможет Transmission Control Protocol (TCP). Затем идет Internet Protocol (IP), определяющий, сетевую адресацию клиента и сервера, а ниже – канальный уровень (link layer) служащий для общения физического оборудования.

Использование UDP

Зачастую DNS использует только стек TCP/IP, но большинство операций может функционировать на протоколе UDP (User Datagram Protocol).

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

Пример DNS-запроса

Основы DNS: пример DNS-запроса

Теперь рассмотрим непосредственно работу сервиса:

  • вы печатаете com в браузере;
  • браузер просит DNS-resolver отыскать сервер, содержащий com;
  • если резолвер не знает, кто это, он пересылает ваш запрос соседнему DNS-серверу;
  • если “сосед” тоже не знает, он может предоставить адрес другого сервера имен, который поможет, и так до корневого сервера, ответственного за часть доменного пространства «.com«;
  • корневой сервер определяет сервер имен, отвечающий за com, который может предоставить IP-адрес искомого ресурса с помощью А-записи;
  • все резолверы ниже по цепочке кэшируют данный результат для дальнейшего использования.

Таким же образом можно получить из IP-адреса имя хоста. Это возможно при помощи специального домена (in-addr.arpa), PTR-записи и IP с инверсией (пример: 4.4.8.8.in-addr.arpa – это имя хоста публичного DNS-сервера 8.8.4.4). Чтобы это сработало, в авторитетном DNS-сервере делается пометка:

333.222.111.in-addr.arpa IN PTR host1.example.net

Это означает, что за данную зону (сеть 333.222.111.000/24) отвечает отдельный сервер.

Если при запросе не находится PTR-запись, то считается, что IP не имеет обратной DNS-записи.

Немного о зоне

Чтобы «всеобщая» DNS-система могла узнать о вашем сайте/приложении, нужно оповестить эту систему. Для этого существует конфиг доменной зоны pets.com, который выглядит примерно так:

[bash]$TTL 86400 ;1d
$ORIGIN pets.com.
@ IN SOA ns1.pets.com. ns2.pets.com. (
2019050300 ; se = serial number
43200 ; ref = refresh (12h)
900 ; ret = update retry (15m)
1209600 ; ex = expiry (2w)
3600 ; nx = nxdomain ttl (1h)
)
IN NS ns1.pets.com.
IN MX 10 mail.pets.com.
www IN CNAME @
[/bash]

Когда вы редактируете что-то в этом файлике «руками» или с помощью сервиса регистратора, изменяется параметр (se). Это ключевой параметр, т. к. если данное значение не поменять, DNS-сервера, стоящие по цепочке не узнают, что произошла корректировка вашей зоны и будут выдавать устаревшую информацию (особенно весело будет, если это сообщение об ошибке try again later или что-то подобное).

Каждая запись в пространстве DNS содержит параметр TTL (time to live), указывающий, как долго кэш может храниться у клиента, прежде чем понадобится «переспросить». Если TTL явно не задан, вместо него используется значение по умолчанию (86400 сек. или сутки).

Основы DNS или что еще поделать?

Самый лучший вариант обучения — это практика. Если есть желание, можете поднять на виртуалке свой DNS-сервер, а если нет, то вот немного чтива:

Заключение

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]


Оставьте комментарий

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

Прокрутить вверх