Маршрутизация DNS иногда не работает

qmxocynjca · 4 ноября

В роутере (fw 5.0.0) прописан DNS от провайдера (обычный) и от Яндекса (DoT), в списке DNS маршрутизации прописан youtube.com.

Проблема: www.youtube.com не смог зароутиться куда надо. После неудачного роутинга несколько раз делал "nslookup www.youtube.com 192.168.1.1", но результата не дало - роутер упорно вёл по провайдеру.

Пробовал включить dns-proxy debug, после чего роутер почти завис секунд через 30, смог выключить эту настройку только через telnet. Кажется после этого роутинг таки заработал, но легче от этого не стало.

Наблюдения:

* провайдерные DNS возвращают 173.194.221.198 от primary и 64.233.162.198 от secondary на nslookup www.youtube.com.

* nslookup на www.youtube.com возвращает "Tracing route to wide-youtube.l.google.com", а на youtube.com возвращает "Tracing route to youtube.com".

* nslookup www.youtube.com 77.88.8.8 (обычный dns от яндекса) возвращает разные адреса на каждый запрос.

Вот как это примерно выглядит:

C:\Users\user>tracert -d -w 50 www.youtube.com

Tracing route to wide-youtube.l.google.com [173.194.220.198]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms     1 ms  <isp_gw>
^C
C:\Users\user>nslookup www.youtube.com 192.168.1.1
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    wide-youtube.l.google.com
Addresses:  2a00:1450:4010:c1e::c6
          142.251.1.198
Aliases:  www.youtube.com
          youtube-ui.l.google.com


C:\Users\user>tracert -d -w 50 www.youtube.com

Tracing route to wide-youtube.l.google.com [142.251.1.198]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     1 ms    <1 ms  <isp_gw>
^C
  
C:\Users\user>tracert -d -w 50 youtube.com

Tracing route to youtube.com [173.194.221.91]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.88.88
  2    91 ms    89 ms     *     <kvn_gw>

Изменено 4 ноября пользователем qmxocynjca

FLK · 5 ноября

1) провайдерские или любые plain-text dns работать не будут, пока есть хотя бы 1 doh/dot

2) если вы пытаетесь смотреть трубу, вбив только youtube.com скажу сразу - это так не работает...

Изменено 5 ноября пользователем FLK

qmxocynjca · 5 ноября

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

1) провайдерские или любые plain-text dns работать не будут, пока есть хотя бы 1 doh/dot

Про это не знал, спасибо.

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

2) если вы пытаетесь смотреть трубу, вбив только youtube.com скажу сразу - это так не работает...

Да, это понятно, весь список нужных доменов заполнен. Проблема воспроизвелась конкретно с этим хостом, поэтому подробности опустил.

@Le ecureuil я бы рад держать dns-proxy debug включенным, чтобы отловить это, но это не реально - резолвер перестаёт отвечать через какое-то время (минута-две) и в логи начинает слать какое-то слишком низкоуровневое месиво. Сделайте чтобы dns-proxy debug был рабочим на постоянной основе?

Le ecureuil · 5 ноября

Нет, debug он для отладки. Постоянно им пользоваться нельзя.

Если в целом, то все верно - нужно использовать нормальные, "неподмененные" DNS, иначе будет ерунда.

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

qmxocynjca · 5 ноября

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

нужно использовать нормальные, "неподмененные" DNS, иначе будет ерунда.

DoT от Яндекса - это нормальный DNS в этом случае? Не очень понимаю что есть "неподменные". Если речь про "Интернет-фильтры", то ими не пользуюсь, всё руками прописано, никакого adguard и прочего нет в цепочке.

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

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

Это хорошо, будем посмотреть.

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

Нет, debug он для отладки. Постоянно им пользоваться нельзя.

Тут вам видней, конечно, но это не первый раз когда я пробовал dns-proxy debug и все разы получалась какая-то жесть, когда было ощущение что девайс придётся ресетить, ибо всё вставало колом.

Le ecureuil · 6 ноября

18 часов назад, qmxocynjca сказал:

DoT от Яндекса - это нормальный DNS в этом случае?

А сами как думаете, им нужно выполнять требования от РКН?

The answer is blowing in the wind.

qmxocynjca · 6 ноября

15 минут назад, Le ecureuil сказал:

А сами как думаете, им нужно выполнять требования от РКН?

Они же не провайдер. Буду удивлен, если DoT от яндекса как-то аффектится ркн-ом, но не исключаю такого в будущем. Сейчас, по ощущениям, работает вполне адекватно.

semipron · 8 ноября

Такая же фигня.

