Jump to content
  • 2

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


KorDen

Question

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

Link to comment
Share on other sites

Recommended Posts

  • 0
В 12.08.2021 в 01:03, НиколайLT сказал:

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

 

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

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

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

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

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

  • Thanks 1
Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0
46 минут назад, Eugeny Novozhilov сказал:

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

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

Link to comment
Share on other sites

  • 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. нэ?

Edited by pol newman
Link to comment
Share on other sites

  • 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 

Link to comment
Share on other sites

  • 0
3 часа назад, Sim-Sim сказал:

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

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

Link to comment
Share on other sites

  • 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
Link to comment
Share on other sites

  • 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 вопросов не вызывает, а вот те три все-таки не совсем понятно от кого идут.

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

Edited by cheburashkaDNS
Link to comment
Share on other sites

  • 0

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

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

 

Edited by keenet07
Link to comment
Share on other sites

  • 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

  • Thanks 2
  • Upvote 1
Link to comment
Share on other sites

  • 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).

 

Link to comment
Share on other sites

  • 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 сразу ставьте и проверяйте.

Link to comment
Share on other sites

  • 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. Это снимет большую часть вопросов.

Link to comment
Share on other sites

  • 0

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

 

Link to comment
Share on other sites

  • 0
3 часа назад, cheburashkaDNS сказал:

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

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

Link to comment
Share on other sites

  • 0
7 часов назад, cheburashkaDNS сказал:

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

 

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

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

Edited by r13
Link to comment
Share on other sites

  • 0
11 час назад, Sim-Sim сказал:

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

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

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

  • Upvote 1
Link to comment
Share on other sites

  • 0
11 час назад, cheburashkaDNS сказал:

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

 

Только draft и delta.

Link to comment
Share on other sites

  • 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 осуществляться не будут?

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

Link to comment
Share on other sites

  • 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.

  • Upvote 2
Link to comment
Share on other sites

  • 0
44 минуты назад, user404 сказал:

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

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

Link to comment
Share on other sites

  • 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
 

Link to comment
Share on other sites

  • 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
 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...