Настройка Stubby и https-dns-proxy для DNS через TLS и HTTPS

При совместном использовании Stubby и https-dns-proxy часто возникает ситуация, когда работает только DoH (DNS через HTTPS), а DoT (DNS через TLS) не обрабатывается. Это связано с неверной цепочкой перенаправления запросов и конфликтом портов. В этом руководстве мы подробно разберём корректную настройку обоих сервисов, чтобы обеспечить шифрованный DNS-запрос как через TLS, так и через HTTPS.

Почему DoT может не работать при включённом DoH?

Основная причина - https-dns-proxy по умолчанию слушает на порту 53 и перенаправляет все запросы на upstream-сервер (например, 127.0.0.1:5053). Если Stubby настроен на порт 5453, а https-dns-proxy ожидает ответ на 5053, цепочка разрывается. Кроме того, если в системе используется dnsmasq, он может перехватывать запросы раньше, чем они дойдут до Stubby.

Корректная конфигурация https-dns-proxy

Используйте следующий конфигурационный файл (обычно /etc/config/https-dns-proxy или /opt/etc/https-dns-proxy.conf):

user=nobody
bogus-priv
no-negcache
clear-on-reload
bind-dynamic
listen-address=192.168.1.1
listen-address=127.0.0.1
min-port=4096
cache-size=1536
expand-hosts
edns-packet-max=1280
no-resolv
server=127.0.0.1#5453

Ключевое изменение - server=127.0.0.1#5453. Теперь все DNS-запросы, приходящие на https-dns-proxy (например, через DoH), будут перенаправляться на Stubby, который слушает на порту 5453. Параметр no-resolv запрещает использование системных резолверов, а bind-dynamic позволяет серверу автоматически привязываться к доступным интерфейсам.

Корректная конфигурация Stubby

Убедитесь, что Stubby настроен на приём запросов с порта 5453 и использует только TLS-транспорт. Пример конфигурации (/opt/etc/stubby/stubby.yml):

resolution_type: GETDNS_RESOLUTION_STUB
round_robin_upstreams: 1
appdata_dir: "/opt/var/lib/stubby"
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 10000
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
upstream_recursive_servers:
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

Обратите внимание: параметр listen_addresses содержит только порт 5453. Никаких других портов быть не должно. Если Stubby слушает на порту 53, он будет конфликтовать с https-dns-proxy или dnsmasq.

Проверка работы DoT и DoH

После внесения изменений перезапустите оба сервиса:

systemctl restart stubby
systemctl restart https-dns-proxy

Для проверки DoT используйте утилиту kdig или drill с указанием порта 5453:
drill @127.0.0.1 -p 5453 example.com
Для проверки DoH отправьте запрос через curl:
curl -H 'accept: application/dns-json' 'https://192.168.1.1/dns-query?name=example.com'

Типичные ошибки при настройке

• Порт 53 занят dnsmasq: отключите dnsmasq или перенастройте его на другой порт (например, 5353).
• Stubby не слушает на нужном порту: проверьте командой netstat -tulpn | grep stubby.
• Неверный порядок серверов: в https-dns-proxy сначала должен быть указан сервер Stubby, а не внешние DNS.
• Файрвол блокирует порт 853: разрешите исходящие соединения на порт 853 для Stubby.

Заключение

Правильная связка Stubby + https-dns-proxy позволяет одновременно использовать DoT и DoH, шифруя DNS-трафик на всех уровнях. Главное - синхронизировать порты: https-dns-proxy должен отправлять запросы на порт Stubby (5453), а Stubby - обращаться к upstream-серверам через TLS. После настройки проверьте логи обоих сервисов на наличие ошибок.