Заметил сразу по просмотру например твича, ttvnw.net добавлен в маршруты через влесс. Но показывает через раз, то в 1080р, то в 720р(1080р для России недоступен). Так же если трассировку запустить до рандомного юрла из моего списка в маршрутах, то где то идет через влесс, где то нет. Доты 8.8.8.8, 8.8.4.4, 9.9.9.9 прописаны.

Oleg Nekrylov · 12 ноября

Если списков fqdn несколько списков, то на 5.0.0 работает только первый и только по проводному сегменту, по WI-FI не работает (NC-1812/KN-1012/KN-2311) 😔

Denis P · 12 ноября

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

по WI-FI не работает (NC-1812/KN-1012/KN-2311) 😔

этим клиентам точно назначена политика по умолчанию?

Oleg Nekrylov · 12 ноября

В 12.11.2025 в 17:50, Denis P сказал:

этим клиентам точно назначена политика по умолчанию?

Это не клиенты - это роутеры. А других политик и нет, только Политика по умолчанию.

Работает только eesti (wireguard), остальные идут через ISP, несмотря, что явно указан туннель. Флаг Эксклюзивный маршрут влияет только на eesti. На 5.0b2/b3 всё работало, после обновления работает только первый список: выключаем eesti, начинает работать tmdb, выключаем tmdb, начинает работать intel...

Изменено Четверг в 15:12 пользователем Oleg Nekrylov

Denis P · 12 ноября

39 минут назад, Oleg Nekrylov сказал:

Это не клиенты - это роутеры. А других политик и нет, только Политика по умолчанию.

Работает только eesti (wireguard), остальные идут через ISP, несмотря, что явно указан туннель. Флаг Эксклюзивный маршрут влияет только на eesti. На 5.0b2/b3 всё работало, после обновления работает только первый список

Так это вы сейчас про статикроуты, а тема то про новую фичу из 5.0

qmxocynjca · 13 ноября

10 часов назад, Denis P сказал:

Так это вы сейчас про статикроуты, а тема то про новую фичу из 5.0

Да не, видно же что что это списки доменов с вручную заданными именами.

Ждём новую версию прошивки, говорят там что-то должно быть поправлено.

Denis P · 13 ноября

15 часов назад, Oleg Nekrylov сказал:

Это не клиенты - это роутеры

т.е. роутеры пиры должны следовать правилам dns маршрутизации и кинетик выступает в качестве dns сервера на них?
пока что к схеме вопросы возникают)

Oleg Nekrylov · Четверг в 15:20

3 часа назад, Denis P сказал:

т.е. роутеры пиры должны следовать правилам dns маршрутизации и кинетик выступает в качестве dns сервера на них?
пока что к схеме вопросы возникают)

К схеме вопросов нет, если вы конечно сами себе чего-то не понапридумывали.

Клиенты здесь конечные устройства, сидящие за роутерами, а на роутерах несколько каналов и их задача коммутировать их в зависимости от поставленных задач.

18 часов назад, Denis P сказал:

Так это вы сейчас про статикроуты, а тема то про новую фичу из 5.0

Статически маршруты это тоже затрагивает. Через какое-то время они перестают работать:, в web, есть но не работают, сделаешь маршруту выкл/вкл и они на какое-то время опять начинают работать.

Изменено Четверг в 15:21 пользователем Oleg Nekrylov

Denis P · Четверг в 15:41

8 минут назад, Oleg Nekrylov сказал:

К схеме вопросов нет

Как же нет, если вы её не показываете?

qmxocynjca · Суббота в 13:23

К теме топика - на 5.0.1 пока полет нормальный, но заметил странную особенность. Если устройство в политике и делает днс запрос на хост из списка (через резолвер, который используется во всех политиках!), то ipset не наполняется. Зачем это ограничение?

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

Denis P · Суббота в 13:31

6 минут назад, qmxocynjca сказал:

Если устройство в политике и делает днс запрос на хост из списка (через резолвер, который используется во всех политиках!), то ipset не наполняется. Зачем это ограничение?

Потому что в политиках обращение идет не к 53 порту, а заворот на другие, системные порты

qmxocynjca · Воскресенье в 09:05

19 часов назад, Denis P сказал:

Потому что в политиках обращение идет не к 53 порту, а заворот на другие, системные порты

На сколько понимаю, в конечном счете всё попадает в тот же самый системный резолвер, значит технически запросы из политик могут наполнять ipset.

Сейчас если устройство было в политике и походило по доменам из списка, то при смене политики на дефолтную возникает wtf, хотя устройство использует DNS от роутера с единственным апстримом.

Почему этот кейс меня так интересует - есть самописный webui, который позволяет переключать политику на конечном устройстве в один клик с самого устройства без авторизации. Пользоваться очень удобно, но вот этот кейс пока что разваливается.

Denis P · Воскресенье в 13:31

4 часа назад, qmxocynjca сказал:

