Подробный гайд по DNS (примеры, расчёт, обучение)

Исчерпывающий гайд по DNS: принципы работы, иерархия, типы записей, настройка серверов, безопасность, DNSSEC и диагностика сетей утилитами dig.

2026.08.08                  


Подробный гайд по DNS (примеры, расчёт, обучение)Подробный гайд по 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. поддомен/хост

Уровни:

  1. Корневая зона.
  2. TLD — домены верхнего уровня: .com, .org, .net, .ru, .io
  3. Домены второго уровняexample.com, company.ru
  4. Поддомены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
Google 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

Упрощённая последовательность:

  1. Приложение запрашивает имя www.example.com.
  2. ОС проверяет локальный кэш.
  3. Если ответа нет, запрос идёт к рекурсивному DNS-серверу.
  4. Рекурсивный сервер проверяет свой кэш.
  5. Если ответа нет, он обращается к root-серверу.
  6. Root-сервер направляет к TLD-серверам .com.
  7. TLD-сервер направляет к authoritative-серверам example.com.
  8. Authoritative-сервер возвращает запись, например A или CNAME.
  9. Рекурсивный сервер сохраняет ответ в кэш согласно TTL.
  10. Клиент получает IP-адрес.
  11. Браузер устанавливает 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-сообщение состоит из:

  1. Заголовка;
  2. Секции вопросов;
  3. Секции ответов;
  4. Секции авторитетных записей;
  5. Секции дополнительных записей.

Пример запроса:

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. Порядок поиска имени

Обычно система проверяет источники в таком порядке:

  1. Приложение запрашивает имя.
  2. Локальный кэш ОС.
  3. Файл hosts.
  4. DNS-резолвер.
  5. mDNS/LLMNR в локальной сети, если настроено.

В Linux порядок может задаваться в /etc/nsswitch.conf:

hosts: files dns myhostname

Это означает:

  1. files/etc/hosts;
  2. dns — DNS;
  3. 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-кэш может быть на нескольких уровнях:

  1. Приложение, например браузер.
  2. Операционная система.
  3. Локальный DNS-сервер.
  4. Рекурсивный резолвер провайдера.
  5. Промежуточные корпоративные DNS.

Очистка кэша:

Linux systemd-resolved

resolvectl flush-caches

Windows

Clear-DnsClientCache

macOS

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Браузер

У браузеров может быть собственный DNS-кэш.


37. DNS и веб-хостинг

Чтобы сайт работал, обычно нужно:

  1. Зарегистрировать домен.
  2. Указать NS-серверы у регистратора.
  3. Создать DNS-зону.
  4. Добавить A/AAAA или CNAME-записи.
  5. Дождаться распространения.
  6. Настроить TLS-сертификат.

Пример:

example.com.        A     203.0.113.10
www.example.com.    CNAME example.com.

Если сайт на CDN:

www.example.com. CNAME cdn-provider.net.

38. DNS и почта

Для полноценной почты нужны:

  1. MX-запись;
  2. A/AAAA для почтового сервера;
  3. PTR для IP почтового сервера;
  4. SPF;
  5. DKIM;
  6. 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

Основные угрозы

  1. DNS spoofing — подмена ответа.
  2. Cache poisoning — отравление кэша.
  3. DNS amplification — усиление DDoS.
  4. Zone transfer leak — утечка зоны.
  5. DNS tunneling — туннелирование данных через DNS.
  6. LLMNR/NetBIOS/mDNS-атаки в локальных сетях.
  7. Регистрация похожих доменов — typosquatting.
  8. Угон домена — 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-мониторинг

Что стоит мониторить:

  1. Доступность DNS-серверов.
  2. Время ответа.
  3. Корректность записей.
  4. NS-набор.
  5. DNSSEC.
  6. Срок истечения домена.
  7. Срок истечения TLS-сертификатов.
  8. Количество запросов.
  9. NXDOMAIN.
  10. Подозрительные домены.

Примеры инструментов:

  • 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. Практический чек-лист настройки домена

  1. Домен зарегистрирован.
  2. У регистратора указаны корректные NS.
  3. Зона создана на authoritative-серверах.
  4. Есть минимум два NS.
  5. Добавлены A/AAAA-записи.
  6. www настроен через CNAME или A.
  7. MX настроен, если нужна почта.
  8. PTR настроен для почтового IP.
  9. SPF добавлен.
  10. DKIM добавлен.
  11. DMARC добавлен.
  12. CAA добавлен при необходимости.
  13. TTL выбран разумно.
  14. DNSSEC включён, если возможно.
  15. Zone transfer ограничен.
  16. Рекурсия на authoritative-серверах ограничена или отключена.
  17. Мониторинг настроен.
  18. Резервные 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 и многих других технологий.

Ключевые вещи, которые важно помнить:

  1. DNS иерархичен: корень → TLD → домен → поддомен.
  2. Есть authoritative-серверы и рекурсивные резолверы.
  3. Записи бывают разные: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA.
  4. TTL управляет кэшированием.
  5. DNS-изменения распространяются не мгновенно.
  6. DNSSEC защищает целостность, DoT/DoH/DoQ — конфиденциальность.
  7. Безопасность DNS требует ограничения рекурсии, zone transfer, мониторинга и корректных SPF/DKIM/DMARC.
  8. Для диагностики лучше всего подходят dig, host, nslookup, resolvectl, Resolve-DnsName.

Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.


Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (5)(· · · — — — · · ·)(30)

Комментарии

Загрузка...
Если комментарии не загружаются, можете попробовать отключить блокировщик рекламы для этого сайта