Руководство по настройке DNS

DNS зона — это область ответственности за определенный домен. Например, зона example.com содержит все DNS записи для этого домена и его поддоменов.

Создание зоны

1. Перейдите в раздел DNS Зоны в боковом меню
2. Нажмите кнопку Добавить зону
3. Введите имя домена (например, example.com)
4. Зона будет создана с настройками SOA по умолчанию

Параметры SOA

При создании зоны автоматически заполняются параметры SOA (Start of Authority):

• Serial — версия зоны (увеличивается при каждом изменении)
• Refresh — интервал обновления для secondary NS (секунды)
• Retry — интервал повторной попытки при ошибке обновления
• Expire — время, после которого secondary NS перестает отвечать
• Minimum TTL — время кэширования негативных ответов (NXDOMAIN)

После создания зоны добавьте необходимые DNS записи. Ниже описаны поддерживаемые типы:

Частые ошибки при создании записей

• MX запись с IP адресом — содержимое MX должно быть именем хоста, а не IP адресом. Используйте mail.example.com, а не 192.168.1.1
• CNAME на корне зоны — нельзя создать CNAME для @, это нарушает RFC. Используйте A/AAAA записи
• Несовпадение имени — убедитесь, что имя записи соответствует запрашиваемому домену. Для корня зоны используйте @
• Отключенные записи — проверьте, что запись не деактивирована

Чтобы CloudDNS начал обслуживать ваш домен, необходимо делегировать его на наши NS серверы у вашего регистратора домена.

Наши NS серверы

ns1.clouddns.ru
ns2.clouddns.ru

Порядок действий

1. Войдите в панель управления вашего регистратора домена
2. Найдите раздел управления NS серверами (DNS серверы / Nameservers)
3. Замените текущие NS серверы на ns1.clouddns.ru и ns2.clouddns.ru
4. Сохраните изменения
5. Дождитесь распространения (от 1 до 48 часов)

После настройки зоны и добавления записей убедитесь, что все работает корректно.

Проверка через dig

Утилита dig — стандартный инструмент для DNS диагностики:

# Проверка A записи напрямую через наш DNS сервер
dig @ns1.clouddns.ru A example.com

# Проверка MX записи
dig @ns1.clouddns.ru MX example.com

# Проверка TXT записи (SPF, DKIM)
dig @ns1.clouddns.ru TXT example.com

# Проверка CNAME
dig @ns1.clouddns.ru CNAME www.example.com

# Проверка ANY (все записи)
dig @ns1.clouddns.ru ANY example.com

# Короткий формат (только ответы)
dig @ns1.clouddns.ru A example.com +short

# Проверка через публичный DNS (после делегирования)
dig @77.88.8.8 A example.com

Проверка через nslookup

# Проверка A записи
nslookup example.com ns1.clouddns.ru

# Проверка MX записи
nslookup -type=MX example.com ns1.clouddns.ru

# Проверка NS делегирования
nslookup -type=NS example.com

Проверка через DoH (curl)

# DNS-over-HTTPS запрос в формате JSON
curl -s "https://dns.clouddns.ru/dns-query?name=example.com&type=A" \
  -H "Accept: application/dns-json" | jq .

# DNS-over-HTTPS запрос в формате wireformat
curl -s "https://dns.clouddns.ru/dns-query?dns=AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE" \
  -H "Accept: application/dns-message" | hexdump -C

Ожидаемые ответы

• NOERROR — запрос успешен, ответ получен
• NXDOMAIN — имя не существует в зоне (проверьте имя записи)
• REFUSED — зона не обслуживается сервером (проверьте делегирование)
• SERVFAIL — ошибка на сервере (обратитесь в поддержку)

Web Application Firewall (WAF) — это межсетевой экран уровня приложений, который анализирует HTTP-запросы к вашему сайту и блокирует вредоносный трафик. В CloudDNS WAF работает на базе Coraza (совместим с ModSecurity) и доступен для записей с включенным проксированием.

Как это работает

1. Вы создаете A или AAAA запись и включаете проксирование (иконка облака)
2. DNS начинает отдавать IP-адрес прокси-сервера CloudDNS вместо вашего origin-сервера
3. Весь HTTP/HTTPS трафик проходит через прокси, где применяются правила WAF
4. Легитимные запросы пропускаются на ваш origin-сервер, вредоносные — блокируются

Предварительные шаги

1. Перейдите на страницу зоны и создайте A-запись с включенным проксированием
2. Перейдите в Настройки прокси и проверьте, что origin-адрес указывает на ваш сервер
3. Перейдите в Правила WAF для управления защитой

Набор правил OWASP CRS

