> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/ru/concepts/how-dns-works.md).
# Как работает DNS
Вы вводите `example.com` и появляется страница. Но компьютеры направляют данные по номеру, а не по имени. Кто выполняет перевод, и можно ли доверять ответу?
Этим переводом занимается Система доменных имён, или DNS. Это одна из старейших и самых фундаментальных частей интернета, и почти всё, что вы делаете онлайн, начинается с DNS-запроса.
## Сравнение со справочником
Представьте печатный телефонный справочник. Вы знаете имя человека; вам нужен его номер. Вы ищете имя, находите номер и звоните.
DNS делает то же самое для интернета. Вы знаете `example.com`; вашему компьютеру нужен `93.184.215.14`. DNS — это шаг поиска, и он происходит до установления любого соединения с сайтом.
Разница в том, что этот телефонный справочник слишком велик для одной книги. Ни одна отдельная машина не хранит все имена в интернете. Поэтому система разбита на уровни, и поиск проходит по ним вниз.
## Кто отвечает на вопрос
В поиске участвуют четыре типа участников.
* **Кэши на вашем устройстве.** Ваш браузер хранит недавние ответы, как и ваша операционная система. Если ответ уже есть там, запрос вообще не покидает ваше устройство.
* **Рекурсивный резолвер.** Это помощник, который делает всю работу за вас. Ваше устройство задаёт ему один вопрос и ожидает один ответ. Обычно его обслуживает ваш интернет-провайдер, но это может быть и публичный сервис, или то, что вы запускаете сами.
* **Корневые серверы и серверы TLD.** Они не знают окончательного ответа. Они знают, кого спрашивать дальше. Корневые серверы знают, кто обслуживает `.com`, `.org`, `.de` и все остальные домены верхнего уровня. `.com` Серверы знают, кто обслуживает каждое `.com` имя.
* **Авторитативный сервер.** Тот, который действительно хранит запись домена, опубликованную тем, кто им управляет.
Вот вся цепочка для имени, которого ваш резолвер ещё не видел:
```mermaid
sequenceDiagram
participant B as Ваш браузер
participant R as Рекурсивный резолвер
participant Ro as Корневой сервер
participant T as серверы .com
participant A as example.com
авторитативный сервер
B->>R: Где находится example.com?
R->>Ro: Где находится example.com?
Ro-->>R: Спроси серверы .com
R->>T: Где находится example.com?
T-->>R: Спроси собственные серверы example.com
R->>A: Где находится example.com?
A-->>R: 93.184.215.14
R-->>B: 93.184.215.14
```
Только теперь ваш браузер открывает соединение с сайтом.
Весь обмен обычно завершается гораздо меньше чем за секунду, и чаще всего он намного короче, чем показывает схема, — благодаря кэшированию.
## Кэширование и TTL
Каждый раз проходить всю цепочку было бы расточительно. Поэтому каждый ответ приходит со сроком действия, который называется **TTL** — временем жизни, измеряемым в секундах.
Резолвер, получивший ответ с TTL 300, будет использовать этот ответ следующие пять минут, не спрашивая снова. Ваша операционная система и браузер делают то же самое. Популярные имена кэшируются почти везде, поэтому большинство поисков ощущаются мгновенными.
TTL — это также причина, почему изменения домена не происходят мгновенно. Когда сайт переезжает на новый адрес, старый ответ продолжает выдаваться из кэшей, пока не истечёт срок его действия. Вот что на самом деле означает «распространение DNS»: ничего не распространяется, старые ответы просто истекают в разное время в разных местах.
Это также объясняет распространённую путаницу: после изменения настроек DNS ваше устройство может ещё какое-то время использовать старые ответы. Очистка кэша или просто ожидание решают проблему.
## Кто обычно является вашим резолвером
Если вы ничего не меняли, вашим рекурсивным резолвером является **ваш интернет-провайдер**. Ваш маршрутизатор автоматически получает его адрес при установлении соединения и передаёт его каждому устройству в вашем доме.
Это удобно и обычно быстро, потому что резолвер находится близко к вам. Это также означает, что ваш провайдер видит каждое доменное имя, которое вы ищете, по порядку, с отметками времени — даже для сайтов, которые вы посещаете по HTTPS, потому что поиск происходит до начала зашифрованного соединения.
Альтернативы — это публичные резолверы, запущенные другими операторами, или резолвер, который вы запускаете сами. Смена резолвера меняет *кто* видит ваши запросы. Это не делает их невидимыми.
## Зашифрованный DNS: DoH и DoT
Традиционный DNS передаётся открытым текстом. Любой на пути — локальная сеть, провайдер — может читать запросы и, в принципе, изменять ответы. Два стандарта решают проблему чтения, оборачивая DNS в шифрование: **DNS over HTTPS** (DoH), который делает запросы похожими на обычный веб-трафик, и **DNS over TLS** (DoT), который использует выделенный зашифрованный канал. Большинство современных браузеров и операционных систем поддерживают как минимум один из них, иногда по умолчанию. Оба защищают ваши запросы от наблюдателей между вами и вашим резолвером и оба сильно затрудняют подмену — но ни один не скрывает ничего от самого резолвера, который по-прежнему видит каждый ваш вопрос. Зашифрованный DNS — это вопрос того, *кто* кто может наблюдать, а не может ли кто-нибудь вообще.
## Где всё идёт не так
DNS — это цепочка доверия, и каждый её элемент может дать сбой или подвергнуться вмешательству.
* **Перехват.** Что-то на пути отвечает вместо выбранного вами резолвера. Сеть отеля, перенаправляющая вас на страницу входа, — безобидный вариант. Сеть, тихо перенаправляющая все запросы на свой собственный резолвер, уже менее безобидна — ваша тщательно выбранная настройка резолвера просто игнорируется.
* **Отравление.** Возвращаемый ответ намеренно неверен: он направляет вас на блокирующую страницу, несуществующий адрес или совсем другой сервер. Это распространённый механизм цензуры, потому что он дешёвый и работает сразу на всех устройствах.
* **Разные ответы.** Одно и то же имя законно возвращает разные адреса в зависимости от того, кто спрашивает. Крупные сервисы делают это намеренно, чтобы направить вас на ближайший сервер. Поэтому расхождение между двумя резолверами само по себе ещё не является признаком подмены — но крайне неправдоподобный ответ, например когда иностранный сайт внезапно разрешается в локальный адрес, обычно уже является.
* **Утечки.** Вы подключаетесь к VPN, но ваши DNS-запросы всё равно идут к резолверу вашего провайдера вне туннеля. Трафик защищён; список имён, которые вы искали, — нет. См. [Утечка ли мой реальный IP?](/knowledge-base/ru/diagnose/am-i-leaking-my-real-ip.md).
* **Обычные сбои.** Если ваш резолвер перестаёт отвечать, всё выглядит сломанным, хотя с вашим соединением всё в порядке. «Интернет не работает» часто означает «DNS не работает».
## Распространённые заблуждения
**«HTTPS защищает мои DNS-запросы.»** Это не так. HTTPS начинается *после* того как поиск завершён. Если вы не используете зашифрованный DNS, имена, которые вы посещаете, передаются открыто.
**«Смена DNS ускоряет просмотр веб-страниц.»** Иногда — незначительно, потому что более близкий или лучше закэшированный резолвер отвечает быстрее. Но DNS — лишь малая часть времени загрузки страницы, и резолвер, находящийся далеко географически, может даже ухудшить ситуацию, отправив вас к далёкой копии сайта.
**«Другой ответ означает, что кто-то атакует меня.»** Не обязательно. Крупные сайты возвращают разные адреса по замыслу. Ищите неправдоподобные ответы, а не просто другие.
**«Приватный просмотр скрывает мои запросы.»** Он очищает локальную историю. Запросы по-прежнему идут к тому же резолверу.
{% hint style="info" %}
**Посмотрите сами в MyIP**
[DNS-резолвер](/knowledge-base/ru/lookup-privacy/dns-resolver.md) Запрашивает один и тот же домен одновременно у набора известных резолверов по всему миру и кладёт ответы рядом. Если ответ из одного региона совсем не похож на остальные, вы видите вмешательство, а не обычную балансировку нагрузки.
Если вы подозреваете, что кто-то переписывает ваши ответы, [Мой DNS перехвачен или подменён?](/knowledge-base/ru/diagnose/is-my-dns-hijacked.md) проходит проверки по порядку.
{% endhint %}
## Связанные понятия
* [Что такое ASN?](/knowledge-base/ru/concepts/what-is-an-asn.md) — сети, по которым проходят ваши запросы
* [GeoIP: как работает геолокация IP](/knowledge-base/ru/concepts/geoip-explained.md) — почему вам выбирают ближайшие серверы
* [Объяснение браузерного фингерпринтинга](/knowledge-base/ru/concepts/browser-fingerprinting.md) — ещё один способ распознавать вас без cookies
* [Тест на утечку DNS](/knowledge-base/ru/connection-tools/dns-leak-test.md) — проверьте, какой резолвер вы действительно используете
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ipcheck.ing/knowledge-base/ru/concepts/how-dns-works.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.