Настройка 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?

[Le ecureuil]

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

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

 

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

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

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

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

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

[Eugeny Novozhilov]

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

[r13]

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

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

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

[pol newman]

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 September 15, 2021 by pol newman

[Sim-Sim]

В 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 

[BABUT]

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

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

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

[Sim-Sim]

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

[cheburashkaDNS]

В 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 September 16, 2021 by cheburashkaDNS

[cheburashkaDNS]

 

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

 

[keenet07]

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

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

 

Edited September 17, 2021 by keenet07

[Le ecureuil]

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

[cheburashkaDNS]

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

 

[Le ecureuil]

19 минут назад, cheburashkaDNS сказал:

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

 

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

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

[Sim-Sim]

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

[cheburashkaDNS]

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

 

[Mamay]

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

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

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

[r13]

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

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

 

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

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

Edited September 18, 2021 by r13

[Le ecureuil]

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

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

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

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

[Le ecureuil]

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

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

 

Только draft и delta.

[НиколайLT]

Стоит ли впадать в панику?

https://ibb.co/3p62MKp

 

[cheburashkaDNS]

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

[user404]

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

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

[Le ecureuil]

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

[user404]

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

[r777ay]

1 час назад, Le ecureuil сказал:

В 3.8 поведение выровнено

Поскорее бы, очень пощупать хочется 🙂

[Le ecureuil]

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

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

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

[user404]

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
 

[Le ecureuil]

Конкретно с 8.8.8.8 наверное все прокатит, но не везде есть жестко вшитые в сертификат адреса, это скорее даже исключение.

[user404]

серьёзно?

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
 

[Le ecureuil]

Хм, это кстати новость хорошая. Еще в 2018, когда только начинал делать DoT / DoH, такого не было.

Тогда пользуйтесь IP-адресами, разрешаю.