Перейти к содержанию

Вопрос

Опубликовано

Хотелось бы понять логику работы 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?

Рекомендуемые сообщения

  • 0
Опубликовано
В 12.08.2021 в 01:03, НиколайLT сказал:

Благодарю. Не совсем понял что такое bootstrap. мои проблемы.

 

На этот ответьте пожалуйста:

День добрый, как я понял по данному комментарию, лучше не использовать DoH в данной модели (Keenetic Lite KN-1310), на данном чипе?

Если не против ссылку на ваш ответ скину обратно в ветку по данному роутеру на 4pda, для будущих любопытных пользователей.

bootstrap это изначальное преобразование FQDN -> IP для установки соединения с адресами DoH.

Использовать можно, если нет проблем. Если наблюдаются проблемы, то стоит отключить.

  • 0
Опубликовано

привет! а как можно зафорсить DoH ходить к dns.google через 6in4 туннель? я так понял, что `https upstream .. on <interface>` не позволяет указать через какой интерфейс ходить, а дропнуть A record для dns.google на кинетике нельзя, да и не знаю пойдет ли DoH клиент за АААА тогда. 

  • 0
Опубликовано
46 минут назад, Eugeny Novozhilov сказал:

привет! а как можно зафорсить DoH ходить к dns.google через 6in4 туннель? я так понял, что `https upstream .. on <interface>` не позволяет указать через какой интерфейс ходить, а дропнуть A record для dns.google на кинетике нельзя, да и не знаю пойдет ли DoH клиент за АААА тогда. 

Dot/doh кинетика только v4 умеет вроде

  • 0
Опубликовано (изменено)
14 hours ago, Eugeny Novozhilov said:

привет! а как можно зафорсить DoH ходить к dns.google через 6in4 туннель? я так понял, что `https upstream .. on <interface>` не позволяет указать через какой интерфейс ходить, а дропнуть A record для dns.google на кинетике нельзя, да и не знаю пойдет ли DoH клиент за АААА тогда. 

по идее, это делается через прописывание маршрута. тостер нативно умеет 6to4, а значит фейс будет виден в гуе маршрутизации. если не нативно(тот же teredo), тогда ip route add. нэ?

Изменено пользователем pol newman
  • 0
Опубликовано
В 14.09.2021 в 21:12, Eugeny Novozhilov сказал:

привет! а как можно зафорсить DoH ходить к dns.google через 6in4 туннель? я так понял, что `https upstream .. on <interface>` не позволяет указать через какой интерфейс ходить, а дропнуть A record для dns.google на кинетике нельзя, да и не знаю пойдет ли DoH клиент за АААА тогда. 

Можно попробовать через NextDNS CLI Client он умеет IPv6 + там есть встроенный Multi upstream healthcheck / fallback 

  • 0
Опубликовано
3 часа назад, Sim-Sim сказал:

Можно попробовать через NextDNS CLI Client он умеет IPv6 + там есть встроенный Multi upstream healthcheck / fallback 

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

  • 0
Опубликовано
5 часов назад, BABUT сказал:

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

Да, похоже это не решает задачу, тут есть только:

Using Another DoH Provide

sudo nextdns install \
    -listen :53 \
    -forwarder https://1.1.1.1/dns-query
и
Split Horizon
sudo nextdns config set \
    -forwarder mycompany.com=1.2.3.4,1.2.3.5 \
    -forwarder mycompany2.com=https://doh.mycompany.com/dns-query#1.2.3.4
sudo nextdns restart
  • 0
Опубликовано (изменено)
В 21.05.2021 в 20:30, vk11 сказал:

145.100.185.15, 145.100.185.16, 185.49.141.37 (getdnsapi.net).

 

точно такая же история при использовании DNS over HTTPS на сервера Google. в активных соединениях переодически идет обращение к этим DNS Privacy серверам по udp/53. все лишние запросы идущие через служебный трафик отключил, кроме internet-checker. 

