Перейти к содержимому
Калькуляторы

[РЕШЕНО] Не резолвятся нормально алиасы на роутерах

Всем привет.

 

Возникла какая-то странная проблема на клиентской стороне резолвингом.
У абонента стоит роутер тплинк, в нем прописан наш ДНС.
При попытке резолва адреса android.clients.google.com на стороне клиента, через мой днс все отлично резолвится и возвращается список IP адресов.
Когда же я пытаюсь зарезолвить этот же домен через ДНС роутера (192.168.1.1), то получаю фигу с маслом, т.е. ничего не резолвится.
Если прописать гугловый ДНС 8.8.8.8 на роутере, то все прекрасно работает и резолвится.

 

Стал копать по проблеме и выяснил, что при резолве android.clients.google.com возвращается алиас на android.l.google.com.
Рекурсия на моей стороне включена.

 

Что роутеровскому ДНС может не нравиться в моих ответах ДНС?
P.S.> другие домены резолвятся нормально, проблема именно с доменами, которые возвращают алиас.

Изменено пользователем vasya_petrovich

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Смотреть в hosts роутера и клиента.

Затем на тип раздачи ДНС в DHCP в роутере.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
47 минут назад, vasya_petrovich сказал:

P.S.> другие домены резолвятся нормально, проблема именно с доменами, которые возвращают алиас.

Что, прям любой альяс, или всё-таки конкретно этот?

Если проверить www.microsoft.com (там вообще ад), как с ним?

$ host www.microsoft.com
www.microsoft.com is an alias for www.microsoft.com-c-2.edgekey.net.
www.microsoft.com-c-2.edgekey.net is an alias for www.microsoft.com-c-2.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-2.edgekey.net.globalredir.akadns.net is an alias for e1863.dspb.akamaiedge.net.
e1863.dspb.akamaiedge.net has address 184.24.199.187
e1863.dspb.akamaiedge.net has IPv6 address 2a02:26f0:2d:487::747
e1863.dspb.akamaiedge.net has IPv6 address 2a02:26f0:2d:481::747

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

смешно но... пробовали роутер до последней прошивки обновлять?

и почему-то ничего умнее чем "нюхать" трафик каким-нибудь wireshark-ом я придумать не могу.

Изменено пользователем GrandPr1de

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Размер ответа днс от твоего сервера получается больше мту и роутер фейлит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, vlad11 сказал:

Смотреть в hosts роутера и клиента.

Затем на тип раздачи ДНС в DHCP в роутере.

Там все нормально с хостс, проблема не только у одного клиента, а у нескольких.

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

Что, прям любой альяс, или всё-таки конкретно этот?

Если проверить www.microsoft.com (там вообще ад), как с ним?

Ммм, возможно и не любой алиас.
С микрософтом все ок.

2 часа назад, GrandPr1de сказал:

смешно но... пробовали роутер до последней прошивки обновлять?

и почему-то ничего умнее чем "нюхать" трафик каким-нибудь wireshark-ом я придумать не могу.

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

2 часа назад, Ivan_83 сказал:

Размер ответа днс от твоего сервера получается больше мту и роутер фейлит.

Это мало вероятно, у нас доступ по IPoE, и тогда не только бы гугл криво резолвился.


Пока писал ответы, обнаружил, что все само собой починилось...
Пока буду наблюдать, если у кого-то есть еще рекомендации, отписывайтесь, буду рад :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
23 минуты назад, vasya_petrovich сказал:

Это мало вероятно, у нас доступ по IPoE, и тогда не только бы гугл криво резолвился.

А ты и так не знаешь что криво резолвится и почему.

IPoE тут вообще никаким боком.

Гугел на своём долбаном 8.8.8.8 выдаёт сильно пострипанный ответ, там только необходимый минимум. Твой днс сервер скорее всего туда вываливает всё что есть. Отсюда и разница.

В unbound вроде была крутилка для минимизации размера ответа, ищи у себя такую же.

 

Ещё можешь поискать тут тему где было о том, что роутеры некоторые чувствительны к регистру букв в ответе, поэтому если первый запросит MaIL.ru то остальные получат в ответ на запрос mail.ru - MaIL.ru, и дропнут такой ответ. Кажется бинд этой хернёй страдал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 13.11.2017 в 04:15, Ivan_83 сказал:

