Настройка DoT/DoH

[KorDen]

Хотелось бы понять логику работы DoT/DoH и взаимодействие с name-server.

Пробуем прописать, при включенном opkg dns-override и полном отсутствии ydns/adguard/...:

(config)> dns-proxy tls upstream 1.1.1.1 sni cloudflare-dns.com
Dns::Secure::ManagerDot: DNS-over-TLS name server "1.1.1.1" is disregarded while Internet Filter is active.

Т.е. как я понимаю, для резолва запросов самим роутером (RPC) DoT/DoH использовать нельзя, они будут ходить напрямую? (использовать name-server только для необходимых резолвов для DoH, и затем переходить полностью на DoH/DoT)

Как можно диагностировать работу DoT/DoH?

[Andreycko]

Пару раз в сутки выбивает такую ошибку:

"Дек 17 07:19:45 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped."

(такая проблема наблюдается и на других кинетиках (знакомым и родственникам ставил) с другими провайдерами)

С DOT так же проблемы периодически, почитал тут последние сообщения, я так понимаю проблема в прошивке роутера? 

 

[project_fcc]

  В 22.12.2021 в 22:32, Andrey Kalinich сказал:

"Дек 17 07:19:45 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped."

 

Показать  

Тоже такое бывает, но я так понимаю, процесс https-dns-proxy дальше перезапускается и работает.

[E] Dec 23 01:01:25 ndm: Service: "DoH "System" proxy #1": unexpectedly stopped.
[I] Dec 23 01:01:28 https-dns-proxy: Starting.
[I] Dec 23 01:01:28 https-dns-proxy: Using DNS-wire DoH request format 

Но сегодня на Peak на несколько часов DoH загрузил ЦП на 50% (одно ядро на 100%), ранее такой нагрузки на kn-1010 не наблюдал:

 

[Andreycko]

  В 23.12.2021 в 04:10, valeramalko сказал:

Тоже такое бывает, но я так понимаю, процесс https-dns-proxy дальше перезапускается и работает.

[E] Dec 23 01:01:25 ndm: Service: "DoH "System" proxy #1": unexpectedly stopped.
[I] Dec 23 01:01:28 https-dns-proxy: Starting.
[I] Dec 23 01:01:28 https-dns-proxy: Using DNS-wire DoH request format 

Но сегодня на Peak на несколько часов DoH загрузил ЦП на 50% (одно ядро на 100%), ранее такой нагрузки на kn-1010 не наблюдал:

 

Показать  

Оно то перезапускается, но в этот момент страницы не открываются.

Вот что поддержка сказала:

"Спасибо за информацию.

Если при работе Cloudflare или других DoH-сервисом в логе также присутствует следующая ошибка:

E] Nov 22 23:18:13 ndm: Service: "DoH "System" proxy #0": unexpectedly stopped.

То это означает, что сервис Cloudflare DNS DoH не отвечает на запрос \ ответ, возможно, в связи с фильтрацией - блокировкой домена в сети провайдера. Данное поведение исправлено в будущей версии ПО 3.08, а пока рекомендуется не пользоваться сервисом в DNS DoH, а пользоваться только DNS DoT, либо выбрать другие сервисы, указав домены в ручную, в разделе Интернет-фильтры."

 

[Le ecureuil]

Попробуйте на 3.8.

[Andreycko]

  В 23.12.2021 в 08:54, Le ecureuil сказал:

Попробуйте на 3.8.

Показать  

Стремно )) она даже не бета.

[Andreycko]

  В 23.12.2021 в 08:54, Le ecureuil сказал:

Попробуйте на 3.8.

Показать  

Обновился таки, сутки, полет нормальный. Дальше буду наблюдать.

[ale_xb]

Помогите разобраться, пожалуйста. Тему прочитал, но так и не понял, куда обращается сам роутер при разрешении имен с DoT/DoH. У меня настроен DoT на 3 сервера 1.0.0.1, 8.8.4.4, 9.9.9.9 на странице "Интернет-фильтр", других DNS в web-интерфейсе нигде не указано. Также "прилетают" DNS серверы из двух VPN подключений PPTP 192.168.0.1 (домен не важен и не указан, т.к. здесь инфо от этого DNS не использую) и OpenVPN 10.10.1.2, 10.10.1.5 (домен xxx.local). Адрес роутера в домашней локалке (домен home) 192.168.100.1. В web интерфейсе в настройках подключения к провайдеру установлена галочка "Игнорировать DNS". Вместо встроенного ndhcps (53-й его порт "погашен" командой opkg dns-override) настроен dnsmasq. Конфиг вот:

  Показать контент