При создании зоны автоматически включается набор правил OWASP Core Rule Set (CRS) — это проверенный набор из сотен правил, защищающий от основных веб-атак: SQL-инъекции, XSS, path traversal, сканирование уязвимостей и другие угрозы из OWASP Top 10.

Вы можете включать и отключать набор OWASP CRS на странице Правила WAF в разделе «Наборы правил».

Помимо набора OWASP CRS, вы можете создавать собственные правила WAF для точной настройки под ваше приложение.

Структура правила

Каждое правило WAF состоит из четырех частей:

Доступные действия (Action)

Переменные для Expression

Expression состоит из переменной (что проверять) и оператора (как проверять). Основные переменные:

Операторы для Expression

Примеры правил

Блокировка IP-адреса:

Expression: REMOTE_ADDR @ipMatch 192.168.1.100
Action:     deny
Описание:   Блокировка подозрительного IP

Блокировка подсети:

Expression: REMOTE_ADDR @ipMatch 10.0.0.0/8
Action:     deny
Описание:   Блокировка внутренней подсети

Блокировка ботов по User-Agent:

Expression: REQUEST_HEADERS:User-Agent @rx (sqlmap|nikto|nmap|masscan)
Action:     deny
Описание:   Блокировка известных сканеров уязвимостей

Блокировка доступа к админ-панели:

Expression: REQUEST_URI @beginsWith /wp-admin
Action:     deny
Описание:   Запрет доступа к WordPress админке

Блокировка подозрительных запросов в URL:

Expression: REQUEST_URI @rx (\.\.[\/]|etc/passwd|/proc/self)
Action:     deny
Описание:   Защита от path traversal

Блокировка SQL-инъекций в параметрах:

Expression: ARGS @rx (union.*select|insert.*into|drop.*table)
Action:     deny
Описание:   Базовая защита от SQL-инъекций

Разрешение только GET и POST:

Expression: REQUEST_METHOD @rx ^(PUT|DELETE|PATCH|OPTIONS)$
Action:     deny
Описание:   Разрешить только GET и POST методы

Логирование запросов к API:

Expression: REQUEST_URI @beginsWith /api/
Action:     log
Описание:   Логирование всех запросов к API

Ограничения

• Максимальная длина expression — 1024 символа
• Максимальная длина описания — 512 символов
• В expression запрещены символы: двойные кавычки, обратные слеши, переносы строк
• Action должен быть одним из: deny, block, allow, pass, log, drop, redirect

Порядок создания правил

1. Перейдите на страницу зоны и нажмите Правила WAF
2. Нажмите Добавить правило
3. Заполните Expression, выберите Action, укажите приоритет
4. Правило можно включать и отключать без удаления
5. Изменения применяются в течение 30 секунд

DoH шифрует DNS запросы внутри HTTPS-соединения (порт 443). Трафик неотличим от обычного веб-трафика, что затрудняет его блокировку.

Поддержка в браузерах

• Firefox: Настройки → Сеть → Включить DNS через HTTPS → указать URL
• Chrome/Edge: Настройки → Безопасность → Использовать защищенный DNS → указать URL

Проверка через curl

# Проверка DoH (JSON формат)
curl -s "https://dns.clouddns.ru/dns-query?name=example.com&type=A" \
  -H "Accept: application/dns-json"

# Проверка DoH (wireformat, RFC 8484)
echo -n "q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE=" | \
  base64 -d | \
  curl -s -X POST "https://dns.clouddns.ru/dns-query" \
    -H "Content-Type: application/dns-message" \
    --data-binary @- | hexdump -C

DoT шифрует DNS запросы с помощью TLS на выделенном порту 853. Это стандартный способ шифрования DNS, поддерживаемый большинством ОС и маршрутизаторов.

Проверка через kdig (knot-dnsutils)

# Установка (Debian/Ubuntu)
sudo apt install knot-dnsutils

# Проверка DoT
kdig @dns.clouddns.ru +tls A example.com

# С явным указанием порта
kdig @dns.clouddns.ru -p 853 +tls A example.com

Проверка через openssl

# Подключение к DoT серверу
openssl s_client -connect dns.clouddns.ru:853 -quiet

DoQ — новейший протокол шифрованного DNS, основанный на QUIC (UDP). Обеспечивает низкую задержку за счет отсутствия TCP handshake и встроенного шифрования.

Проверка через q (DNS client)

# Установка q (https://github.com/natesales/q)
# Linux
curl -sL https://github.com/natesales/q/releases/latest/download/q-linux-amd64 \
  -o /usr/local/bin/q && chmod +x /usr/local/bin/q

# Проверка DoQ
q A example.com @quic://dns.clouddns.ru:853

Проверка через dnslookup