А ты и так не знаешь что криво резолвится и почему.

IPoE тут вообще никаким боком.

Гугел на своём долбаном 8.8.8.8 выдаёт сильно пострипанный ответ, там только необходимый минимум. Твой днс сервер скорее всего туда вываливает всё что есть. Отсюда и разница.

В unbound вроде была крутилка для минимизации размера ответа, ищи у себя такую же.

 

Ещё можешь поискать тут тему где было о том, что роутеры некоторые чувствительны к регистру букв в ответе, поэтому если первый запросит MaIL.ru то остальные получат в ответ на запрос mail.ru - MaIL.ru, и дропнут такой ответ. Кажется бинд этой хернёй страдал.

накидал о своем опыте сегодня http://telegra.ph/Pochemu-ne-rabotaet-Play-Market-na-nekotoryh-modelyah-TPLINK-11-20

Изменено пользователем kirush

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kirush держите в курсе решения вопроса через поддержку TP-Link, ибо тоже недавно столкнулись с такой проблемой, видать гугл добавил новых пару записей, проблема началась где то после 13 ноября.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
12 минут назад, polmax сказал:

kirush держите в курсе решения вопроса через поддержку TP-Link, ибо тоже недавно столкнулись с такой проблемой, видать гугл добавил новых пару записей, проблема началась где то после 13 ноября.

TPLINK:

Цитата

У вас ipoe подключение? Какой размер MTU у вас на брасах используется? Меньше 1500? Если да, то почему, можно узнать?
Подобные проблемы возникают, когда оператор со своей стороны ограничивает размер MTU на своих узлах маршрутизации ниже стандартного 1500 а mtu blackhole не на всех аппаратных версиях реализовано.  
Про какие именно исправления вы пишете тут http://telegra.ph/Pochemu-ne-rabotaet-Play-Market-na-nekotoryh-modelyah-TPLINK-11-20 - не совсем понятно. Вендор тут совершенно не виноват - нужно либо оператору двигаться в сторону повышения клиентоориентированности с учётом заводских настроек клиентского оборудования, либо на уровне инструкций указывать, что для специфического провайдера требуется понижать MTU до 1450
IPoE по всей РФ используется довольно обширно, многие операторы это используют и никаких проблем не возникает как правило. У меня например провайдер Онлайм, IpoE , динамика , MTU 1500 на 841 v7 , v13 - никаких проблем с 2013 года по сей день.

Я:

Цитата

 

В сети используем: PPTP/PPPoE и ipoe - проблема изучалась на том образце который попал мне в руки, на нем PPPoE было настроено.

Сейчас проблема устранена, путем урезания доп. информации от ДНС.

 

Для pptp и pppoe выдаем:

set iface mtu 1492

set link mtu 1492

set link mru 1492

 

----

После того как выдал настройки mpd написал про PPPoE/PPTP сказали попробовать поменять MTU.

а потом поинтересовались:

"Нам очень важно узнать Ваше мнение о нашем сервисе технической поддержки. Пожалуйста, пройдите небольшой опрос для улучшения качества нашей работы".