В 21.05.2021 в 16:41, keenet07 сказал:

Да, несколько служебных открытых DNS запросов роутер будет периодически слать при работе DOH.

8.8.8.8 8.8.4.4 udp/53 вопросов не вызывает, а вот те три все-таки не совсем понятно от кого идут.

можно как-нибудь поподробнее объяснить?

Изменено пользователем cheburashkaDNS
  • 0
Опубликовано (изменено)

185.49.141.37   https://getdnsapi.net   Нидерланды.  Такой же публичный резолвер как и 8.8.8.8 или 1.1.1.1 только менее известный и более мелкий.  В целом все эти запросы для скорости и для надежности резолвинга адресов вашего DOH сервера.

Они отправляются одновременно и самый вроде самый быстрый ответ и используется. А дальше уже все ваши запросы идут исключительно внутри DOH.

 

Изменено пользователем keenet07
  • 0
Опубликовано
15 часов назад, cheburashkaDNS сказал:

 

точно такая же история при использовании DNS over HTTPS на сервера Google. в активных соединениях переодически идет обращение к этим DNS Privacy серверам по udp/53. все лишние запросы идущие через служебный трафик отключил, кроме internet-checker. 

8.8.8.8 8.8.4.4 udp/53 вопросов не вызывает, а вот те три все-таки не совсем понятно от кого идут.

можно как-нибудь поподробнее объяснить?

Это встроенный bootstrap, используется для разрешения внешнего имени DoH и DoT. Можете сами увидеть это, посмотря дампы на WAN, какие запросы туда идут.

Про запас зашит такой список адресов для DoT:

"8.8.8.8", "1.1.1.1", "145.100.185.15", "185.49.141.37"

Для DoH вот:

https://github.com/aarond10/https_dns_proxy/blob/master/src/options.c#L31

  • 0
Опубликовано

@Le ecureuil, спасибо за развёрнутый ответ.

такой вопрос в догонку, с чем связаны проблемы в работе DoH Cloudflare? в отличии от гугла в системном журнале постоянно идут ошибки do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 632e7300 и отваливается интернет соединение, либо сайты начинают открываться с глюками. 

Скрытый текст

Сен 15 19:02:19 ndm
Core::Syslog: the system log has been cleared.
Сен 15 19:05:40 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:07:18 ndm
Network::InternetChecker: Internet access lost (status: 0x0001).
Сен 15 19:08:20 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:08:23 https-dns-proxy
Starting.
Сен 15 19:08:23 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:08:23 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:08:33 ndm
Network::InternetChecker: Internet access detected.
Сен 15 19:10:41 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:14:45 ndm
Network::InternetChecker: Internet access lost (status: 0x0001).
Сен 15 19:14:56 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:14:59 https-dns-proxy
Starting.
Сен 15 19:14:59 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:14:59 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:15:03 ndm
Network::InternetChecker: Internet access detected.
Сен 15 19:15:41 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:19:29 ndm
Network::InternetChecker: Internet access lost (status: 0x0001).
Сен 15 19:20:41 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:21:31 kernel
do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 2d736e64
Сен 15 19:21:31 kernel
epc = 00419c4c in https_dns_proxy[400000+27000]
Сен 15 19:21:31 kernel
ra = 00419c1c in https_dns_proxy[400000+27000]
Сен 15 19:21:31 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:21:34 https-dns-proxy
Starting.
Сен 15 19:21:34 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:21:34 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'