# Установка dnslookup
go install github.com/ameshkov/dnslookup@latest

# Проверка DoQ
dnslookup example.com quic://dns.clouddns.ru:853

MikroTik RouterOS 6.47+ поддерживает DoH. RouterOS 7 добавляет улучшенную поддержку с верификацией сертификатов.

DNS-over-HTTPS (RouterOS 6.47+)

# 1. Импортируйте корневые сертификаты
/tool fetch url=https://curl.se/ca/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

# 2. Настройте DoH
/ip dns set use-doh-server="https://dns.clouddns.ru/dns-query" verify-doh-cert=yes

# 3. Очистите обычные DNS серверы (опционально)
/ip dns set servers=""

# 4. Разрешите удаленные запросы (если роутер выступает DNS для LAN)
/ip dns set allow-remote-requests=yes

# 5. Проверьте
/ip dns print
/ip dns cache print

DNS-over-HTTPS (RouterOS 7)

# RouterOS 7 — упрощенная настройка
/ip/dns/set use-doh-server="https://dns.clouddns.ru/dns-query" \
  verify-doh-cert=yes

# Очистите fallback серверы
/ip/dns/set servers=""

# Проверка
/ip/dns/print
/ip/dns/cache/print

Классический DNS (без шифрования)

# Если DoH не нужен — используйте обычный DNS
/ip dns set servers=<IP_ВАШЕГО_FORWARDER>:5353

# Проверка
/ping dns.clouddns.ru count=3

Перенаправление DNS трафика из LAN

# Перехват всех DNS запросов из LAN и перенаправление на роутер
/ip firewall nat add chain=dstnat protocol=tcp dst-port=53 \
  action=redirect to-ports=53 comment="Redirect DNS TCP"
/ip firewall nat add chain=dstnat protocol=udp dst-port=53 \
  action=redirect to-ports=53 comment="Redirect DNS UDP"

DNS-over-TLS через systemd-resolved

systemd-resolved (Ubuntu 18.04+, Fedora, Arch) поддерживает DoT из коробки:

# Редактируем конфигурацию
sudo nano /etc/systemd/resolved.conf

# Добавьте/измените следующие строки:
[Resolve]
DNS=<IP_ВАШЕГО_СЕРВЕРА>
DNSOverTLS=yes
Domains=~.

# Перезапустите сервис
sudo systemctl restart systemd-resolved

# Проверьте статус
resolvectl status
resolvectl query example.com

DNS-over-TLS через stubby

stubby — легковесный DNS stub resolver с поддержкой DoT:

# Установка
sudo apt install stubby    # Debian/Ubuntu
sudo dnf install stubby    # Fedora

# Конфигурация: /etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
upstream_recursive_servers:
  - address_data: <IP_ВАШЕГО_СЕРВЕРА>
    tls_auth_name: "dns.clouddns.ru"
    tls_port: 853
listen_addresses:
  - 127.0.0.1@53
  - 0::1@53

# Перезапуск
sudo systemctl restart stubby

# Укажите системе использовать stubby
sudo resolvectl dns eth0 127.0.0.1
# или в /etc/resolv.conf:
# nameserver 127.0.0.1

DNS-over-HTTPS через cloudflared (dnsproxy)

cloudflared можно использовать как локальный DoH прокси для любого DoH провайдера:

# Установка dnsproxy (универсальный вариант)
wget https://github.com/AdguardTeam/dnsproxy/releases/latest/download/dnsproxy-linux-amd64-*.tar.gz
tar xzf dnsproxy-linux-amd64-*.tar.gz
sudo mv dnsproxy /usr/local/bin/

# Запуск локального DoH прокси
dnsproxy -l 127.0.0.1 -p 53 -u https://dns.clouddns.ru/dns-query

# Или в качестве systemd сервиса:
sudo tee /etc/systemd/system/dnsproxy.service << 'EOF'
[Unit]
Description=DNS Proxy (DoH)
After=network.target

[Service]
ExecStart=/usr/local/bin/dnsproxy -l 127.0.0.1 -p 53 \
  -u https://dns.clouddns.ru/dns-query
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now dnsproxy

# Настройте систему на 127.0.0.1
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf

DNS-over-QUIC через dnsproxy

# dnsproxy поддерживает все протоколы, включая DoQ
dnsproxy -l 127.0.0.1 -p 53 -u quic://dns.clouddns.ru:853

Проверка итогового результата

# Проверка текущего DNS резолвера
cat /etc/resolv.conf

# Проверка через dig
dig example.com +short

# Проверка DoT соединения
resolvectl status | grep -A5 "DNS Server"

# Проверка утечки DNS (должен отвечать ваш сервер)
dig whoami.cloudflare TXT CH +short