На сколько понимаю, в конечном счете всё попадает в тот же самый системный резолвер, значит технически запросы из политик могут наполнять ipset.

технически - да, но о подобных ограничениях разработчики упоминали еще в 4.3, когда только часть функционала была реализована

qmxocynjca · Воскресенье в 14:12

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

Тут вопрос - как работает кэширование dns в принципе у Кинетика? Шарится ли кэш между политиками в ситуации с одним dns апстримом? Если шарится, то логично и ipset-ы наполнять по этой же логике.

avn · Воскресенье в 14:50

33 минуты назад, qmxocynjca сказал:

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

Тут вопрос - как работает кэширование dns в принципе у Кинетика? Шарится ли кэш между политиками в ситуации с одним dns апстримом? Если шарится, то логично и ipset-ы наполнять по этой же логике.

Если хотите, что бы DNS-Маршрутизация работала и в политиках, то попробуйте для нее изменить приоритет, путем добавление копии rule. Мне такой тест проводить лениво, но если заработает, можно написать разработчикам.

$ ip rule add from all fwmark 0xffffaaf lookup 4102 pref  8

$ ip rule
0:      from all lookup local
8:      from all fwmark 0xffffaaf lookup 4102
10:     from all fwmark 0xffffa00 lookup main
100:    from all fwmark 0xffffaaa lookup 4096
101:    from all fwmark 0xffffaaa blackhole
102:    from all fwmark 0xffffaab lookup 4098
103:    from all fwmark 0xffffaab blackhole
106:    from all fwmark 0xffffaae lookup 4100
107:    from all fwmark 0xffffaae blackhole
108:    from all fwmark 0xffffaac lookup 4101
109:    from all fwmark 0xffffaac blackhole
110:    from all fwmark 0xffffaaf lookup 4102
111:    from all fwmark 0xffffaaf blackhole
233:    from all fwmark 0x20000000 lookup 233
1152:   from x.x.x.x lookup 16385
2000:   from all lookup 248
32766:  from all lookup main
32767:  from all lookup default

Denis P · Воскресенье в 15:03

12 минут назад, avn сказал:
Если хотите, что бы DNS-Маршрутизация работала и в политиках, то попробуйте для нее изменить приоритет, путем добавление копии rule. Мне такой тест проводить лениво, но если заработает, можно написать разработчикам.
$ ip rule add from all fwmark 0xffffaaf lookup 4102 pref  8

$ ip rule
0:      from all lookup local
8:      from all fwmark 0xffffaaf lookup 4102
10:     from all fwmark 0xffffa00 lookup main
100:    from all fwmark 0xffffaaa lookup 4096
101:    from all fwmark 0xffffaaa blackhole
102:    from all fwmark 0xffffaab lookup 4098
103:    from all fwmark 0xffffaab blackhole
106:    from all fwmark 0xffffaae lookup 4100
107:    from all fwmark 0xffffaae blackhole
108:    from all fwmark 0xffffaac lookup 4101
109:    from all fwmark 0xffffaac blackhole
110:    from all fwmark 0xffffaaf lookup 4102
111:    from all fwmark 0xffffaaf blackhole
233:    from all fwmark 0x20000000 lookup 233
1152:   from x.x.x.x lookup 16385
2000:   from all lookup 248
32766:  from all lookup main
32767:  from all lookup default

не поможет, потому что
-A PREROUTING -m mark --mark 0x0 -j _NDM_DNSRT_PREROUTING_MANGLE
да и метки там динамические с таблицами

Изменено Воскресенье в 15:03 пользователем Denis P

qmxocynjca · Воскресенье в 15:04

12 минут назад, avn сказал:

Если хотите, что бы DNS-Маршрутизация работала и в политиках

Спасибо, но как раз не хочу. Я лишь хочу чтобы dns запросы из политик наполняли ipset, который используется в маршрутизации dns в основной политике.

Alf_massol · Понедельник в 08:45

У меня вообще не маршутизируется по DNS. Записан и по имени и по IP

traceroute -n api.themoviedb.org
traceroute to api.themoviedb.org (65.9.175.91), 30 hops max, 60 byte packets
 1  192.168.1.1  1.630 ms * *
 2  192.168.1.1  3054.966 ms !H  3055.176 ms !H  3055.171 ms !H

А вот если добавить IP-v4 маршрутизацию, то все отлично

Oleg Nekrylov · Понедельник в 11:52

5.0.1 - вообще не работает маршрутизация по fqdn спискам 😡

Пришлось возвращаться на OPKG (IPset4Static), только вот забыл, как посмотреть адрес и порт обратного DNS (чтобы в ADH DHCP-клиенты правильно резолвились)

qmxocynjca · Понедельник в 13:55