Сен 15 19:35:42 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:35:54 kernel
do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 632e7300
Сен 15 19:35:54 kernel
epc = 00419c4c in https_dns_proxy[400000+27000]
Сен 15 19:35:54 kernel
ra = 00419c1c in https_dns_proxy[400000+27000]
Сен 15 19:35:54 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:35:57 https-dns-proxy
Starting.
Сен 15 19:35:57 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:35:57 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:36:04 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:36:07 https-dns-proxy
Starting.
Сен 15 19:36:07 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:36:07 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:36:11 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:36:14 https-dns-proxy
Starting.
Сен 15 19:36:14 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:36:14 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:36:19 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:36:22 https-dns-proxy
Starting.
Сен 15 19:36:22 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:36:22 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:36:24 ndm
Network::InternetChecker: Internet access detected.
Сен 15 19:40:42 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:40:59 ndm
Network::InternetChecker: Internet access lost (status: 0x0001).
Сен 15 19:43:39 ndm
Service: "DoH "System" proxy #0": unexpectedly stopped.
Сен 15 19:43:42 https-dns-proxy
Starting.
Сен 15 19:43:42 https-dns-proxy
Using DNS-wire DoH request format
Сен 15 19:43:42 https-dns-proxy
DNS polling initialized for 'cloudflare-dns.com'
Сен 15 19:43:59 ndm
Network::InternetChecker: Internet access detected.
Сен 15 19:45:42 ndhcpc
GigabitEthernet1: received ACK for 100.127.x.xx from 100.127.0.1 lease 600 sec.
Сен 15 19:46:00 ndm
Network::InternetChecker: Internet access lost (status: 0x0001).

 

  • 0
Опубликовано
19 минут назад, cheburashkaDNS сказал:

@Le ecureuil, спасибо за развёрнутый ответ.

такой вопрос в догонку, с чем связаны проблемы в работе DoH Cloudflare? в отличии от гугла в системном журнале постоянно идут ошибки do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 632e7300 и отваливается интернет соединение, либо сайты начинают открываться с глюками. 

  Показать содержимое

 

Работа ведется над этим, в версии 3.8 (по моим ощущениям) все поправилось. В 3.7 это, к сожалению, перенести не планируется, так как с 3.8 убрана поддержка формата JSON, остался только DNS-Message.

Как только появится 3.8.A сразу ставьте и проверяйте.

  • 0
Опубликовано
12 минуты назад, Le ecureuil сказал:
6 часов назад, Le ecureuil сказал:

Это встроенный bootstrap, используется для разрешения внешнего имени DoH и DoT. Можете сами увидеть это, посмотря дампы на WAN, какие запросы туда идут.

Про запас зашит такой список адресов для DoT:

"8.8.8.8", "1.1.1.1", "145.100.185.15", "185.49.141.37"

Для DoH вот:

https://github.com/aarond10/https_dns_proxy/blob/master/src/options.c#L31

Может просто дать возможность  пользователям самим определять через каких провайдеров резолвить DOH и DOT ?  
 

Да окей оставьте "145.100.185.15", "185.49.141.37" для встроенных сервисов, но для DOH и DOT предоставьте возможность выбора Upstream DNS. Это снимет большую часть вопросов.

  • 0
Опубликовано

@Le ecureuil, а обновление до 3.8 на Giga III планируется вообще? сейчас глянул в дашборд стоит последняя стабильная 3.5.10
в релизах уже есть 3.6.11 для старших моделей 1010/1810, там же аппаратная начинка одна и та же за исключением беспроводной связи

 

  • 0
Опубликовано
3 часа назад, cheburashkaDNS сказал:

@Le ecureuil, а обновление до 3.8 на Giga III планируется вообще? 

3.8 не вышла ещё даже на общедоступную альфа стадию, так как 3.7 не вышла в официальную бету. Касаемо GIII - то архивная модель осталась за бортом...

  • 0
Опубликовано (изменено)
7 часов назад, cheburashkaDNS сказал:

@Le ecureuil, а обновление до 3.8 на Giga III планируется вообще? сейчас глянул в дашборд стоит последняя стабильная 3.5.10
в релизах уже есть 3.6.11 для старших моделей 1010/1810, там же аппаратная начинка одна и та же за исключением беспроводной связи

 

Как и с 3.6, в draft/delta канале будет доступна 3.8 для вашего устройства.

Переходите на delta канал обновлений

Изменено пользователем r13
  • 0
