Баг в логике маршрутов запросов к 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. 

Цитата

 

Изменено 3 часа назад пользователем 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. Отключил и заново включил это соединение.

 

Цитата

 

Изменено 3 часа назад пользователем Dalex

[Denis P]

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

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

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

 

 

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

Изменено 2 часа назад пользователем 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.
 

Цитата

 

Изменено 2 часа назад пользователем 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 наборов

Изменено 1 час назад пользователем 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 есть?

 

Изменено 1 час назад пользователем Dalex

[Denis P]

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

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

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

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

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

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

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

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

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

 

Изменено 55 минут назад пользователем Denis P

[vincome]

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

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

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

 

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

[Dalex]

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

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

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

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

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

Изменено 32 минуты назад пользователем Dalex

[Denis P]

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

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

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

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

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