@Le ecureuil К первоначальной проблеме: воспроизвелось, но теперь уже на 5.0.1. Трейс по интересующему домену опять не ведёт куда нужно.

Делаю запрос с устройства в дефолтной политике:

nslookup www.youtube.com
Server:  ...
Address:  192.168.1.1

Non-authoritative answer:
Name:    wide-youtube.l.google.com
Addresses:  2a00:1450:4010:c03::c6
          209.85.233.198
Aliases:  www.youtube.com
          youtube-ui.l.google.com

Адрес не появляется в show object-group fqdn для интересующего домена:

"fqdn": "www.youtube.com",
"type": "runtime",
"deadline4": 12779,
"deadline6": 1531545,
"fail-counter4": 0,
"fail-counter6": 0,
"last-external": 88586,
"last-list-changed": 88586,
"parent": "youtube.com",
"ipv4": [
    {
        "address": "74.125.131.198",
        "ttl": 249,
        "last-updated": 79343
    },
    {
        "address": "74.125.205.198",
        "ttl": 162,
        "last-updated": 89695
    },
    {
        "address": "108.177.14.198",
        "ttl": 271,
        "last-updated": 91759
    },
    {
        "address": "142.250.150.198",
        "ttl": 278,
        "last-updated": 94667
    },
    {
        "address": "142.251.1.198",
        "ttl": 260,
        "last-updated": 87750
    },
    {
        "address": "173.194.221.198",
        "ttl": 218,
        "last-updated": 88125
    }
],
"ipv6": [
    {
        "address": "2a00:1450:4010:c02::c6",
        "ttl": 147,
        "last-updated": 46964
    },
    {
        "address": "2a00:1450:4010:c0a::c6",
        "ttl": 285,
        "last-updated": 88109
    },
    {
        "address": "2a00:1450:4010:c0e::c6",
        "ttl": 135,
        "last-updated": 82176
    },
    {
        "address": "2a00:1450:4010:c0f::c6",
        "ttl": 151,
        "last-updated": 91653
    },
    {
        "address": "2a00:1450:4010:c1c::c6",
        "ttl": 250,
        "last-updated": 94667
    },
    {
        "address": "2a00:1450:4010:c1e::c6",
        "ttl": 206,
        "last-updated": 87773
    }
]

dot прокси на роутере отвечает нормально:

В конфиге ndnproxy:
dns_server = 127.0.0.1:40500 . # 77.88.8.8:853@common.dot.dns.yandex.net

$ nslookup www.youtube.com 127.0.0.1:40500
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      www.youtube.com
Address 1: 209.85.233.198 lr-in-f198.1e100.net
Address 2: 2a00:1450:4010:c03::c6 lr-in-f198.1e100.net

Другие адреса добавились, а этот не хочет. Что примечательно, ipv6 адрес тоже отсутствует в списке.

mrGhotius · Понедельник в 18:07

9 часов назад, Alf_massol сказал:

У меня вообще не маршутизируется по DNS. Записан и по имени и по IP

6 часов назад, Oleg Nekrylov сказал:

5.0.1 - вообще не работает маршрутизация по fqdn спискам

Не знаю что вы настраиваете не так, но у меня все работает. Как ipv4, так и ipv6.

Racer X · Понедельник в 18:48

6 часов назад, Oleg Nekrylov сказал:

5.0.1 - вообще не работает маршрутизация по fqdn спискам

KN-11011, KN-3810 все работает. Не идеально, с багами, но работает не хуже чем раньше.
Никаких разговоров о "вообще не работает".

spatiumstas · Понедельник в 21:53

5.0.1 - работает 3-4 часа и хаотично начинает делать пропуски. Эксклюзивный маршрут игнорируется - трафик идёт в провайдера, через минут 5 нормализуется и снова в туннель. ~~Снять логи проблематично, в момент запуска debug все начинает маршрутизироваться как и должно~~

Изменено вчера в 07:41 пользователем spatiumstas

Racer X · Понедельник в 22:26

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

5.0.1 - работает 3-4 часа и хаотично начинает делать пропуски.

Да, так и есть. Я бы сказал что заметно чаще 3-4 часов. Скорее раз в час, если не чаще. Затык и трафик в провайдера. Продолжается 1-2 мин и потом все опять работает нормально.
И могу точно сказать что это не тоннель у меня периодически отваливается. Потому что если с этим же тоннелем возвращаюсь на классический IP роутинг по подсетям, то все работает железобетонно.

Я это все наблюдаю еще с первых бет 5 версии и пока изменений такого поведения не вижу вплоть до 5.0.1.

Изменено Понедельник в 23:21 пользователем Racer X

Маршрутизация DNS иногда не работает

Вопрос

32 ответа на этот вопрос

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

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

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

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