Опубликовано
11 час назад, Sim-Sim сказал:

Может просто дать возможность  пользователям самим определять через каких провайдеров резолвить DOH и DOT ?  
 

Да окей оставьте "145.100.185.15", "185.49.141.37" для встроенных сервисов, но для DOH и DOT предоставьте возможность выбора Upstream DNS. Это снимет большую часть вопросов.

Да, в 3.8 тоже будет. Будут использоваться провайдерские DNS или из ip nameserver, и только если везде пусто будет идти fallback на эти.

  • 0
Опубликовано
11 час назад, cheburashkaDNS сказал:

@Le ecureuil, а обновление до 3.8 на Giga III планируется вообще? сейчас глянул в дашборд стоит последняя стабильная 3.5.10
в релизах уже есть 3.6.11 для старших моделей 1010/1810, там же аппаратная начинка одна и та же за исключением беспроводной связи

 

Только draft и delta.

  • 0
Опубликовано
On 9/24/2021 at 3:18 PM, cheburashkaDNS said:

@Le ecureuil, правильно ли я понимаю что при использовании doh google напрямую https://8.8.8.8/dns-query и https://8.8.4.4/dns-query запросы bootstrap по udp/53 осуществляться не будут?

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

  • 0
Опубликовано
В 24.09.2021 в 15:18, cheburashkaDNS сказал:

@Le ecureuil, правильно ли я понимаю что при использовании doh google напрямую https://8.8.8.8/dns-query и https://8.8.4.4/dns-query запросы bootstrap по udp/53 осуществляться не будут?

По идее да, не должны. Но тогда у вас никакой проверки сертификата тоже не будет, что вообще говоря не очень.

В 3.8 поведение выровнено, и DoT и DoH сначала смотрят в ip host (если там что-то есть, то используют только тот адрес для домена, который вы руками заколотили), потом идут в ip name-server или к провайдеру (в зависимости от того, что есть), и только потом уже лезут на fallback.

  • 0
Опубликовано
44 минуты назад, user404 сказал:

а разве корневые сертификаты не должны находиться локально? или проверка- это проверка не отозван ли он?

Когда в URL не указано доменное имя как можно понять какой сертификат из хранилища брать для проверки? Если брать тот, что пришел в ответе по TLS - а как доказать что юзер хотел именно этот домен и не происходит MITM?

  • 0
Опубликовано
1 hour ago, Le ecureuil said:

Когда в URL не указано доменное имя как можно понять какой сертификат из хранилища брать для проверки? Если брать тот, что пришел в ответе по TLS - а как доказать что юзер хотел именно этот домен и не происходит MITM?

нам не нужен домен, если мы обращаемся по ip, ip в сертификате фигурирует. так в чём тогда проблема?

DNS Name=dns.google
DNS Name=dns.google.com
DNS Name=*.dns.google.com
DNS Name=8888.google
DNS Name=dns64.dns.google
IP Address=8.8.8.8
IP Address=8.8.4.4
IP Address=2001:4860:4860:0000:0000:0000:0000:8888
IP Address=2001:4860:4860:0000:0000:0000:0000:8844
IP Address=2001:4860:4860:0000:0000:0000:0000:6464
IP Address=2001:4860:4860:0000:0000:0000:0000:0064
 

  • 0
Опубликовано

серьёзно?

DNS Name=cloudflare-dns.com
DNS Name=*.cloudflare-dns.com
DNS Name=one.one.one.one
IP Address=1.1.1.1
IP Address=1.0.0.1
IP Address=162.159.36.1
IP Address=162.159.46.1
IP Address=2606:4700:4700:0000:0000:0000:0000:1111
IP Address=2606:4700:4700:0000:0000:0000:0000:1001
IP Address=2606:4700:4700:0000:0000:0000:0000:0064
IP Address=2606:4700:4700:0000:0000:0000:0000:6400
 

Присоединяйтесь к обсуждению

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

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

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.