user=nobody
domain-needed       # Never forward plain names (without a dot or domain part)
bogus-priv          # Fake reverse lookups for RFC1918 private address ranges,
                    # i.e. never forward addresses in the non-routed address spaces
no-negcache         # Do NOT cache failed search results
clear-on-reload     # Clear DNS cache when reloading dnsmasq
bind-dynamic
listen-address=192.168.100.1
listen-address=127.0.0.1
min-port=4096       # Specify lowest port available for DNS query transmission
cache-size=1536     # Specify the size of the cache in entries
expand-hosts        # Expand simple names in /etc/hosts with domain-suffix
log-async           # Enable async. logging; optionally set queue length
stop-dns-rebind     # Reject (and log) addresses from upstream nameservers which are in the private ranges
rebind-localhost-ok # Exempt 127.0.0.0/8 and ::1 from rebinding checks
rebind-domain-ok=/onion/
domain=home

#Настройки обхода блокировок из файла доп.конфига
conf-file=/opt/etc/unblock.dnsmasq

#Настройки для доступа к .onion
server=/onion/127.0.0.1#9053
ipset=/onion/unblock,unblock6

#Настройки для доступа к .ххх.local
server=/ххх.local/10.10.1.2#53    # Add other name servers here, with domain specs if they are for
server=/ххх.local/10.10.1.5#53    # non-public domains

#Настройки для использования встроенных в Keenetic DNS-over-TLS или DNS-Over-HTTPS
no-resolv           # Do NOT read resolv.conf
server=127.0.0.1#40500
server=127.0.0.1#40501
server=127.0.0.1#40502
 

теперь, что я вижу и вопросы:

1. В web-интерфейсе (Системный монитор/Подробнее о соединении):

• DNS-серверы  2a02:2168:208:1::1
•                            2a02:2168:208:2::1

Судя, по всему, "Игнорировать DNS" не распространяется на ipv6. Его можно (проверил), отключить командой interface ISP no ipv6 name-servers auto, но, будет ли в таком случае работать bootstrap для DoT/DoH (не выяснил). И, похоже, нет смысла ставить галочку "Игнорировать DNS", верно?

2. По команде  show ip name-server я вижу все серверы - из п.1, и "прилетевшие по VPN", правда провайдерские ipv6 DNS почему-то указаны, как "Client-eth3", хотя ISP у меня GigabitEthernet1, как у большинства:

  Показать контент

show ip name-server

           server:
              address: 192.168.0.1
                 port:
               domain:
               global: 0
              service: PPTP0
            interface: PPTP0

           server:
              address: 10.10.1.5
                 port:
               domain:
               global: 0
              service: OpenVPN0
            interface: OpenVPN0

           server:
              address: 10.10.1.2
                 port:
               domain:
               global: 0
              service: OpenVPN0
            interface: OpenVPN0

           server:
              address: 2a02:2168:208:1::1
                 port:
               domain:
               global: 0
              service: Ip6::Dhcp::Client-eth3
            interface: GigabitEthernet1

           server:
              address: 2a02:2168:208:2::1
                 port:
               domain:
               global: 0
              service: Ip6::Dhcp::Client-eth3
            interface: GigabitEthernet1

3. По команде show dns-proxy я вижу три моих DoT сервера. Здесь почему-то статические записи для устройств в домашней локалке указаны дважды - с и без домена home. Это нормально?

  Показать контент

(config)> show dns-proxy

     proxy-status:
            proxy-name: System

          proxy-config:

