Женщина, которой звонили, чтобы добавить компьютер в интернет
1982 год. Менло-Парк, Калифорния. В офис Стэнфордского исследовательского института снова звонят.
Элизабет Фейнлер — коллеги звали её Джейк — берёт трубку. Очередной системный администратор из очередного университета хочет добавить новый компьютер в ARPANET. Это значит: внести запись в файл HOSTS.TXT.
HOSTS.TXT — единственный список всех компьютеров в сети. Имя машины, её числовой адрес, контакты ответственного. Один файл. Одна команда. Один телефон.
К 1982 году в ARPANET было несколько сотен машин. Файл обновлялся несколько раз в неделю. Его скачивали вручную, по команде ftp, сотни раз в день. Стоило выйти новой версии — часть машин ещё работала со старой. Имена задваивались. Адреса конфликтовали. Администраторы ругались.
Фейнлер понимала: так больше нельзя. Интернет перерос записную книжку.
В ноябре 1983 года инженер Пол Мокапетрис из Университета Южной Калифорнии опубликовал два технических документа — RFC 882 и RFC 883. Он предложил систему, которая делала бы то, что делал файл Фейнлер — только автоматически, распределённо и для любого количества имён.
Так появился DNS. Система доменных имён работает до сих пор — и ни разу принципиально не менялась.
Что такое DNS
DNS расшифровывается как Domain Name System — система доменных имён.
Её задача: переводить понятные людям имена сайтов (например, google.com) в числовые IP-адреса, которые используют компьютеры (например, 142.250.185.78). Браузеры, почтовые клиенты, приложения — все они работают с IP-адресами. Но помнить «142.250.185.78» вместо «google.com» никто не хочет. DNS берёт это на себя.
Сравнение с телефонной книгой точное, но неполное. Телефонная книга — плоский список. DNS — дерево. Иерархическая распределённая система, где за разные уровни отвечают разные серверы в разных странах. Именно это позволяет ей работать с миллиардами имён — без единого файла и без единого телефона.
Путь одного запроса
Вы вводите в браузере pwnrie.beget.tech/ и нажимаете Enter. Вот что происходит за сотню миллисекунд.
Сначала браузер проверяет собственную память — вдруг адрес уже известен с прошлого раза. Нашёл — подключается сразу.
Не нашёл — спрашивает у операционной системы. У неё тоже есть кэш DNS. Плюс на каждом компьютере есть файл под названием hosts — небольшой локальный список имён и адресов, который можно редактировать вручную. Его изобрела ещё Фейнлер; он до сих пор существует в Windows, Mac и Linux, просто о нём мало кто знает.
Если и ОС не знает — запрос уходит к DNS-серверу. Обычно это сервер провайдера, назначенный автоматически при подключении. Или тот, что вы выбрали вручную — например, 8.8.8.8 от Google. Этот сервер называют рекурсивным резолвером: он сам пойдёт искать ответ, если не знает его.
Резолвер спрашивает у корневого сервера DNS. Корневой не знает конкретного адреса pwnrie.beget.tech/ — но знает, кто отвечает за зону .ru, и отправляет резолвер туда.
Сервер зоны .ru — его называют TLD-сервером, от Top Level Domain — знает, какой сервер обслуживает домен pwnrie.beget.tech/, и даёт его адрес.
Авторитетный сервер — последняя остановка. Здесь хранятся настоящие записи домена: точный IP-адрес сайта. Он отвечает резолверу.
Резолвер получает IP, запоминает ответ на какое-то время и возвращает браузеру. Браузер подключается к серверу. Страница открывается.
Тринадцать имён, на которых держится интернет
Корневых серверов DNS — тринадцать. Точнее: тринадцать имён. От a.root-servers.net до m.root-servers.net.
Это не тринадцать машин. За каждым именем стоят сотни физических серверов, рассредоточенных по всему миру. Технология anycast устроена так, что запрос автоматически идёт к ближайшей копии — не обязательно в США, а может в Москву или Франкфурт.
Корневые серверы обслуживают разные организации: ICANN, Verisign, NASA, армия США, RIPE NCC и другие. Намеренно разные — чтобы не было единой точки отказа. Если один оператор пропадёт, остальные продолжат работу.
Что важно понимать: корневые серверы не знают адресов конкретных сайтов. Они только знают, к кому идти дальше. Как диспетчер в аэропорту: сам не летит, но знает, кто знает маршрут.
Что хранится в DNS: типы записей
DNS — это не просто таблица «имя → адрес». Это база данных с несколькими типами записей.
Запись A — основная. Связывает имя домена с IPv4-адресом. Именно её запрашивает браузер.
Запись AAAA — то же самое, но для IPv6. Если сайт поддерживает оба протокола, оба типа записи существуют одновременно.
Запись CNAME — псевдоним. Например, www.newscroll.ru — это CNAME, который указывает на pwnrie.beget.tech/. Позволяет не дублировать IP в каждой записи.
Запись MX — почтовый сервер домена. Когда кто-то отправляет письмо на адрес с доменом, почтовый клиент сначала спрашивает DNS: «Куда доставить?» MX-запись отвечает.
Запись TXT — текстовая. Используется для подтверждения владения доменом и для настроек защиты почты. Например, Google просит добавить строку в TXT, чтобы верифицировать сайт в Search Console.
Почему изменения в DNS распространяются небыстро
У каждой DNS-записи есть TTL — Time To Live, время жизни в кэше. Оно указывает, сколько секунд другие серверы могут хранить запись, прежде чем запросить актуальную версию.
TTL = 3600 означает: кэшировать один час. TTL = 86400 — сутки.
Вот почему, когда владелец сайта меняет хостинг, изменения видны не сразу. Серверы по всему миру держат в кэше старый адрес — пока не истечёт TTL. Это называют «распространением DNS», и оно занимает от нескольких минут до 48 часов.
Если разработчик говорит «подождите, DNS ещё не обновился» — это именно об этом.
Зачем менять DNS-сервер
При подключении к интернету провайдер автоматически назначает свой DNS-сервер. Большинство пользователей об этом не думают — всё работает.
Но менять DNS-сервер имеет смысл по нескольким причинам.
Скорость. Провайдерские DNS бывают медленными. Публичные серверы — Google 8.8.8.8 или Cloudflare 1.1.1.1 — чаще отвечают быстрее, потому что у них больше инфраструктуры и лучше кэширование. Разница в десятки миллисекунд, но при большом количестве запросов это ощутимо.
Приватность. Провайдер видит все DNS-запросы: какие сайты вы запрашиваете и когда. Это не содержимое страниц — но список адресов у него есть. Cloudflare 1.1.1.1 декларирует, что не хранит пользовательские запросы дольше 24 часов и не передаёт их третьим лицам.
Фильтрация. Некоторые DNS-серверы блокируют рекламу и вредоносные сайты прямо на уровне запроса. AdGuard DNS и NextDNS работают именно так — браузер не получает адрес рекламного трекера и просто не загружает его.
Доступ к сервисам. Об этом — отдельно.
Популярные публичные DNS-серверы:
- Google: 8.8.8.8 и 8.8.4.4
- Cloudflare: 1.1.1.1 и 1.0.0.1
- Яндекс: 77.88.8.8 и 77.88.8.1
- AdGuard: 94.140.14.14 и 94.140.15.15
DNS и доступ к сервисам
Часть сайтов в России недоступна — либо заблокирована Роскомнадзором, либо сама компания закрыла доступ с российских IP.
Блокировки работают по-разному. Одни — на уровне IP: пакеты не доходят до сервера. Другие — на уровне DNS: провайдерский сервер возвращает неправильный адрес или просто молчит. Смена DNS-сервера помогает только во втором случае.
Есть и более сложные ситуации. ChatGPT, например, не заблокирован Роскомнадзором — OpenAI самостоятельно закрыл доступ с российских IP-адресов. Это значит: DNS правильно переведёт имя в адрес, но сервер OpenAI всё равно откажет вашему запросу — из-за IP.
Для таких случаев существуют специализированные DNS-сервисы. Их называют Smart DNS: они не только переводят имена в адреса, но и маршрутизируют часть трафика через собственные серверы с нероссийскими адресами.
Например сервис Comss.one DNS работает именно так.
DNS over HTTPS: когда запросы шифруются
Классический DNS работает открыто: запросы передаются без шифрования. Провайдер видит, что вы запрашивали google.com или youtube.com — даже если сам сайт загружается по защищённому HTTPS.
DNS over HTTPS (DoH) — стандарт 2018 года. Он упаковывает DNS-запросы в обычный зашифрованный HTTPS-трафик. Провайдер видит соединение, но не видит, что именно вы запрашиваете.
DoH встроен во все современные браузеры: Chrome, Firefox, Edge, Safari, Яндекс.Браузер, Opera. Включается в настройках безопасности — там же, где можно указать адрес DNS-сервера.
DNS over TLS (DoT) — похожий механизм, но для всего устройства сразу. Android поддерживает его через функцию «Частный DNS» в настройках сети. Там достаточно ввести имя сервера, например dns.comss.one, — и все приложения на телефоне будут использовать зашифрованный DNS, не только браузер.
Для обычного пользователя разница между DoH и DoT небольшая: оба шифруют запросы. DoH удобнее настраивать в браузере, DoT — на уровне всего устройства или роутера.