Баг в логике маршрутов запросов к DNS в KeeneticOS 5.1.5

[Dalex]

В KeeneticOS при включенном публичном DNS типа Cloudflare etc. есть две сущности, отрабатывающие DNS запросы:

1. ndnproxy, принимающий запросы на порт 53.

2. stubby, принимающий запросы на порт 40300.

И они с собой явно не дружат.

Ситуация первая - включаем "Игнорировать DNS провайдера".
В этом случае ndnproxy (в Entware проверял) перестанет отвечать на DNS запросы и часть KeeneticOS перестанет корректно получать ответы на DNS запросы.
Например, wireguard соединение к серверу по DNS имени не сможет подняться, несмотря на то, что публичный DNS то настроен и отвечает на 40300.
Если изменить DNS имя в настройках соединения на ip адрес, поднимется.

Ситуация вторая - "Маршруты DNS".
Тут логика такая - 
1. Пользователь делает DNS запрос и получает на него ответ от публичного DNS сервера (stubby?).
2. А вот KeeneticOS добавляет в группу fqdn ip (show object-group fqdn) адреса от ndnproxy и уже совсем другие адреса, потому что ndnproxy работает только с выключенной галкой "Игнорировать DNS провайдера" и отсылает запросы только на DNS сервер провайдера, публичный DNS он игнорирует от слова совсем.
(есть кстати вопрос -  а куда пойдет роутер, чтобы отресольвить dns.cloudflare.com, чтобы заработал публичный DNS - если провайдерские DNS игнорируются ?)

В результате имеем две сущности:
- ndnproxy, который всегда идет на DNS провайдера, игнорируя, что в KeeneticOS есть выбранный пользователем публичный DNS,
- stubby, который может отдать с публичного DNS ответы пользвателям в локалке, но не может отвечать на внутренние запросы от процессов в KeeneticOS.

Вот пример  (ну да я их делал в Entware, но 1. с отключенным Entware ситуация не меняется, 2. проблема воспроизводится на другом устройстве без OPKG) - 4 запроса www.goodreads.com. К провайдеру, к ndnproxy (53 порт), к stubby (порт 40300) и к Яндекс DNS.
И так со всеми запросами, которые имеют геораспределение\множественные записи DNS. 

Цитата

 

Edited September 14 by Dalex

[Denis P]

2 минуты назад, Dalex сказал:

Ситуация первая - включаем "Игнорировать DNS провайдера".
В этом случае 53 порт перестанет отвечать на DNS запросы и часть системы перестанет получать ответы на DNS запросы.

не правда.

3 минуты назад, Dalex сказал:

А вот KeeneticOS добавляет в группу fqdn ip адреса от ndnproxy и уже совсем другие адреса, потому что ndnproxy работает только с выключенной галкой "Игнорировать DNS провайдера" и отсылает запросы только на DNS сервер провайдера, публичный DNS он игнорирует от слова совсем.

и тоже мимо.

[Dalex]

3 минуты назад, Denis P сказал:

не правда.

Я могу продемонстрировать все, что описано мной выше. Я конечно буду рад ошибиться, но пока все выглядит именно так.

[Dalex]

Вот скриншот 2 запросов с моей ультры.

Разница между первым и вторым, что перед вторым я сделал следующие действия:
1. Зашел в настройки L2TP соединения к провайдеру и выбрал "Игнорировать DNSv4 Интернет-провайдера".
2. Отключил и заново включил это соединение.

 

Цитата

 

Edited September 14 by Dalex

[Denis P]

50 минут назад, Dalex сказал:

Вот скриншот 2 запросов с моей ультры.

Разница между первым и вторым, что перед вторым я сделал следующие действия:
1. Зашел в настройки L2TP соединения к провайдеру и выбрал "Игнорировать DNSv4 Интернет-провайдера".
2. Отключил и заново включил это соединение.

 

 

ну вы эт самое, plaintext днсы то верните любые, не обязательно провайдерские.
у вас не работает потому что в resolv.conf пусто

Edited September 14 by Denis P

[Mamay]

3 минуты назад, Denis P сказал:

у вас не работает потому что в resolv.conf пусто

Он художник. Он так видит.

[Dalex]

45 минут назад, Denis P сказал:

ну вы эт самое, plaintext днсы то верните любые, не обязательно провайдерские.
у вас не работает потому что в resolv.conf пусто