rpc_port = 54321
rpc_ttl = 10000
rpc_wait = 10000
timeout = 7000
proceed = 500
stat_file = /var/ndnproxymain.stat
stat_time = 10000
dns_server = 127.0.0.1:40500 . # 1.0.0.1@cloudflare-dns.com
dns_server = 127.0.0.1:40501 . # 8.8.4.4@dns.google
dns_server = 127.0.0.1:40502 . # 9.9.9.9@dns.quad9.net
static_a = my.keenetic.net 78.47.125.180
static_a = keenetic.local 192.168.100.1
static_a = 289b3153dd5a471547d36f6e.keenetic.io 78.47.125.180
static_a = A50 192.168.100.100
static_a = A50.home 192.168.100.100
static_a = M2101K7BNY 192.168.100.240
static_a = M2101K7BNY.home 192.168.100.240
static_a = Delta 192.168.100.10
static_a = Delta.home 192.168.100.10
padding = on
norebind_ctl = on
norebind_ip4net = 10.1.30.1:24
norebind_ip4net = 192.168.100.1:24
norebind_ip4net = 255.255.255.255:32
set-profile-ip 127.0.0.1 0
set-profile-ip ::1 0
rpc_only = on

            proxy-stat:

# ndnproxy statistics file

Total incoming requests: 13
Proxy requests sent:     14
Cache hits ratio:        0.000 (0)
Memory usage:            3.33K

DNS Servers

                      Ip   Port  R.Sent  A.Rcvd  NX.Rcvd  Med.Resp  Avg.Resp  Rank
               127.0.0.1  40500       2       2        0     397ms     202ms     4
               127.0.0.1  40501       0       0        0       0ms       0ms     2
               127.0.0.1  40502      12      11        0      43ms      47ms    10

            proxy-safe:

             proxy-tls:
               server-tls:
                      address: 1.0.0.1
                         port:
                          sni: cloudflare-dns.com
                         spki:
                    interface:

               server-tls:
                      address: 8.8.4.4
                         port:
                          sni: dns.google
                         spki:
                    interface:

               server-tls:
                      address: 9.9.9.9
                         port:
                          sni: dns.quad9.net
                         spki:
                    interface:

     proxy-tls-filters:

Кстати, попутный вопрос: Как назначаются ранки этим серверам? По выводу так и не ясно. Максимальный - и не у самого быстрого, и не у самого медленного.

4. Проверяю на роутере, как идет разрешение имен. Почему, если не указать явно DNS сервер, обращение идет к серверу, "прилетевшему" по VPN PPTP ? Возможно, потому, что у меня для этого сервера не указан домен (см.самое начало поста)? Можно ли ему указать абстрактный фейковый в настройках dnsmasq, чтобы к нему не было обращений? Но в любом случае, получается, сам роутер для разрешения имен не использует dns-proxy и соответственно DoT/DoH. Разве так должно быть?

И подскажите, пожалуйста, как проверить/убедиться с хоста в локалке, что для него разрешение имен идет через dns-proxy, т.е. своего рода трассировку запросов/ответов DNS.

  Показать контент

root@keenetic:/opt/etc$ nslookup ya.ru
Server:    192.168.0.1
Address 1: 192.168.0.1

Name:      ya.ru
Address 1: 2a02:6b8::2:242 ya.ru
Address 2: 87.250.250.242 ya.ru

root@keenetic:/opt/etc$ nslookup ya.ru 127.0.0.1
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      ya.ru
Address 1: 2a02:6b8::2:242 ya.ru
Address 2: 87.250.250.242 ya.ru

Собственно dns-proxy работает. tcpdump на lo интерфейсе показывает обращения на порты 40500-40502, да и вывод статистики в п.3 это подтверждает.

Изменено 8 апреля, 2022 пользователем ale_xb

[ale_xb]

Заметил еще одну странность dnsmasq. Это не совсем по теме, но близко. При попытке ping storage.xxx.local хоста в рабочем домене с хоста в домашней LAN вижу в tcpdump на роутере, что идет попытка разрешения указанного имени. При этом запрос корректно форвардится на рабочие DNS серверы и приходит правильный ответ. Здесь все ожидаемо, вопросов не вызывает.

  Показать контент

Apr  9 11:02:07 keenetic dnsmasq[5616]: query[A] storage.xxx.local from 192.168.100.10
Apr  9 11:02:07 keenetic dnsmasq[5616]: forwarded storage.xxx.local to 10.10.1.2
Apr  9 11:02:07 keenetic dnsmasq[5616]: forwarded storage.xxx.local to 10.10.1.5
Apr  9 11:02:07 keenetic dnsmasq[5616]: reply storage.xxx.xxxis 10.10.1.4

