04
Май
2019

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

Каждый Web-разработчик должен знать основы DNS для понимания, диагностики, исправления и предупреждения неисправностей. Ну, поехали! DNS отвечает за превращение имен хостов в понятный машине IP-адрес. Как это выглядит в dig:
$ 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
Перейдем к секции 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 Теперь рассмотрим непосредственно работу сервиса:
  • вы печатаете 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, который выглядит примерно так:
$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   @
Когда вы редактируете что-то в этом файлике «руками» или с помощью сервиса регистратора, изменяется параметр (se). Это ключевой параметр, т. к. если данное значение не поменять, DNS-сервера, стоящие по цепочке не узнают, что произошла корректировка вашей зоны и будут выдавать устаревшую информацию (особенно весело будет, если это сообщение об ошибке try again later или что-то подобное). Каждая запись в пространстве DNS содержит параметр TTL (time to live), указывающий, как долго кэш может храниться у клиента, прежде чем понадобится «переспросить». Если TTL явно не задан, вместо него используется значение по умолчанию (86400 сек. или сутки).

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

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

Заключение

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

Хотите что-то добавить? Будем рады почитать 🙂

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

Тебе может это понравится...