Я не хотел бы сейчас спрашивать -  зачем я должен это делать, если включен публичный DNS. Давайте пока этот вопрос отложим, хотя спасибо, что подтвердили, что проблема существует.

Самый важный вопрос - это то, что пользователям Кинетик отдает DNS ответ от публичного DNS, а сам внутри забирает совсем другие ip адреса из "plaintext dns" и добавляет уже их в "Маршруты DNS".
Вы написали, что это не так.
Вот вам подтверждение.
"Включены" plaintext dns провайдера и публичный DNS quad9.
На скриншотах - два DNS запроса - на кинетик и на 9.9.9.9 и вывод "show object-group fqdn".
Как видите - в списке не появились ip адреса " 18.64.211", которые отдал Кинетик\quad9, но появились ip адреса 18.165.122, которые упорно отдает только провайдерский DNS.
 

Цитата

 

Edited September 14 by Dalex

[Denis P]

55 минут назад, Dalex сказал:

Я не хотел бы сейчас спрашивать -  зачем я должен это делать, если включен публичный DNS. Давайте пока этот вопрос отложим, хотя спасибо, что подтвердили, что проблема существует.

Самый важный вопрос - это то, что пользователям Кинетик отдает DNS ответ от публичного DNS, а сам внутри забирает совсем другие ip адреса из "plaintext dns" и добавляет уже их в "Маршруты DNS".
Вы написали, что это не так.
Вот вам подтверждение.
"Включены" plaintext dns провайдера и публичный DNS quad9.
На скриншотах - два DNS запроса - на кинетик и на 9.9.9.9 и вывод "show object-group fqdn".
Как видите - в списке не появились ip адреса " 18.64.211", которые отдал Кинетик\quad9, но появились ip адреса 18.165.122, которые упорно отдает только провайдерский DNS.
 

 

нет проблемы, вы проверяете с самого роутера, более того не из ndm, что не является стандартным сценарием.
У клиентов всё будут работать если нет plaintext dns, в том числе и наполнение object group наборов

Edited September 14 by Denis P

[Denis P]

56 минут назад, Dalex сказал:

Вот вам подтверждение.
"Включены" plaintext dns провайдера и публичный DNS quad9.

учитывая что провайдет отвечает быстрее чем quad - вполне ожидаемо

[Dalex]

8 минут назад, Denis P сказал:

нет проблемы, вы проверяете с самого роутера, более того не из ndm, что не является стандартным сценарием.
У клиентов всё будут работать если нет plaintext dns, в том числе и наполнение object group наборов

Я проверяю с ноутбука обычного пользователя, подключенного по WIFI.

Вы сами подтверждаете что есть проблема - "учитывая что провайдет отвечает быстрее чем quad - вполне ожидаемо".

Это баг -  и вы исправите со временем, или не баг и какая-то последовательность действий по настройке в 5.1.5 есть?

 

Edited September 14 by Dalex

[Denis P]

14 минут назад, Dalex сказал:

Я проверяю с ноутбука обычного пользователя, подключенного по WIFI.

в первом посте были проверки из opkg, дальше перескочили уже к fqdn и клиентам, очень непоследовательные претензии
 

14 минут назад, Dalex сказал:

Вы сами подтверждаете что есть проблема - "учитывая что провайдет отвечает быстрее чем quad - вполне ожидаемо".

каким боком это проблема?

14 минут назад, Dalex сказал:

и вы исправите со временем

я? конечно нет. потому что никакого отношения к ООО Неткрейз не имею

 

Edited September 14 by Denis P

[vincome]

13 минут назад, Dalex сказал:

или не баг и какая-то последовательность действий по настройке в 5.1.5 есть?

Не баг, а штатное задокументированное поведение. В системном профиле днс обязательно должны быть. Не шифрованные серверы. Ядро роутера для резолва системных адресов (адрес впн это тоже системный) идеет только через обычные днс. Если вы убираете все нешифрованные, то начинаются проблемы.

 

Также при работе днс в расчет берется наиболее быстрый днс сервер.это везде так. 

[Dalex]

22 минуты назад, Denis P сказал:

каким боком это проблема?

"Маршруты DNS" работают со сбоями, так как в группу, которая маршрутизирует домен в конкретный интерфейс, часто попадают ip адреса, отличающиеся от тех, которые кинетик же в той же самой итерации отдает пользователю. 