Но, если послать явный запрос на разрешение этого же имени командой nslookup storage.xxx.local, сначала формируется запрос с добавлением доменного суффикса home моей домашней LAN и только затем следует правильный запрос без оного. Если в конце запрашиваемого в nslookup FDQN поставить точку, то суффикс home ожидаемо не добавляется. Я ожидал, что суффикс будет добавляться только для запросов по имени без какого-либо суффикса вовсе. Можно ли добиться именного такого поведения dnsmasq, что надо поправить в его конфиге?

  Показать контент

Apr  9 11:02:29 keenetic dnsmasq[5616]: query[A] storage.xxx.local.home from 192.168.100.10
Apr  9 11:02:29 keenetic dnsmasq[5616]: forwarded storage.xxx.local.home to 127.0.0.1
Apr  9 11:02:29 keenetic dnsmasq[5616]: forwarded storage.xxx.local.home to 127.0.0.1
Apr  9 11:02:29 keenetic dnsmasq[5616]: query[A] storage.xxx.local from 192.168.100.10
Apr  9 11:02:29 keenetic dnsmasq[5616]: cached storage.xxx.local is 10.10.1.4
 

 

[litor89210]

поставил 3.8.1 и господь меня покарал ( ну что опять не так с вашим dot? даже поудалял и вбил заново- нуль. то, что от прова прилетает- работает, значит ndnproxy в принципе не просто на 53 висит, а ещё и что-то отчасти делает, ну а с dot что изменилось, какие телодвижения нужны, которые не требовались ранее?

     proxy-status:
              proxy-name: System

            proxy-config:

rpc_port = 54321
rpc_ttl = 10000
rpc_wait = 10000
timeout = 7000
proceed = 500
stat_file = /var/ndnproxymain.stat
stat_time = 10000
dns_server = 127.0.0.1:40500 . # 8.8.8.8@dns.google.com
static_a = my.keenetic.net 78.47.125.180
norebind_ctl = on
norebind_ip4net = 192.168.85.1:24
norebind_ip4net = 255.255.255.255:32
set-profile-ip 127.0.0.1 0
set-profile-ip ::1 0
dns_tcp_port = 53
dns_udp_port = 53

              proxy-stat:

# ndnproxy statistics file

Total incoming requests: 349
Proxy requests sent:     348
Cache hits ratio:        0.000 (0)
Memory usage:            7.82K

DNS Servers

                      Ip   Port  R.Sent  A.Rcvd  NX.Rcvd  Med.Resp  Avg.Resp  Rank
               127.0.0.1  40500     348       0        0       0ms       0ms     1
 

[Иннокентий]

Здравствуйте. После сброса к заводским настройкам, при настройке роутера заметил проблему. 

Конкретно связанную с настройкой интернет фильтра и сайтом 1.1.1.1. 

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

Раздражает что не могу понять, в чем проблема. На других сайтах пока с похожей проблемой не сталкилвался, но очень интересно с чем может быть связанно то, что при стороннем DNS перестает работать 1.1.1.1 в браузере 

add:

Разобрался, проблема была в установленных компонентах системы роутера. 
После удаления данных приложений 1.1.1.1 стал открываться. Видел подобные проблемы и у других пользователей, так что это баг видимо 

https://imgbox.com/q9Gdvltq

Изменено 18 августа, 2022 пользователем Иннокентий
Добавил решение проблемы

[Avaritia]

 

Правильно ли я понимаю, что при включении Кинетик обращается к 1.1.1.1 по udp:53 чтобы получить адрес dns.google ?

Изменено 28 января, 2023 пользователем Avaritia

[sergeyk]

  В 28.01.2023 в 21:59, Avaritia сказал:

Правильно ли я понимаю, что при включении Кинетик обращается к 1.1.1.1 по udp:53 чтобы получить адрес dns.google ?

Показать  

 

[kvsplz9860]

Как doq настроить на роутере keenetic?

Изменено 1 февраля, 2023 пользователем kvsplz9860

[avn]

  В 01.02.2023 в 22:53, kvsplz9860 сказал:

Как doq настроить на роутере keenetic?

Показать  

Nginx в entware установите с поддержкой quic паралельно существующему и там настройте.

[kvsplz9860]

  В 02.02.2023 в 07:29, avn сказал:

Nginx в entware установите с поддержкой quic паралельно существующему и там настройте.

Показать  

Dnscrypt не лучше?

Есть инструкция?

[Kazantsev]

Это норм? Или я неправильно настроил, также включён интернет фильтр на cloudflare

 

Изменено 8 апреля, 2023 пользователем Milk97

[PASPARTU]

  В 08.04.2023 в 04:23, Milk97 сказал:

Это норм? Или я неправильно настроил, также включён интернет фильтр на cloudflare

Показать  

или фильтр или то что сами добавили.

[Kazantsev]

  В 08.04.2023 в 04:36, PASPARTU сказал:

или фильтр или то что сами добавили.

Показать  

Ой, забыл прикрепить ещё один скриншот, чтобы было понятнее, вот, у меня DOT не работает

Изменено 8 апреля, 2023 пользователем Milk97

[keenet07]

  В 08.04.2023 в 04:23, Milk97 сказал:

Это норм? Или я неправильно настроил, также включён интернет фильтр на cloudflare

Показать  

Здесь не видно указан ли порт для DoT. Зайдите в него, адрес должен быть указан в формате 1.1.1.1:853, т.е. с портом. У меня так и точно работает. Хотя в инструкции вижу, что и без указания можно. 

По поводу скрина с сайта 1.1.1.1 там может и не показать DOT, если запрос прошёл по DOH.

Изменено 8 апреля, 2023 пользователем keenet07

[Kazantsev]

  В 08.04.2023 в 07:36, keenet07 сказал:

Здесь не видно указан ли порт для DoT. Зайдите в него, адрес должен быть указан в формате 1.1.1.1:853, т.е. с портом. У меня так и точно работает. Хотя в инструкции вижу, что и без указания можно. 

По поводу скрина с сайта 1.1.1.1 там может и не показать DOT, если запрос прошёл по DOH.

Показать  

так? а в 1.1.1.1 тоже порт 853? и в DOH больше ничего не надо добавлять

[keenet07]

  В 08.04.2023 в 08:07, Milk97 сказал:

так? а в 1.1.1.1 тоже порт 853?

Показать  

Да. Но всё это возможно и не обязательно. Наверняка и автоматом подставляется где нужно.

А на счёт скрина с проверкой я вам уже написал.

DOH норм.

Изменено 8 апреля, 2023 пользователем keenet07

[Kazantsev]

  В 08.04.2023 в 08:12, keenet07 сказал:

Да. Но всё это возможно и не обязательно. Наверняка и автоматом подставляется где нужно.

А на счёт скрина с проверкой я вам уже написал.

Показать  

получается можно не обращать внимание на NO? и так работает? а сам используешь это?

[keenet07]

  В 08.04.2023 в 08:15, Milk97 сказал:

получается можно не обращать внимание на NO? и так работает? а сам используешь это?

Показать  

Можно. Да, у меня чисто DOT и без включенных фильтров. Работает как нужно.

[keenet07]

Вот вам сайт для проверки утечки DNS запросов.

https://www.dnsleaktest.com

Если не увидите там других серверов отличных от CloudFlare, значит всё идёт правильно.

Для проверки DOT можете отключить фильтр. И даже временно убрать DOH.

 

Изменено 8 апреля, 2023 пользователем keenet07

[Existing2846]

Удалось ли кому-то найти источник проблем с too many failed requests при использовании профиля Cloudflare? Вижу в теме уже поднимался такой вопрос.

В системном профиле для DNS, DoT, DoH прописаны те же значения от Cloudflare но если я правильно понял - они должны игнорироваться при использовании профиля и роли не играть.

В логе происходит примерно следующее:

  Показать контент

[E] Apr 24 14:39:05 stubby: "cloudflare-dns.com": too many failed requests, try to reload process
[E] Apr 24 14:39:05 ndm: Service: "DoT "System" proxy #2": unexpectedly stopped.
[I] Apr 24 14:39:08 stubby: starting Stubby 0.4.0
[E] Apr 24 14:43:08 stubby: "cloudflare-dns.com": too many failed requests, try to reload process
[E] Apr 24 14:43:08 ndm: Service: "DoT "System" proxy #2": unexpectedly stopped.
[I] Apr 24 14:43:11 stubby: starting Stubby 0.4.0
[E] Apr 24 14:46:38 stubby: "cloudflare-dns.com": too many failed requests, try to reload process
[E] Apr 24 14:46:38 ndm: Service: "DoT "System" proxy #2": unexpectedly stopped.
[I] Apr 24 14:46:41 stubby: starting Stubby 0.4.0

 

Каким образом можно локализовать проблему?

[Denis P]

  В 24.04.2023 в 11:56, Existing2846 сказал:

Удалось ли кому-то найти источник проблем с too many failed requests при использовании профиля Cloudflare? Вижу в теме уже поднимался такой вопрос.

В системном профиле для DNS, DoT, DoH прописаны те же значения от Cloudflare но если я правильно понял - они должны игнорироваться при использовании профиля и роли не играть.

В логе происходит примерно следующее:

  Показать контент

[E] Apr 24 14:39:05 stubby: "cloudflare-dns.com": too many failed requests, try to reload process
[E] Apr 24 14:39:05 ndm: Service: "DoT "System" proxy #2": unexpectedly stopped.
[I] Apr 24 14:39:08 stubby: starting Stubby 0.4.0
[E] Apr 24 14:43:08 stubby: "cloudflare-dns.com": too many failed requests, try to reload process
[E] Apr 24 14:43:08 ndm: Service: "DoT "System" proxy #2": unexpectedly stopped.
[I] Apr 24 14:43:11 stubby: starting Stubby 0.4.0
[E] Apr 24 14:46:38 stubby: "cloudflare-dns.com": too many failed requests, try to reload process
[E] Apr 24 14:46:38 ndm: Service: "DoT "System" proxy #2": unexpectedly stopped.
[I] Apr 24 14:46:41 stubby: starting Stubby 0.4.0

 

Каким образом можно локализовать проблему?

Показать  

Чтоб наверняка - проверить на других устройствах нет ли проблем с резолвом (конкретно указав их на самом клиенте, не на роутере), при использовании doh/dot от cloudflare. С большой долей вероятности вопросы стоит адресовать провайдеру.

Изменено 24 апреля, 2023 пользователем Denis P

[Mixin]

  В 24.04.2023 в 11:56, Existing2846 сказал:

Удалось ли кому-то найти источник проблем с too many failed requests при использовании профиля Cloudflare?

Показать  

А тут точно проблема не с Cloudflare? 

[Existing2846]

  В 24.04.2023 в 19:10, Mixin сказал:

А тут точно проблема не с Cloudflare? 

Показать  

Не, у других же работает

 

  В 24.04.2023 в 16:18, Denis P сказал:

С большой долей вероятности вопросы стоит адресовать провайдеру.

Показать  

Были заданы, неделю пробовали с ними всякое. Разрешилось подключением мне белого ip - проблема сразу пропала, при возврате за общий снова были ошибки DoT/DoH. С тех пор сижу на белом ip который они любезно предоставили за свой счет и ни единого разрыва с DoT/DoH у меня не произошло.

[clockworkcarrot]

Привет! На роутере настроен DoH. Если я правильно понимаю, при включённой блокировке транзитных dns-запросов plaintext-запросы заворачиваются на роутер, а DoT/DoH – блокируются.

Может быть, кто-нибудь знает, можно ли штатными средствами сделать так, чтобы обычные dns-запросы из внутренней сети перехватывались и перенаправлялись на dns-сервер роутера, а DoT/DoH-запросы – пропускались как есть во внешний интернет?

Или единственный путь – это разрешение транзитных запросов в интерфейсе роутера и перенаправление нешифрованных запросов на внутренний dns-сервер средствами iptables?

Изменено 19 февраля, 2024 пользователем clockworkcarrot

[bnsott]

Подскажите, при настроенном DoH (NextDNS, через компонент Прокси-сервер DNS-over-HTTPS) адреса добавленные через ip host (сторонние, не для DoH сервера) игнорируются?

Изменено 17 марта, 2024 пользователем bnsott