на этом все, я так понимаю заявку закрыли. Ссылку на эту ветку я им давал. Жалко ;(
 

Изменено пользователем kirush

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Только что, kirush сказал:

TPLINK предложил с MTU поиграться.

Только я так понимаю мту это затрагивает пакеты которые проходят через роутер, а не предназначенные роутеру, ибо проблема когда роутер выступает DNS сервером, если указать сервер DNS например свой (провайдера) на прямую на клиенте (или выдавать его через DHCP), то пакеты без "minimal-responses yes;" норм начинают бегать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, polmax сказал:

Только я так понимаю мту это затрагивает пакеты которые проходят через роутер, а не предназначенные роутеру, ибо проблема когда роутер выступает DNS сервером, если указать сервер DNS например свой (провайдера) на прямую на клиенте (или выдавать его через DHCP), то пакеты без "minimal-responses yes;" норм начинают бегать.

Можете попробовать с ними пободаться дальше. Сошлитесь на Ticket №10264340 и данную ветку форума. Может у Вас чего выйдет объяснить им ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

minimal-responses yes; 

Это временно решение, добавит гугл ещё пару записей и МТУ (размер пакета) станет выше 1500 и всё, проблему уже не решить этим параметром, если только каким то образом выдавать своим днс не все записи, а например всего 5.

Изменено пользователем polmax

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, polmax сказал:

minimal-responses yes; 

Это временно решение, добавил гугл ещё пару записей и МТУ станет выше 1500 и всё, проблему уже не решить этим параметром, если только каким то образом выдавать своим днс не все записи а например всего 5.

Да придется резать - или искать параметр в bind или уходить на unbound, там вроде это есть.

Изменено пользователем kirush

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, kirush сказал:

У меня например провайдер Онлайм, IpoE , динамика , MTU 1500 на 841 v7 , v13 - никаких проблем с 2013 года по сей день

Дак и не было никаких проблем, пока пакет пролазил, а сейчас очень много обращений пользователей у разных провайдеров именно с роутерами TP-Link + приложения на андроиде гугл Маркет, Youtube и проблема у всех одна: выдаёт ошибку что нет связи. Всех проблемных клиентов объединяет роутер TP-Link причём разных марок, MTU у всех клиентов разные и разные способы подключения (IPoE, PPTP), причём у тех у кого MTU 1500, проблема тоже есть.

Изменено пользователем polmax

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы бы хоть документацию почитали сначала на dnsmasq ибо он во всех мыльницах стоит, а потом на свой днс сервер на предмет того что minimal-responses yes; делает и как, а то гадаете тут как последние хомячки.

(я вот припоминаю что можно лимитировать размер ответа на днс сервере, и он просто будет выкидывать что не влезло, и пофик что дудль/мс написало 100500 записей).

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

Заодно можно из глючной мыльницы вытащить конфиг днс маска и поиграться на своём х86 стенде.


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

 

Видимо вам разбираться некогда, хуяк-хуяк и вроде работает в продакшене.

Какой то не инженерский подход, стыдно должно быть интернетом торговать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ivan_83 как всегда в своём репертуаре, лишь бы всех говном полить. Раз такой спец подсказал бы как порезать на unbound и bind ответ так чтобы пролезал на мыльницах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В общем случае - никак :)

Вполне легитимный ответ, без дополнительной информации может быть длинне 1500 байт. клиент (в вашем случае ТПлинк) должен свичнуться на tcp, если получил неполнй пакет. Если они не умеют (ну в приницпе dnsmasq умел, но что там нарожали авторы из ТПЛинка... знают они или можно вытянуть конфиг из прошивки и почитать.) то проблемы с ресолвом там-сям будут.

 

Ну и таки совет вроде дали options(minimal-responses yes;); для бинда или minimal-responses: yes для unbound

но это оттянет проблему, отрезав доп. поля в ответе, а не решит. Написать 1000 А записей на 1 имя можно легко. Оно не влезет в UDP пакет. инфа 146%

 

Кроме того оно сломает у клиента DNSSEC, если тот попробует включть его проверку у себя. т.к. подписи тоже тогось... отрежет.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
54 минуты назад, Kolunchik сказал:

polmax

max-udp-size не пробовали на бинде крутить?

Конечно пробовал, при превышении этого параметра, пакет начинает бегать по tcp, вместо udp. При первом запросе если пакет превышает параметр указаный в max-udp-size, возвращает клиенту: Message is truncated, клиент пытается уже получить данные по tcp, а TP-Link походу этого уже не умеет.

 

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

клиент (в вашем случае ТПлинк) должен свичнуться на tcp

Судя по tcpdump, клиент на андроиде делает тоже самое, он делает запрос у TP-Link по udp, ничего от него не получает, потом пытается послать запрос по tcp, а TP-Link уже походу этого не умеет и всё приехали.

 

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

но это оттянет проблему, отрезав доп. поля в ответе, а не решит. Написать 1000 А записей на 1 имя можно легко.

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

Изменено пользователем polmax

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
13 часов назад, polmax сказал:

как всегда в своём репертуаре, лишь бы всех говном полить. Раз такой спец подсказал бы как порезать на unbound и bind ответ так чтобы пролезал на мыльницах.

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

Времени и мотивации заниматься этим самому у меня нет совсем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас