Как разобраться с кейсом: настройка stubby совместно с https-dns-proxy?

Ссылка скопирована
dns
1 ответ

По вводным: настроить stubby совместно с https-dns-proxy. На данный момент работает только DoH.
По вводным: вот конфиг https-dns-proxy

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 ###use https no-resolv server=127.0.0.1#5053

И вот конфиг stubby

# Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. 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"
Нужно решить такую задачу?

Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.

Заказать помощь
Лучший ответ
1
Backend-редакция Ответ

В вашем конфиге сейчас https-dns-proxy слушает 127.0.0.1#5053, а stubby слушает 127.0.0.1@5453. Но dnsmasq направлен только на DoH через 5053:

server=127.0.0.1#5053

server=127.0.0.1#5053

Поэтому работает только DoH. Чтобы задействовать stubby как DoT, dnsmasq должен отправлять запросы на порт stubby, например:

no-resolv
server=127.0.0.1#5453

no-resolv server=127.0.0.1#5453

Если вы хотите использовать и DoH, и DoT одновременно, нужно понимать, кто у вас главный upstream для dnsmasq. Обычно выбирают один локальный резолвер: либо https-dns-proxy на 5053, либо stubby на 5453. Можно прописать оба:

no-resolv
server=127.0.0.1#5053
server=127.0.0.1#5453

no-resolv server=127.0.0.1#5053 server=127.0.0.1#5453

Но это не всегда означает “резервирование как хочется”: dnsmasq может выбирать серверы по своей логике, а диагностика усложнится. Для начала лучше оставить один путь и добиться его работы.

Проверьте stubby отдельно:

dig @127.0.0.1 -p 5453 example.com
logread -e stubby
netstat -lntup | grep 5453

dig @127.0.0.1 -p 5453 example.com logread -e stubby netstat -lntup | grep 5453

В конфиге stubby обратите внимание на последний upstream:

- address_data: 1.0.0.1
  tls_auth_name: ""

- address_data: 1.0.0.1 tls_auth_name: ""

Для Cloudflare нужно указывать cloudflare-dns.com, иначе TLS-аутентификация может не пройти:

- address_data: 1.0.0.1
  tls_auth_name: "cloudflare-dns.com"

- address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com"

Также на OpenWRT stubby часто конфигурируется через UCI-файл /etc/config/stubby. Если вы редактируете YAML, но не включили manual mode, изменения могут не применяться. Проверьте строку из комментария: option manual '1'.

Итог: сейчас dnsmasq ходит в DoH на 5053, поэтому stubby не участвует. Переключите server на 5453, проверьте stubby через dig, исправьте tls_auth_name и убедитесь, что OpenWRT реально использует ваш конфиг stubby.

Другие ответы (0)

Пока нет других ответов. Будьте первым, кто поможет автору.

Ответить на вопрос

комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вам также может быть интересно