Сеть умеет доставлять пакеты только по числовому адресу вроде 46.149.71.22. Люди такими адресами не оперируют — они помнят имена. DNS и есть перевод одного в другое: справочная служба, у которой спрашивают «какой адрес у koddo.ru» и получают ответ.
Проверить можно прямо сейчас, одной командой:
$ dig +noall +answer koddo.ru A
koddo.ru. 600 IN A 46.149.71.22Пять полей этой записи: имя, TTL в секундах, класс (IN — Internet), тип записи и значение. Всё остальное — подробности про то, кто эту строку хранит и как её ищут.
Полная дорога от браузера до сервера зоны разобрана отдельно, в статье про то, что происходит, когда вводишь адрес сайта. Здесь — про то, что в конце этой дороги лежит: сами записи, их типы и срок жизни.
Кто вообще хранит эти записи
Записи домена лежат не «в интернете вообще», а на конкретных серверах, и кто эти серверы — записано в самом домене. Цепочка короткая: реестр зоны .ru знает, каким серверам делегирован koddo.ru, а те уже хранят все его записи.
$ dig +noall +answer koddo.ru NS
koddo.ru. 600 IN NS ns2.timeweb.ru.
koddo.ru. 600 IN NS ns4.timeweb.org.
koddo.ru. 600 IN NS ns3.timeweb.org.
koddo.ru. 600 IN NS ns1.timeweb.ru.Порядок строк здесь не значит ничего и меняется от запроса к запросу — следующий вызов той же команды вернул те же четыре сервера в другом порядке. Так DNS размазывает нагрузку: клиент обычно берёт первый в списке.
Делегирование приводит к серверу с ответами
Типы записей
Тип — это ответ на вопрос «что именно спрашивают про это имя». Их больше сотни, но в работе встречаются семь.
| Тип | Что отвечает | Значение выглядит так |
|---|---|---|
A | IPv4-адрес имени | 46.149.71.22 |
AAAA | IPv6-адрес имени | 2a00:1450:400e:807::200e |
CNAME | «это имя — псевдоним другого» | dualstack.python.map.fastly.net. |
NS | какие серверы обслуживают зону | ns1.timeweb.ru. |
MX | куда доставлять почту, с приоритетом | 10 mx1.timeweb.ru. |
TXT | произвольная строка: SPF, DMARC, проверка владения | "v=spf1 include:_spf.timeweb.ru ~all" |
SOA | служебные параметры зоны и её версия | ns1.timeweb.ru. dns.timeweb.ru. 88 … |
A и AAAA: адрес
Самая частая пара. A отдаёт адрес IPv4, AAAA — IPv6. Второй записи у многих доменов просто нет, и это нормально:
$ dig +short koddo.ru A
46.149.71.22
$ dig +short koddo.ru AAAA
← пусто: IPv6 у домена не настроен
$ dig +short google.com AAAA
2a00:1450:400e:807::200eАдрес Google в последней строке у тебя будет другим: крупные сервисы отдают ближайший к спрашивающему узел, и он меняется даже между двумя соседними запросами.
Пустой ответ здесь — не ошибка. Ошибка выглядит иначе, и её видно в статусе: NXDOMAIN означает, что такого имени нет вовсе, а не что нет записи запрошенного типа.
CNAME: псевдоним, который стоит одного лишнего шага
CNAME говорит «спрашивай не про меня, а про вон то имя». Разрешение становится двухшаговым, и в выводе dig это видно целиком:
$ dig +noall +answer www.python.org
www.python.org. 604789 IN CNAME dualstack.python.map.fastly.net.
dualstack.python.map.fastly.net. 49 IN A 151.101.192.223
dualstack.python.map.fastly.net. 49 IN A 151.101.0.223У псевдонима и адреса разные сроки кэширования
Главное ограничение: на вершине зоны CNAME ставить нельзя. У koddo.ru рядом с адресом обязаны существовать NS и SOA, а CNAME по спецификации запрещает соседей у того же имени. Поэтому www.site.ru псевдонимом быть может, а site.ru — нет; хостеры обходят это собственными выдумками вроде ALIAS или ANAME, которые вне их панели не существуют.
MX: куда идёт почта
У MX есть число перед именем — приоритет, и меньшее значит «пробовать первым»:
$ dig +noall +answer koddo.ru MX
koddo.ru. 600 IN MX 20 mx2.timeweb.ru.
koddo.ru. 600 IN MX 10 mx1.timeweb.ru.Обрати внимание: в выводе первым идёт mx2, но письмо уйдёт на mx1. Порядок строк не значит ничего, значение имеет только число — меньшее пробуют первым, а на mx2 отправитель пойдёт, лишь если первый недоступен. Сами числа произвольные: важна их относительная величина.
TXT: строки, на которых держится почта
TXT хранит произвольный текст, и именно поэтому в него сложили половину почтовой инфраструктуры:
$ dig +short koddo.ru TXT
"v=spf1 include:_spf.timeweb.ru ~all"
"google-site-verification=JZudRIDz…"
$ dig +short _dmarc.koddo.ru TXT
"v=DMARC1; p=quarantine; rua=mailto:help@koddo.ru; adkim=s; aspf=s; fo=1; pct=100"Первая строка — SPF: список тех, кому разрешено слать письма от имени домена. Вторая — доказательство владения доменом для Google: сервис просит положить в DNS выданную строку, потому что сделать это может только тот, кто управляет зоной. Третья, в поддомене _dmarc, — DMARC: что делать с письмом, которое проверку не прошло (p=quarantine — в спам).
SOA: версия зоны и одно неочевидное поле
$ dig +noall +answer koddo.ru SOA
koddo.ru. 600 IN SOA ns1.timeweb.ru. dns.timeweb.ru. 88 28800 7200 259200 300Числа по порядку: серийный номер зоны (88 — версия, а не число правок), интервалы обновления, повтора и истечения для вторичных серверов и последнее поле — 300, SOA MINIMUM. TTL отрицательного ответа берут как минимум из TTL самой SOA и SOA MINIMUM: здесь min(600, 300) = 300 секунд. Поэтому «сайта нет» тоже запоминается.
TTL: почему правка не применяется сразу
Второе число в каждой записи — TTL, срок жизни в кэше. Это не константа, а обратный отсчёт: резолвер отдаёт остаток, а не исходное значение.
$ dig +noall +answer koddo.ru A | awk '{print "TTL =", $2}'
TTL = 558
... три секунды спустя ...
TTL = 555Разница между холодным и кэшированным ответом измерима и велика:
$ dig probe-1788138914.koddo.ru A | grep -E 'status:|Query time'
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45534
;; Query time: 181 msec
... тот же запрос повторно ...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7818
;; Query time: 1 msecКэш ускоряет повторный ответ до истечения TTL
NXDOMAIN тоже вернулся за 1 мс. Срок для него — минимум из TTL SOA и поля MINIMUM: в примере 300 секунд.Практическое следствие одно, и оно стоит нервов при каждом переезде: изменив запись, ты не изменил то, что уже роздано. Разные резолверы обновятся в разное время: запрос без старого кэша может увидеть новое значение сразу, а остальные — после истечения своего остатка TTL. Поэтому переезд планируют заранее: за сутки TTL опускают до 60 секунд, переключают запись, ждут, и только потом возвращают обратно.
Как проверить записи самому
dig +short koddo.ru A # только значение, без обвязки
dig +noall +answer koddo.ru MX # ответ целиком, с TTL и типом
dig koddo.ru A # плюс статус, время запроса и кто ответил
dig @8.8.8.8 koddo.ru A # спросить конкретный резолвер, минуя свой
dig +trace koddo.ru A # весь путь от корня, шаг за шагомФлаг @8.8.8.8 — главный инструмент отладки: он показывает, что видит чужой резолвер, а не твой закэшированный. Если запись поменяли и «у меня не работает», сравнивать надо именно эти два ответа.
В Windows та же роль у nslookup: nslookup -type=MX koddo.ru. Он старше и выводит скупее, но для проверки одного значения хватает.
Строка SERVER: внизу вывода dig говорит, кто на самом деле ответил. На типичном Linux там будет 127.0.0.53 — локальный systemd-resolved, то есть ответ пришёл из системного кэша и до сети мог не дойти:
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)Где чаще всего ошибаются
- Правят записи не там, где они живутПанель регистратора и панель хостера — разные места. Действуют те записи, что лежат на серверах из
NS. Первым делом смотриdig +short домен NS, а не список в интерфейсе. - Ждут мгновенного эффектаСтарое значение живёт у всех, кто успел его получить, ровно столько, сколько указано в TTL. Снижай TTL заранее, а не в момент переезда — тогда снижение само разойдётся не сразу.
- Ставят CNAME на вершину зоныРядом с
site.ruобязаны бытьNSиSOA, аCNAMEсоседей не терпит. Для корня — толькоAлибо проприетарный ALIAS у конкретного хостера. - Путают «нет записи» и «нет имени»Пустой вывод
dig +shortсам по себе ничего такого не доказывает: проверь статус полного ответа.NOERRORбез запрошенных данных может означать NODATA, аNXDOMAIN— что имени нет. Первое чинят добавлением записи, второе — проверкой опечатки и делегирования. - Заводят вторую TXT со SPFСтрока
v=spf1у домена должна быть одна. Две — и проверка не проходит ни по одной; новый сервис дописывают черезinclude:в существующую.
Частые вопросы
Чем DNS-сервер отличается от хостинга
DNS-сервер хранит соответствие имени и адреса, хостинг — сам сайт. Купить домен и не поднять сервер значит получить имя, ведущее в никуда; поднять сервер и не настроить DNS — сайт, доступный только по числовому адресу. Часто и то и другое продаёт одна компания, отчего их и путают.
Что значит «DNS-сервер не отвечает»
Что до резолвера не дошёл запрос или от него не пришёл ответ. Проверяется подстановкой чужого резолвера: если dig @8.8.8.8 домен отвечает, а dig домен — нет, дело в настройках сети или в провайдерском сервере, а не в домене.
Сколько ждать после смены записей
Столько, сколько указано в TTL старой записи, плюс запас. При TTL 600 секунд — до десяти минут; при суточном TTL и переезде без подготовки — до суток. Ускорить чужие кэши нельзя, можно только заранее поставить маленький TTL.
Зачем домену несколько NS-записей
Ради живучести. Если единственный сервер имён недоступен, домен исчезает целиком — вместе с сайтом и почтой. Поэтому их держат минимум два, обычно в разных сетях: у koddo.ru четыре, и половина в зоне .org, чтобы отказ одной зоны не унёс сразу все.
Почему сайт открывается, а почта не ходит
Потому что за них отвечают разные записи. A может быть настроена верно, а MX отсутствовать или указывать на старый сервер. Проверяются по отдельности: dig +short домен A и dig +short домен MX.
Где потренироваться
Все команды из статьи работают на любом домене — начни со своего или с python.org, там есть и CNAME, и живой CDN за ним. Что происходит после того, как адрес найден, разобрано в статьях про путь запроса и коды ответов HTTP.