Один запрос к одному домену от одного пользователя - > разные адреса в кеше DNS клиента пользователя и в соответствующей группе fqdn, отвечающей за маршрутизацию по маршрутам DNS -> кинетик отправляет пакеты в маршрут по умолчанию, ведь адрес то другой. А должен корректно разрезольвить и отправить их в выбранный  в настройках маршрут.

Засим все, возможно кто-то из "имеющих отношения к ООО Неткрейз" обратит внимание на этот топик.

Edited September 14 by Dalex

[Denis P]

2 минуты назад, Dalex сказал:

"Маршруты DNS" работают со сбоями, так как в группу, которая маршрутизирует домен в конкретный интерфейс, часто попадают ip адреса, отличающиеся от тех, которые кинетик же в той же самой итерации отдает пользователю. 

Один запрос к одному домену от одного пользователя - > разные адреса в кеше DNS клиента пользователя и в соответствующей группе fqdn -> кинетик отправляет пакеты в маршрут по умолчанию, ведь адрес то другой. А должен корректно разрезольвить и отправить их в выбранный  в настройках маршрут.

Засим все, возможно кто-то из "имеющих отношения к ООО Неткрейз" обратит внимание на этот топик.

и это всё тоже ожидаемое поведение, о котором было сказано неоднократно. После первого запроса клиента роутер по истечению ttl сам продолжает наполнять списки (т.е происходит авторезолв) по этому они и могут отличаться от тех что получил клиент напрямую обратившись к резолверу, минуя роутер, что вы и показываете на одном из скриншотов

[Dalex]

Возможно кому-то пригодится и будет неприятным открытием, как для меня.
Публичные DNS-резольверы, настраиваемые в веб - интерфейсе в разделе Интернет-фильтры, работают не в 100% случаев.
Keenetic нужен не шифрованный plain-text dns, чтобы работать, а им обычно по умолчанию является DNS сервер провайдера (получается от провайдера и находится рядом - в Настройка DNS).
И вот тут и начинается проблема - Keenetic использует и его для своих запросов и в результате "подмешивает" данные не только от выбранного публичного DNS-резольвера, но и от провайдерского. Это в том числе ломает и "Маршруты DNS" (в группу, отвечающую за маршрутизацию попадают совсем другие ip адреса, а не те, что получил клиент).
Поэтому сейчас единственным решением, позволяющим в 100% случаев использовать публичный DNS-резольвер, является следующий ход (Публичный DNS-резольвер в разделе Интернет-фильтры конечно нужно выключить).
1. Добавить в "Настройка DNS" plain-text dns сервер для всех доменов от выбранного вами и не заблокированного публичного DNS-резольвера, например 8.8.8.8.
Выбрать в настройках подключения к Интернет галку "Игнорировать DNSv4 интернет провайдера".
3. Добавить в "Настройка DNS" DoT\DoH\оба dns сервер для всех доменов от выбранного вами и не заблокированного публичного DNS-резольвера, например dns.google.com.

4. Отключить транзит запросов в "Настройка DNS" для вашего профиля.

Edited September 26 by Dalex

[Denis P]

1 час назад, Dalex сказал:

Возможно кому-то пригодится и будет неприятным открытием, как для меня.
Публичные DNS-резольверы, настраиваемые в веб - интерфейсе в разделе Интернет-фильтры, работают не в 100% случаев.
Keenetic нужен не шифрованный plain-text dns, чтобы работать, а им обычно по умолчанию является DNS сервер провайдера (получается от провайдера и находится рядом - в Настройка DNS).
И вот тут и начинается проблема - Keenetic использует и его для своих запросов и в результате "подмешивает" данные не только от выбранного публичного DNS-резольвера, но и от провайдерского. Это в том числе ломает и "Маршруты DNS" (в группу, отвечающую за маршрутизацию попадают совсем другие ip адреса, а не те, что получил клиент).
Поэтому сейчас единственным решением, позволяющим в 100% случаев использовать публичный DNS-резольвер, является следующий ход (Публичный DNS-резольвер в разделе Интернет-фильтры конечно нужно выключить).
1. Добавить в "Настройка DNS" plain-text dns сервер для всех доменов от выбранного вами и не заблокированного публичного DNS-резольвера, например 8.8.8.8.
Выбрать в настройках подключения к Интернет галку "Игнорировать DNSv4 интернет провайдера".
3. Добавить в "Настройка DNS" DoT\DoH\оба dns сервер для всех доменов от выбранного вами и не заблокированного публичного DNS-резольвера, например dns.google.com.

Осмыслили написанное тут? Славно)