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