Подробный гайд по DNS (примеры, расчёт, обучение)
DNS (Domain Name System): от базовых принципов до записей, безопасности, диагностики и практики администрирования.
Подробный гайд по DNS
1. Что такое DNS и зачем он нужен
DNS (Domain Name System) — это распределённая система, которая преобразует понятные человеку доменные имена, например example.com, в IP-адреса, например 93.184.216.34 или 2606:2800:220:1:248:1893:25c8:1946. Компьютеры и сетевое оборудование оперируют IP-адресами, а людям удобнее использовать имена. DNS выполняет роль «телефонной книги интернета».
Пример:
example.com -> 93.184.216.34
mail.example.com -> 93.184.216.50
Без DNS пришлось бы запоминать IP-адреса сайтов и сервисов вручную.
2. Краткая история: файл hosts
До DNS использовался файл hosts, где вручную прописывались соответствия имён и IP-адресов.
Пример:
93.184.216.34 example.com
192.0.2.10 intranet.local
В современных системах он обычно находится здесь:
- Linux/macOS:
/etc/hosts - Windows:
C:\Windows\System32\drivers\etc\hostsФайлhostsдо сих пор работает и часто имеет приоритет перед DNS. Его используют для локальных переопределений, тестов, блокировок, разработки.
Пример:
127.0.0.1 localhost
127.0.0.1 ads.example.com
192.168.1.50 myserver.home
Но для интернета в целом такой подход не масштабируется. Поэтому появилась DNS.
3. Основные термины
| Термин | Значение |
|---|---|
| Доменное имя | Символьное имя ресурса, например www.example.com |
| Доменная зона | Часть пространства имён, например example.com |
| DNS-запись | Запись, связывающая имя с данными, например IP-адресом |
| DNS-сервер | Сервер, который хранит или запрашивает DNS-данные |
| Резолвер | Клиентская библиотека или сервис, который выполняет DNS-запросы |
| Authoritative DNS | Сервер, который официально отвечает за зону |
| Recursive resolver | Сервер, который выполняет полный поиск ответа от имени клиента |
| TTL | Время жизни записи, сколько её можно кэшировать |
| FQDN | Полное доменное имя, например host.example.com. |
4. Иерархия DNS
DNS имеет древовидную иерархическую структуру.
Пример имени:
www.example.com.
Точка в конце означает полностью квалифицированное доменное имя — FQDN. В обычной записи она часто опускается.
Разбор справа налево:
. корневая зона
com. зона верхнего уровня
example.com. домен второго уровня
www.example.com. поддомен/хост
Уровни:
- Корневая зона —
. - TLD — домены верхнего уровня:
.com,.org,.net,.ru,.io - Домены второго уровня —
example.com,company.ru - Поддомены —
www.example.com,api.example.com,mail.example.com
Пример:
app.prod.example.com
Здесь:
com— TLD;example.com— домен;prod.example.com— поддомен;app.prod.example.com— имя хоста или сервиса.
5. Корневые DNS-серверы
В основе DNS находятся root-серверы.
Их логически 13 идентификаторов:
a.root-servers.net
b.root-servers.net
...
m.root-servers.net
Физически каждый из них представлен множеством серверов по всему миру через anycast. Root-серверы не знают IP всех сайтов. Они знают, какие серверы отвечают за TLD-зоны: .com, .org, .ru, .net и т.д.
6. TLD-серверы
TLD-серверы отвечают за доменные зоны верхнего уровня.
Например:
- для
.com— серверы зоны COM; - для
.ru— серверы зоны RU; - для
.org— серверы зоны ORG. Они знают, какие authoritative-серверы отвечают за конкретный домен.
Пример:
Запрос: example.com
Root: "Не знаю, но спроси у .com"
TLD .com: "Не знаю, но вот NS-серверы example.com"
7. Authoritative DNS-серверы
Authoritative DNS-сервер — это сервер, который официально хранит или обслуживает зону.
Например, для домена example.com могут быть указаны:
ns1.example.com
ns2.example.com
Или внешние DNS-хостинги:
ns1.dnsprovider.com
ns2.dnsprovider.com
Именно authoritative-сервер даёт окончательный ответ по записям зоны, если запрос пришёл к нему напрямую.
8. Рекурсивный DNS-резолвер
Обычный компьютер не ходит сам по всем серверам интернета. Он отправляет запрос рекурсивному резолверу. Рекурсивный резолвер — это DNS-сервер, который выполняет всю работу по поиску ответа от имени клиента.
Примеры публичных рекурсивных резолверов:
| Провайдер | IPv4 | IPv6 |
|---|---|---|
| Cloudflare | 1.1.1.1 |
2606:4700:4700::1111 |
8.8.8.8 |
2001:4860:4860::8888 |
|
| Quad9 | 9.9.9.9 |
2620:fe::fe |
| OpenDNS | 208.67.222.222 |
2620:119:35::35 |
Корпоративные сети часто используют собственные DNS-резолверы:
- Unbound;
- BIND;
- CoreDNS;
- Windows DNS Server;
- dnsmasq;
- systemd-resolved.
9. Как выполняется DNS-запрос
Допустим, пользователь открывает:
https://www.example.com
Упрощённая последовательность:
- Приложение запрашивает имя
www.example.com. - ОС проверяет локальный кэш.
- Если ответа нет, запрос идёт к рекурсивному DNS-серверу.
- Рекурсивный сервер проверяет свой кэш.
- Если ответа нет, он обращается к root-серверу.
- Root-сервер направляет к TLD-серверам
.com. - TLD-сервер направляет к authoritative-серверам
example.com. - Authoritative-сервер возвращает запись, например A или CNAME.
- Рекурсивный сервер сохраняет ответ в кэш согласно TTL.
- Клиент получает IP-адрес.
- Браузер устанавливает TCP/TLS-соединение по полученному адресу.
Схема:
Клиент
|
v
Рекурсивный резолвер
|
v
Root-сервер
|
v
TLD-сервер .com
|
v
Authoritative-сервер example.com
|
v
Ответ: IP-адрес
10. Рекурсивный и итеративный запрос
Рекурсивный запрос
Клиент говорит резолверу:
- Найди мне ответ полностью. Резолвер сам выполняет все необходимые шаги.
Пример:
Клиент -> Recursive resolver:
"Дай IP для www.example.com"
Итеративный запрос
Сервер отвечает:
- Я не знаю, но спроси у этого сервера. Так общаются между собой DNS-серверы.
Пример:
Root -> Resolver:
"Спроси у TLD .com"
TLD -> Resolver:
"Спроси у ns1.example.com"
11. DNS-зоны
DNS-зона — это часть доменного пространства, за которую отвечает конкретный authoritative-сервер.
Например, зона:
example.com
Может содержать записи:
example.com. A 203.0.113.10
www.example.com. A 203.0.113.10
mail.example.com. A 203.0.113.20
example.com. MX 10 mail.example.com.
Зона может быть:
- первичной — master;
- вторичной — slave/secondary;
- stub — хранит только NS-записи;
- forward — перенаправляет запросы;
- reverse — для обратного преобразования IP → имя.
12. Файл зоны в BIND
Классический пример файла зоны:
$TTL 3600
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com. (
2026022201 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ; minimum TTL
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 203.0.113.10
www IN A 203.0.113.10
mail IN A 203.0.113.20
@ IN MX 10 mail.example.com.
ns1 IN A 203.0.113.53
ns2 IN A 203.0.113.54
Где:
@— текущий origin, то естьexample.com.;IN— Internet class;SOA— служебная запись зоны;NS— DNS-серверы зоны;A— IPv4-адрес;MX— почтовый сервер.
13. Основные типы DNS-записей
A-запись
Связывает доменное имя с IPv4-адресом.
example.com. A 203.0.113.10
Запрос:
example.com -> 203.0.113.10
AAAA-запись
Связывает доменное имя с IPv6-адресом.
example.com. AAAA 2001:db8::10
Пример:
example.com -> 2001:db8::10
CNAME-запись
Указывает, что имя является псевдонимом другого имени.
www.example.com. CNAME example.com.
Запрос:
www.example.com -> example.com -> 203.0.113.10
Важно:
- CNAME не может существовать на вершине зоны по стандарту;
- CNAME не должен сосуществовать с другими записями для того же имени;
- лучше использовать CNAME для поддоменов, а не корневого домена.
Неправильно:
www.example.com. CNAME example.com.
www.example.com. A 203.0.113.10
MX-запись
Указывает почтовый сервер для домена.
example.com. MX 10 mail.example.com.
Число — приоритет. Чем меньше, тем выше приоритет.
Пример с несколькими серверами:
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
Сначала почта будет доставляться на mail1.example.com, при недоступности — на mail2.example.com.
Важно:
MX должен указывать на A/AAAA-имя, а не на IP-адрес напрямую.
TXT-запись
Хранит произвольный текст. Часто используется для проверки владения доменом, SPF, DKIM, DMARC, политик.
example.com. TXT "v=spf1 include:_spf.google.com ~all"
Примеры использования:
- SPF;
- DKIM;
- DMARC;
- verification-записи;
- MTA-STS;
- TLSRPT;
- произвольные метки.
NS-запись
Указывает authoritative-серверы зоны.
example.com. NS ns1.example.com.
example.com. NS ns2.example.com.
Для нормальной отказоустойчивости нужно минимум два NS-сервера.
SOA-запись
SOA (Start of Authority) — служебная запись зоны. Содержит параметры репликации и тайминги.
example.com. IN SOA ns1.example.com. admin.example.com. (
2026022201 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ; minimum TTL
)
Поля:
| Поле | Назначение |
|---|---|
| Primary NS | Главный сервер зоны |
| Responsible mailbox | Контакт администратора, @ заменяется на точку |
| Serial | Версия зоны |
| Refresh | Как часто secondary проверяет изменения |
| Retry | Повтор при неудаче |
| Expire | Когда secondary перестаёт отвечать, если master недоступен |
| Minimum TTL | Минимальный TTL для отрицательных ответов |
Serial часто делают в формате:
YYYYMMDDNN
Например:
2026022201
PTR-запись
Используется для обратного DNS: IP → имя.
Пример для IPv4:
10.113.0.203.in-addr.arpa. PTR mail.example.com.
Это соответствует адресу:
203.0.113.10
PTR важен для почты, диагностики, логов, некоторых систем безопасности.
SRV-запись
Указывает сервис, порт и приоритет.
_sip._tcp.example.com. SRV 10 60 5060 sip.example.com.
Формат:
_service._proto.name TTL class SRV priority weight port target
Поля:
- priority;
- weight;
- port;
- target.
Используется для:
- SIP;
- XMPP;
- LDAP;
- Kerberos;
- Minecraft-серверов;
- некоторых корпоративных сервисов.
CAA-запись
Определяет, какие центры сертификации могут выпускать сертификаты для домена.
example.com. CAA 0 issue "letsencrypt.org"
Примеры:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"
DNSKEY, RRSIG, DS
Используются в DNSSEC.
DNSKEY— публичные ключи;RRSIG— подписи записей;DS— делегирование подписанной зоны.
NAPTR
Используется для сложных преобразований URI, часто в телефонии и SIP.
example.com. NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
SPF, DKIM, DMARC через TXT
SPF
example.com. TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all"
DKIM
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
DMARC
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
14. TTL и кэширование
TTL (Time To Live) — время в секундах, в течение которого DNS-запись может храниться в кэше.
Пример:
example.com. A 203.0.113.10 ; TTL 3600
Это означает, что ответ можно кэшировать на 3600 секунд — 1 час.
Если TTL высокий:
- меньше нагрузка на DNS;
- быстрее ответы из кэша;
- но изменения применяются медленнее.
Если TTL низкий:
- изменения распространяются быстрее;
- нагрузка выше;
- больше запросов к authoritative-серверам.
Рекомендации:
- для стабильных записей:
3600,7200,86400; - перед миграцией: временно снизить TTL до
300или60; - после миграции: вернуть нормальный TTL.
Важно понимать:
Изменение DNS не мгновенно. Старые кэши могут хранить прежние значения до истечения TTL.
15. Отрицательное кэширование
Если имя не существует, DNS может вернуть NXDOMAIN. Резолвер может кэшировать отрицательный ответ на время, указанное в SOA, в поле minimum.
Пример:
Запрос: nohost.example.com
Ответ: NXDOMAIN
Резолвер может запомнить: «такого имени нет» на определённое время.
16. DNS-запрос и ответ: структура
DNS-сообщение состоит из:
- Заголовка;
- Секции вопросов;
- Секции ответов;
- Секции авторитетных записей;
- Секции дополнительных записей.
Пример запроса:
Header:
ID
QR=0
OPCODE=QUERY
RD=1
QUESTION:
www.example.com IN A
Пример ответа:
HEADER:
QR=1
AA=0/1
RD=1
RA=1
QUESTION:
www.example.com IN A
ANSWER:
www.example.com 3600 IN A 203.0.113.10
Основные флаги:
| Флаг | Значение |
|---|---|
| QR | Запрос или ответ |
| AA | Authoritative Answer |
| TC | Truncated, ответ не поместился в UDP |
| RD | Recursion Desired |
| RA | Recursion Available |
| AD | Authenticated Data, DNSSEC |
| CD | Checking Disabled |
17. DNS и транспорт: UDP, TCP
Классически DNS использует:
- UDP порт 53 — обычные небольшие запросы;
- TCP порт 53 — большие ответы, передача зон, DNS over TLS.
Если ответ не помещается в UDP-пакет, сервер ставит флаг
TC— truncated, и клиент повторяет запрос по TCP. Современные расширения, например EDNS0, позволяют передавать больше данных по UDP.
18. EDNS0
EDNS0 — расширение DNS, которое позволяет:
- увеличивать размер UDP-сообщений;
- передавать дополнительные параметры;
- использовать DNSSEC;
- улучшать совместимость. Без EDNS0 классический UDP DNS ограничен 512 байтами.
19. DNSSEC
DNSSEC — расширение DNS, которое позволяет проверять подлинность DNS-ответов с помощью цифровых подписей.
DNSSEC защищает от:
- подмены DNS-ответов;
- cache poisoning;
- MITM-атак на DNS, если проверяющая сторона поддерживает валидацию. DNSSEC не шифрует DNS-запросы. Он только подтверждает, что данные пришли из правильной зоны и не изменены.
Основные записи:
DNSKEY;RRSIG;DS;NSEC/NSEC3.
Пример проверки:
dig +dnssec example.com A
Или:
delv example.com A
20. Шифрование DNS: DoT, DoH, DoQ
Классический DNS не шифрует содержимое запросов. Провайдер или наблюдатель может видеть, какие домены запрашиваются. Для повышения конфиденциальности используются:
DNS over TLS — DoT
DNS поверх TLS, обычно порт 853.
Пример:
dns.google
1.1.1.1
DNS over HTTPS — DoH
DNS-запросы передаются через HTTPS, обычно порт 443.
Примеры:
https://dns.google/dns-query
https://cloudflare-dns.com/dns-query
DNS over QUIC — DoQ
DNS поверх QUIC, использует UDP и шифрование на базе TLS 1.3.
Плюсы:
- меньше задержек;
- нет head-of-line blocking, как у TCP;
- шифрование.
21. Сравнение обычного DNS, DoT, DoH, DoQ
| Технология | Транспорт | Порт | Шифрование | Примечание |
|---|---|---|---|---|
| DNS | UDP/TCP | 53 | Нет | Классический DNS |
| DoT | TLS over TCP | 853 | Да | Шифрованный DNS |
| DoH | HTTPS/TCP | 443 | Да | Маскируется под HTTPS |
| DoQ | QUIC/UDP | 853 | Да | Современный вариант |
22. Локальный DNS в операционных системах
Linux
В Linux DNS обычно настраивается через:
/etc/resolv.conf;systemd-resolved;- NetworkManager;
resolvconf;dhclient;netplan.
Пример /etc/resolv.conf:
nameserver 1.1.1.1
nameserver 8.8.8.8
search example.local
options ndots:2
Проверка:
resolvectl status
или:
cat /etc/resolv.conf
Windows
В Windows DNS-клиент настраивается в параметрах сетевого адаптера или через DHCP.
Команды:
ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
nslookup example.com
Resolve-DnsName example.com
macOS
Проверка:
scutil --dns
dscacheutil -flushcache
sudo killall -HUP mDNSResponder
23. Порядок поиска имени
Обычно система проверяет источники в таком порядке:
- Приложение запрашивает имя.
- Локальный кэш ОС.
- Файл
hosts. - DNS-резолвер.
- mDNS/LLMNR в локальной сети, если настроено.
В Linux порядок может задаваться в /etc/nsswitch.conf:
hosts: files dns myhostname
Это означает:
files—/etc/hosts;dns— DNS;myhostname— локальное имя хоста.
24. mDNS и LLMNR
mDNS
mDNS (Multicast DNS) используется для локального разрешения имён вида:
printer.local
Порт:
UDP 5353
Применяется в домашних сетях, Bonjour, Avahi.
LLMNR
LLMNR — Link-Local Multicast Name Resolution, в основном Windows. Используется для локальных имён, если DNS не ответил. В корпоративных сетях LLMNR часто отключают из соображений безопасности, так как он может использоваться в атаках.
25. DNS и DHCP
DHCP может автоматически выдавать клиентам:
- DNS-серверы;
- доменный суффикс;
- параметры регистрации имён.
Пример для Linux-сети:
DHCP server -> client:
DNS: 192.168.1.1
Domain: home.local
В Windows DHCP может взаимодействовать с DNS-сервером для динамической регистрации A/AAAA и PTR-записей.
26. Прямая и обратная DNS-зона
Прямая зона
Преобразует имя в IP:
server.example.com -> 203.0.113.10
Обратная зона
Преобразует IP в имя:
10.113.0.203.in-addr.arpa -> server.example.com
Для IPv4 обратная зона выглядит так:
0.113.203.in-addr.arpa
Для подсети:
203.0.113.0/24
Для IPv6 используется зона:
ip6.arpa
27. DNS-серверы: роли
1. Recursive resolver
Выполняет рекурсивные запросы для клиентов.
Примеры:
- Unbound;
- BIND с
recursion yes; - CoreDNS с плагином forward;
- Windows DNS;
- dnsmasq.
2. Authoritative server
Отвечает за зону.
Примеры:
- BIND;
- NSD;
- Knot DNS;
- PowerDNS;
- CoreDNS;
- Windows DNS для AD-зон.
3. Forwarder
Перенаправляет запросы другому DNS-серверу.
Пример:
Локальный сервер -> корпоративный DNS -> интернет
4. Caching-only server
Не хранит зоны, только кэширует ответы.
28. Популярные DNS-серверы
BIND
Один из самых известных DNS-серверов.
Плюсы:
- мощный;
- гибкий;
- поддерживает DNSSEC, dynamic DNS, views.
Минусы:
- сложная конфигурация;
- исторически много нюансов безопасности.
Unbound
Лёгкий рекурсивный резолвер.
Плюсы:
- быстрый;
- безопасный;
- хорош для recursive resolver.
NSD
Authoritative DNS-сервер.
Плюсы:
- быстрый;
- минималистичный;
- хорошо подходит для authoritative.
PowerDNS
Гибкий сервер с поддержкой SQL-бэкендов, API.
Плюсы:
- удобно автоматизировать;
- можно хранить записи в БД;
- хорошая интеграция.
CoreDNS
Современный DNS-сервер на Go с плагинами.
Плюсы:
- удобен для Kubernetes;
- модульность;
- простая конфигурация через Corefile.
dnsmasq
Лёгкий DNS/DHCP/TFTP-сервер.
Плюсы:
- простой;
- подходит для роутеров и малых сетей.
29. Практика: dig
dig — основной инструмент диагностики DNS.
Базовый запрос
dig example.com
Запрос A-записи
dig example.com A
Запрос AAAA
dig example.com AAAA
Запрос MX
dig example.com MX
Запрос NS
dig example.com NS
Запрос TXT
dig example.com TXT
Запрос SOA
dig example.com SOA
Запрос к конкретному серверу
dig @8.8.8.8 example.com A
Запрос к authoritative-серверу
dig @ns1.example.com example.com A
Короткий ответ
dig +short example.com A
Пример вывода:
93.184.216.34
Только ответ
dig +noall +answer example.com A
Проверка DNSSEC
dig +dnssec example.com A
Трассировка
dig +trace example.com A
Эта команда покажет путь от корневых серверов до authoritative.
Запрос PTR
dig -x 203.0.113.10
Проверка TTL
dig +noall +answer example.com A
Пример:
example.com. 3600 IN A 203.0.113.10
30. Практика: nslookup
nslookup проще, чем dig, но менее детален.
nslookup example.com
Запрос к конкретному серверу:
nslookup example.com 8.8.8.8
Тип записи:
nslookup -type=MX example.com
31. Практика: host
host example.com
host -t MX example.com
host -t NS example.com
host -t TXT example.com
host -t SOA example.com
Обратный запрос:
host 203.0.113.10
32. Практика: resolvectl
Для systemd-resolved:
resolvectl status
resolvectl query example.com
resolvectl dns
resolvectl domain
resolvectl flush-caches
33. Практика: Windows PowerShell
Проверка DNS:
Resolve-DnsName example.com
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Server 8.8.8.8
Очистка кэша:
Clear-DnsClientCache
Просмотр кэша:
Get-DnsClientCache
Диагностика:
Get-DnsClientServerAddress
34. Диагностика DNS-проблем
Симптом: имя не резолвится
Проверьте:
1. Правильность имени:
ping example.com
2. Локальный кэш:
resolvectl flush-caches
или Windows:
Clear-DnsClientCache
3. Файл hosts.
4. DNS-серверы:
cat /etc/resolv.conf
или:
Get-DnsClientServerAddress
5. Доступность DNS:
dig @8.8.8.8 example.com
6. Authoritative-серверы:
dig NS example.com
dig @ns1.example.com example.com A
Симптом: сайт открывается не по тому IP
Возможные причины:
- старый кэш;
- неправильная DNS-запись;
- CDN;
- GeoDNS;
- локальный hosts;
- корпоративный прокси или фильтрация.
Проверка:
dig +short example.com A
dig @1.1.1.1 +short example.com A
dig @8.8.8.8 +short example.com A
dig @ns1.example.com +short example.com A
Если ответы разные, нужно смотреть, где именно отличается запись.
Симптом: почта не ходит
Проверьте:
dig MX example.com
dig A mail.example.com
dig TXT example.com
dig TXT _dmarc.example.com
Также проверьте PTR:
dig -x IP_адрес_почтового_сервера
Симптом: медленный DNS
Проверка времени ответа:
dig example.com
Смотрите поле:
Query time: 123 msec
Сравните разные DNS:
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @9.9.9.9 example.com
35. Пример полной диагностики домена
Комплексная проверка:
domain=example.com
dig +trace $domain A
dig $domain A
dig $domain AAAA
dig $domain NS
dig $domain MX
dig $domain TXT
dig $domain SOA
dig +dnssec $domain A
36. DNS-кэш
DNS-кэш может быть на нескольких уровнях:
- Приложение, например браузер.
- Операционная система.
- Локальный DNS-сервер.
- Рекурсивный резолвер провайдера.
- Промежуточные корпоративные DNS.
Очистка кэша:
Linux systemd-resolved
resolvectl flush-caches
Windows
Clear-DnsClientCache
macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Браузер
У браузеров может быть собственный DNS-кэш.
37. DNS и веб-хостинг
Чтобы сайт работал, обычно нужно:
- Зарегистрировать домен.
- Указать NS-серверы у регистратора.
- Создать DNS-зону.
- Добавить A/AAAA или CNAME-записи.
- Дождаться распространения.
- Настроить TLS-сертификат.
Пример:
example.com. A 203.0.113.10
www.example.com. CNAME example.com.
Если сайт на CDN:
www.example.com. CNAME cdn-provider.net.
38. DNS и почта
Для полноценной почты нужны:
- MX-запись;
- A/AAAA для почтового сервера;
- PTR для IP почтового сервера;
- SPF;
- DKIM;
- DMARC.
Пример:
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20
20.113.0.203.in-addr.arpa. PTR mail.example.com.
example.com. TXT "v=spf1 ip4:203.0.113.20 -all"
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..."
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
39. DNS и Active Directory
В Windows-доменах DNS критически важен.
Active Directory использует DNS для:
- поиска контроллеров домена;
- SRV-записей;
- репликации;
- Kerberos;
- LDAP;
- Global Catalog.
Пример SRV-записей AD:
_ldap._tcp.dc._msdcs.example.com
_kerberos._tcp.dc._msdcs.example.com
_gc._tcp.default-first-site-name._sites.dc._msdcs.example.com
Если DNS в AD работает неправильно, возможны проблемы:
- вход в домен;
- репликация;
- групповые политики;
- поиск контроллеров.
40. DNS в Kubernetes
В Kubernetes обычно используется CoreDNS или ранее kube-dns.
Сервисы получают DNS-имена вида:
service-name.namespace.svc.cluster.local
Пример:
nginx.default.svc.cluster.local
Pod может резолвить:
nslookup nginx.default.svc.cluster.local
Конфигурация CoreDNS обычно хранится в ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
41. Split DNS
Split DNS — это когда одно и то же имя возвращает разные ответы внутри сети и снаружи.
Пример:
Внутри компании:
portal.example.com A 10.0.0.20
Снаружи:
portal.example.com A 203.0.113.20
Это удобно для:
- внутренних сервисов;
- экономии трафика;
- безопасности;
- доступа через внутренний IP.
Реализуется через:
- views в BIND;
- политики в PowerDNS;
- разные зоны во внутреннем DNS;
- CoreDNS-плагины;
- AD DNS.
42. Views в BIND
Пример разделения внутренней и внешней видимости:
view "internal" {
match-clients { 10.0.0.0/8; };
zone "example.com" {
type master;
file "/etc/bind/internal/example.com.zone";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "/etc/bind/external/example.com.zone";
};
};
43. Dynamic DNS
Dynamic DNS позволяет обновлять DNS-записи автоматически.
Например, клиент получает IP по DHCP и регистрирует имя:
laptop.example.local -> 192.168.1.55
Используется в:
- Active Directory;
- DHCP-серверах;
- домашних сервисах;
- IoT. Обновление может выполняться через RFC 2136.
Пример утилиты:
nsupdate
Сессия:
server ns1.example.com
zone example.com
update add host.example.com 300 A 203.0.113.99
send
44. Zone Transfer: AXFR и IXFR
Zone transfer — передача зоны от master к secondary.
AXFR
Полная передача зоны.
IXFR
Инкрементальная передача только изменений.
Проверка AXFR:
dig @ns1.example.com example.com AXFR
Важно:
AXFR должен быть разрешён только доверенным secondary-серверам. Иначе любой может получить список всех записей зоны.
45. Безопасность DNS
Основные угрозы
- DNS spoofing — подмена ответа.
- Cache poisoning — отравление кэша.
- DNS amplification — усиление DDoS.
- Zone transfer leak — утечка зоны.
- DNS tunneling — туннелирование данных через DNS.
- LLMNR/NetBIOS/mDNS-атаки в локальных сетях.
- Регистрация похожих доменов — typosquatting.
- Угон домена — domain hijacking.
46. Защита DNS
1. Используйте несколько NS
Минимум два, лучше больше:
example.com. NS ns1.example.com.
example.com. NS ns2.example.com.
2. Ограничивайте zone transfer
Только для secondary:
allow-transfer { 203.0.113.54; };
3. Включайте DNSSEC
Для защиты целостности данных.
4. Используйте DNS over TLS/HTTPS
Для конфиденциальности клиентских запросов.
5. Ограничивайте рекурсию
Рекурсия должна быть доступна только своим клиентам.
Пример в BIND:
allow-query { 10.0.0.0/8; };
recursion yes;
allow-recursion { 10.0.0.0/8; };
Для публичного authoritative-сервера рекурсию обычно отключают:
recursion no;
6. Обновляйте DNS-ПО
BIND, Unbound, PowerDNS, CoreDNS, Windows DNS получают исправления безопасности.
7. Мониторьте DNS-трафик
Аномалии:
- очень длинные поддомены;
- огромное количество TXT-запросов;
- необычные домены;
- всплески NXDOMAIN;
- подозрительные zone transfer.
8. Используйте CAA
Чтобы ограничить выпуск сертификатов.
example.com. CAA 0 issue "letsencrypt.org"
9. Настраивайте SPF, DKIM, DMARC
Для защиты почты и домена.
10. Отключайте LLMNR/NetBIOS там, где не нужно
Особенно в Windows-сетях.
47. DNS amplification attack
Атакующий отправляет маленький запрос с подделанным IP-источником на открытые DNS-серверы. Ответ может быть значительно больше запроса и уходит жертве.
Пример:
Запрос: ANY example.com
Ответ: много записей
Меры защиты:
- не быть open resolver;
- ограничивать рекурсию;
- использовать response rate limiting;
- отключать или ограничивать ANY;
- применять BCP38/BCP84 — фильтрацию поддельных исходных адресов.
48. DNS tunneling
DNS может использоваться для скрытой передачи данных.
Пример:
data12345.attacker.com
В поддомен кодируются данные. Сервер, контролирующий зону, декодирует их.
Признаки:
- длинные случайные поддомены;
- много TXT/NULL/CNAME-запросов;
- необычные имена;
- высокий объём DNS у хоста.
Защита:
- мониторинг;
- фильтрация;
- ограничение внешних DNS;
- использование только разрешённых DNS в корпоративной сети.
49. DNS и HTTP/HTTPS
DNS не определяет протокол HTTP. Он только возвращает IP-адрес.
Последовательность:
DNS: example.com -> 203.0.113.10
TCP: соединение с 203.0.113.10:443
TLS: проверка сертификата example.com
HTTP: запрос страницы
Важно:
TLS-сертификат проверяется по имени, а не по IP. Поэтому DNS-имя должно совпадать с именем в сертификате или SAN.
50. DNS и CDN
CDN часто используют DNS для маршрутизации пользователей к ближайшему серверу.
Пример:
www.example.com CNAME cdn.example.net.
Далее CDN-провайдер возвращает разные IP в зависимости от:
- географии;
- сети;
- нагрузки;
- anycast.
51. GeoDNS
GeoDNS возвращает разные ответы в зависимости от региона запроса.
Пример:
Европа:
example.com -> 192.0.2.10
Азия:
example.com -> 198.51.100.20
Используется для:
- снижения задержек;
- балансировки;
- compliance;
- локализации.
52. Anycast DNS
Anycast — один IP-адрес анонсируется из множества точек. Запрос приходит к ближайшему серверу.
Пример:
1.1.1.1
8.8.8.8
Преимущества:
- низкая задержка;
- отказоустойчивость;
- защита от DDoS;
- глобальная масштабируемость.
53. DNS round-robin
Простая балансировка через несколько A-записей:
example.com. A 203.0.113.10
example.com. A 203.0.113.11
example.com. A 203.0.113.12
Резолвер может возвращать адреса в разном порядке.
Плюсы:
- просто;
- не требует сложной инфраструктуры.
Минусы:
- не учитывает здоровье серверов;
- не учитывает нагрузку;
- клиенты могут кэшировать один IP;
- нет гибкой маршрутизации. Для продакшена лучше использовать полноценный load balancer или продвинутый DNS-health-check.
54. Wildcard DNS
Запись вида:
*.example.com. A 203.0.113.10
Означает, что любое имя в example.com, если нет более точной записи, вернёт этот IP.
Пример:
app.example.com -> 203.0.113.10
api.example.com -> 203.0.113.10
test.example.com -> 203.0.113.10
Но если есть:
mail.example.com. A 203.0.113.20
То:
mail.example.com -> 203.0.113.20
Wildcard не перекрывает более конкретные записи.
55. CNAME flattening / ALIAS / ANAME
Классический DNS не позволяет CNAME в корне зоны:
example.com. CNAME something.com.
Но многие DNS-провайдеры предлагают псевдо-записи:
- ALIAS;
- ANAME;
- CNAME flattening. Они позволяют корневому домену вести себя похоже на CNAME, но возвращают A/AAAA.
Пример у провайдера:
example.com ALIAS cdn.example.net
56. Примеры конфигураций
dnsmasq: простой локальный DNS
Файл dnsmasq.conf:
listen-address=127.0.0.1,192.168.1.1
no-resolv
server=1.1.1.1
server=8.8.8.8
address=/example.local/192.168.1.50
address=/ads.example.com/0.0.0.0
Записи:
example.local -> 192.168.1.50
ads.example.com -> 0.0.0.0
Unbound: рекурсивный резолвер
Пример unbound.conf:
server:
interface: 127.0.0.1
interface: 192.168.1.1
access-control: 127.0.0.0/8 allow
access-control: 192.168.1.0/24 allow
hide-identity: yes
hide-version: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
cache-min-ttl: 300
cache-max-ttl: 86400
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 8.8.8.8
CoreDNS: простой forward
Corefile:
.:53 {
errors
health
ready
forward . 1.1.1.1 8.8.8.8
cache 30
loop
reload
loadbalance
}
Локальные записи через hosts:
.:53 {
hosts {
192.168.1.50 server.home
192.168.1.51 nas.home
fallthrough
}
forward . 1.1.1.1 8.8.8.8
cache
}
BIND: минимальный authoritative-конфиг
named.conf:
options {
directory "/var/named";
recursion no;
dnssec-validation auto;
allow-query { any; };
};
zone "example.com" {
type master;
file "example.com.zone";
allow-transfer { 203.0.113.54; };
};
BIND: вторичная зона
zone "example.com" {
type slave;
file "example.com.zone";
masters { 203.0.113.53; };
};
57. Типовые DNS-сценарии
Сценарий 1: сайт на одном сервере
example.com. A 203.0.113.10
www.example.com. A 203.0.113.10
или:
example.com. A 203.0.113.10
www.example.com. CNAME example.com.
Сценарий 2: сайт на CDN
example.com. A 203.0.113.10
www.example.com. CNAME cdn.example.net.
Сценарий 3: почта
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20
Сценарий 4: поддомен для приложения
app.example.com. A 203.0.113.30
api.example.com. A 203.0.113.31
Сценарий 5: внутренний сервис
Внутренняя зона:
portal.internal.example.com. A 10.10.0.5
Внешняя зона может не содержать этой записи.
58. Частые ошибки
1. CNAME на apex
Неправильно:
example.com. CNAME example.net.
Правильнее использовать A/AAAA или ALIAS/ANAME у провайдера.
2. CNAME вместе с другими записями
Неправильно:
www.example.com. CNAME example.com.
www.example.com. A 203.0.113.10
3. MX на CNAME
MX должен указывать на A/AAAA-имя.
Нежелательно:
example.com. MX 10 mail.example.net.
Лучше:
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20
Хотя в некоторых случаях MX на имя вне домена допустим, важно, чтобы у этого имени были A/AAAA.
4. Один NS-сервер
Для отказоустойчивости нужно минимум два NS.
5. Неверный serial в SOA
Если serial не увеличен, secondary-серверы могут не обновить зону.
6. Слишком большой TTL перед миграцией
Если TTL 24 часа, изменения могут применяться долго. Перед миграцией лучше снизить TTL заранее.
7. Открытый zone transfer
Если AXFR доступен всем, злоумышленник может получить список поддоменов.
8. Открытая рекурсия
Если сервер отвечает рекурсивно всем из интернета, он может использоваться в DDoS-атаках.
59. DNS-мониторинг
Что стоит мониторить:
- Доступность DNS-серверов.
- Время ответа.
- Корректность записей.
- NS-набор.
- DNSSEC.
- Срок истечения домена.
- Срок истечения TLS-сертификатов.
- Количество запросов.
- NXDOMAIN.
- Подозрительные домены.
Примеры инструментов:
- Prometheus + Blackbox Exporter;
- Zabbix;
- Grafana;
- Nagios/Icinga;
- SmokePing;
- DNSdist;
- dnstap;
- Zeek;
- Suricata.
60. DNS и производительность
Факторы влияния:
- TTL;
- количество CNAME-цепочек;
- географическое расположение DNS;
- anycast;
- размер ответа;
- DNSSEC;
- UDP/TCP fallback;
- сеть между клиентом и резолвером.
Рекомендации:
- избегайте длинных CNAME-цепочек;
- используйте разумные TTL;
- применяйте anycast или распределённые DNS;
- включайте DNSSEC, но тестируйте размер ответов;
- следите за EDNS0 и fragmentation.
61. DNS и браузеры
Современные браузеры могут:
- использовать собственный DNS-кэш;
- использовать DoH;
- prefetch-запросы;
- кэшировать соединения.
Поэтому при диагностике полезно проверять не только браузер, но и систему:
dig example.com
или:
Resolve-DnsName example.com
62. DNS и контейнеры
В Docker по умолчанию контейнеры используют встроенный DNS.
Пример:
docker run --dns 1.1.1.1 alpine nslookup example.com
Вручную указать DNS в Docker:
{
"dns": ["1.1.1.1", "8.8.8.8"]
}
В Kubernetes DNS обычно CoreDNS, а resolv.conf в Pod выглядит примерно так:
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
63. ndots в Kubernetes
Параметр ndots влияет на поиск доменов.
Пример:
options ndots:5
Если имя содержит меньше пяти точек, Kubernetes может сначала пытаться добавить search-суффиксы.
Например, запрос:
example.com
Может превратиться в серию:
example.com.default.svc.cluster.local
example.com.svc.cluster.local
example.com.cluster.local
example.com
Это может увеличивать задержки.
Для внешних имён иногда используют:
ndots:2
или указывают FQDN с точкой:
example.com.
64. Практический чек-лист настройки домена
- Домен зарегистрирован.
- У регистратора указаны корректные NS.
- Зона создана на authoritative-серверах.
- Есть минимум два NS.
- Добавлены A/AAAA-записи.
wwwнастроен через CNAME или A.- MX настроен, если нужна почта.
- PTR настроен для почтового IP.
- SPF добавлен.
- DKIM добавлен.
- DMARC добавлен.
- CAA добавлен при необходимости.
- TTL выбран разумно.
- DNSSEC включён, если возможно.
- Zone transfer ограничен.
- Рекурсия на authoritative-серверах ограничена или отключена.
- Мониторинг настроен.
- Резервные DNS-серверы настроены.
65. Пример минимальной production-зоны
$TTL 3600
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com. (
2026022201
7200
3600
1209600
3600
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 203.0.113.10
www IN CNAME example.com.
@ IN MX 10 mail.example.com.
mail IN A 203.0.113.20
@ IN TXT "v=spf1 ip4:203.0.113.20 -all"
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
selector._domainkey IN TXT "v=DKIM1; k=rsa; p=..."
@ IN CAA 0 issue "letsencrypt.org"
66. Шпаргалка по командам
Проверить A
dig +short example.com A
Проверить AAAA
dig +short example.com AAAA
Проверить MX
dig +short example.com MX
Проверить NS
dig +short example.com NS
Проверить TXT
dig +short example.com TXT
Проверить SOA
dig +short example.com SOA
Проверить PTR
dig +short -x 203.0.113.10
Проверить конкретный DNS
dig @8.8.8.8 example.com A
Проверить authoritative
dig @ns1.example.com example.com A
Трассировка
dig +trace example.com A
DNSSEC
dig +dnssec example.com A
Очистить кэш Windows
Clear-DnsClientCache
Очистить кэш systemd-resolved
resolvectl flush-caches
67. Краткая схема DNS-экосистемы
Пользователь
|
v
Приложение
|
v
ОС / DNS-клиент
|
v
Локальный DNS / Recursive resolver
|
+---> Кэш
|
+---> Root servers
| |
| v
| TLD servers
| |
| v
+---> Authoritative servers
|
v
DNS-записи
Итог
DNS — это фундаментальная распределённая система именования в интернете. Она решает задачу преобразования доменных имён в IP-адреса, обеспечивает работу почты, сервисов, балансировки, CDN, корпоративных сетей, Kubernetes, Active Directory и многих других технологий.
Ключевые вещи, которые важно помнить:
- DNS иерархичен: корень → TLD → домен → поддомен.
- Есть authoritative-серверы и рекурсивные резолверы.
- Записи бывают разные: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA.
- TTL управляет кэшированием.
- DNS-изменения распространяются не мгновенно.
- DNSSEC защищает целостность, DoT/DoH/DoQ — конфиденциальность.
- Безопасность DNS требует ограничения рекурсии, zone transfer, мониторинга и корректных SPF/DKIM/DMARC.
- Для диагностики лучше всего подходят
dig,host,nslookup,resolvectl,Resolve-DnsName.
Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.