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

[vasya_petrovich]

Всем привет.

 

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

 

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

 

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

Edited November 21, 2017 by vasya_petrovich

[vlad11]

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

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

[rm_]

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

 

[GrandPr1de]

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

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

Edited November 12, 2017 by GrandPr1de

[Ivan_83]

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

[vasya_petrovich]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

[Ivan_83]

23 минуты назад, vasya_petrovich сказал:

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

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

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

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

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

 

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

[kirush]

В 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

Edited November 21, 2017 by kirush

[vasya_petrovich]

спс, за статейку.

Дядя Ваня83, твои мысли были в верном направлении.

[polmax]

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

[kirush]

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.

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

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

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

Edited November 29, 2017 by kirush

[polmax]

Только что, kirush сказал:

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

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

[kirush]

1 минуту назад, polmax сказал:

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

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

[polmax]

minimal-responses yes; 

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

Edited November 29, 2017 by polmax

[kirush]

1 минуту назад, polmax сказал:

minimal-responses yes; 

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

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

Edited November 29, 2017 by kirush

[polmax]

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

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

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

Edited November 29, 2017 by polmax

[Ivan_83]

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

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

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

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

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

 

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

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

[polmax]

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

[st_re]

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

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

 

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

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

 

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

 

[Kolunchik]

polmax 

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

[polmax]

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 имя можно легко.

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

Edited November 30, 2017 by polmax

[Ivan_83]

13 часов назад, polmax сказал:

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

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

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

[No_name]

Каким образом решена была проблема?

[GrandPr1de]

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

Каким образом решена была проблема?

всю тему слабо прочитать?

[No_name]

23 минуты назад, GrandPr1de сказал:

всю тему слабо прочитать?

Читал всю тему.

Читаю у ТС: "все само собой починилось" это что-ли решение, или решение то, что накидали разношерстные советы?

 

У нас решением, года 2 назад, было отключить PDNSD(потому как напрочь, время от времени не отдавал гугловские адреса) и оставить все на бинде и теперь все прекрасно работает, ни один не жалуется.

Особо плакались клиенты с тплинковским поделием.