Bitcomet tracker connection error dns resolve failed

Ошибка «Не удается преобразовать DNS-адрес сервера»

В этой статье я расскажу о решениях, которые помогут избавится от сообщения «Ошибка 105 (net::ERR_NAME_NOT_RESOLVED): Не удается преобразовать DNS-адрес сервера» при попытке перейти на какой-то сайт. В зависимости от браузера, ошибка может немного отличатся. Но суть проблемы и решения будут одинаковые. А проблема в том, что в браузере не открывается ни один сайт, или большинство сайтов. При этом, некоторые программы могут выходить в интернет.

Чаще всего, эта ошибка появляется на каком-то одном компьютере. И если у вас интернет через Wi-Fi роутер, то на других устройствах все может отлично работать. Причиной появления сообщения «Не удается преобразовать DNS-адрес сервера» может быть изменение сетевых параметров, как самим пользователем, так и какой-то программой. Не редко антивирусы могут вызывать эту ошибку. Точно так же, как и вирусы и вредоносные программы. Еще заметил, что многие сталкиваются с этой проблемой в играх ВКонтакте. В любом случае, сейчас все исправим. Решения подойдут для Windows 10, Windows 8 и Windows 7.

Рекомендую в первую очередь выполнить несколько простых действий и проверок:

• В том случае, если у вас интернет подключен через маршрутизатор, нужно его перезагрузить. Просто отключите питание и включите его через минуту.
• Если к маршрутизатору подключены другие устройства, то проверьте, не появляется ли на них сообщение «Не удается преобразовать DNS-адрес сервера» при открытии сайта в браузере. Если ошибка на всех устройствах, то проблема скорее всего у интернет-провайдера. Всегда можно позвонить в поддержку и спросить. Может быть что-то с Wi-Fi роутером.
• Возможно, интернет к вашему компьютеру подключен напрямую. Можете зайти в «Сетевые подключения», отключить и обратно включить адаптер «Сетевое подключение», или «Ethernet» (в Windows 10).

Сразу скажу, что по моим наблюдениям, самое рабочее решение, это смена DNS на Google Public DNS. Так же часто помогает сброс настроек сети. Подробнее об этом читайте дальше в статье.

Меняем DNS для решения ошибки с преобразованием DNS-адресов

Нам нужно открыть свойства протокола IPv4 подключения к интернету и прописать статические адреса.

Зайдите в «Сетевые подключения». Это можно сделать выполнив команду ncpa.cpl (в окне «Выполнить», которое можно вызвать сочетанием клавиш Win + R) , или так, как на скриншоте ниже.

Дальше нужно открыть свойства того подключения, через которое вы подключаетесь к интернету. Это может быть «Сетевое подключение», «Ethernet», «Беспроводное подключение», высокоскоростное, или с названием вашего провайдера.

Дальше выделяем «IP версии 4 (TCP/IPv4)» и нажимаем кнопку «Свойства». Приписываем DNS:

Если сразу ошибка не исчезнет, то перезагрузите компьютер.

Возможно, у вас там уже были прописаны какие-то цифры. В таком случае, попробуйте установить автоматическое получение DNS.

Сброс параметров сети и кэша DNS

Если у вас Windows 10, то все можно сделать через настройки, по инструкции: сброс настроек сети в Windows 10. Но можете использовать способ описанный ниже.

В Windows 8 и Windows 7 нужно выполнить несколько команд в командной строке запущенной от имени администратора.

Сначала сделайте сброс кэша DNS, выполнив команду:

Если это не поможет, то по очереди выполните следующие команды:

После этого перезагрузите компьютер.

Служба «DNS-клиент» и проблема с преобразованием DNS-адресов сервера

Нужно проверить, работает ли служба «DNS-клиент». Честно говоря, я еще не видел случая, чтобы данная ошибка появлялась именно из-за этой службы. Но, если ее остановить, то так и будет. Поэтому, нужно ее проверить.

Службы проще всего открыть командой compmgmt.msc. Нажмите клавиши Win + R, введите команду и нажмите Ok.

Дальше находим службу «DNS-клиент» и открываем ее свойства.

Тип запуска должен быть «Автоматически», и служба должна выполнятся.

Скорее всего у вас служба была запущена.

Антивирусы и вирусы

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

Что касается антивируса, то вы можете временно отключить его, и проверить загрузку страниц в браузере.

Если ни один из вышеописанных способов не помог исправить ошибку, то вполне возможно, что она появилась из-за вируса. Запустите проверку компьютера антивирусом, который установлен на вашем компьютере. Если он установлен. Так же, можно использовать бесплатные антивирусные утилиты. Например: Dr.Web CureIt!, Kaspersky Virus Removal Tool и другие.

Думаю, я смог ответить на ваш вопрос «как исправить ошибку с преобразованием DNS-адресов», и ваши любимые сайты начали открываться, Ютуб воспроизводит видео, а игры ВКонтакте заработали. Всего хорошего!

Источник

Tracker connection error dns resolve failed

Thu Jan 05, 2012 8:25 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 9:59 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:03 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:25 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:26 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:31 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:33 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:40 am

mikrotik : ip dns print:

[admin@BMCHS] > ip dns print
primary-dns: 195.112.195.34
secondary-dns: 192.168.2.200
allow-remote-requests: yes
max-udp-packet-size: 512
cache-size: 50000KiB
cache-max-ttl: 1w
cache-used: 15KiB

ip dhcp-server lease print:

[admin@BMCHS] > ip dhcp-server lease print
Flags: X — disabled, R — radius, D — dynamic, B — blocked
# ADDRESS MAC-ADDRESS HOS. SERVER RAT. STATUS

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:42 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 10:46 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 11:02 am

Re: «DNS resolving failed» error

Thu Jan 05, 2012 11:02 am

Re: «DNS resolving failed» error

Mon Jan 16, 2012 8:51 am

I added the ip of mikrotik to the dns server which is a windows server 2003

but should i put mikrotik in the domain
i mean should i change the name of mikrotik to become
mikrotik.domain.com
if so,how to do it?
how to let mikrotik see the domain?
i need help here because everything should work well but i m still facing the dns resolving failed error
thank you anyway

Re: «DNS resolving failed» error

Mon Jan 16, 2012 9:53 am

Re: «DNS resolving failed» error

Mon Jan 16, 2012 9:57 am

Re: «DNS resolving failed» error

Mon Jan 16, 2012 10:22 am

Re: «DNS resolving failed» error

Thu Feb 02, 2012 3:38 pm

i managed to get through the DNS resolving error by restarting the RouterOS.( i heard from a friend that it’s a bug in version 3 )

now i am having another error: (Network is Unreachable)
i have already tested the internet connection by connecting the laptop directly to the internet cable it is working properly.
now i believe that there is something wrong in my configuration. how can i figure out what is the missing part in the configuration.
Please advise.

Источник

Ошибка net::ERR_NAME_NOT_RESOLVED: быстрое устранение

Привет! Это статья специально для пользователей, у которых при открытии сайта вываливается сообщение «Веб-страница недоступна». Сообщение появляется у всех пользователей Google Chrome – на ПК с Windows и телефонах с Android. А если посмотреть чуть ниже, то будет другая интересная приписка:

Error 105 (net::ERR_NAME_NOT_RESOLVED): Unable to resolve the server’s DNS address

В русском переводе – «Не удается преобразовать DNS-адрес сервера»

Или просто и без приписок:

О том, как исправить эту окаянную ошибку, я и расскажу в этом классной короткой статье. Но если у вас вдруг останутся какие-то вопросы – обязательно спрашивайте меня в комментариях. Спасибо писать туда же!

Почему возникает?

Итак, Ошибка 105, или в расшифровке ERR_NAME_NOT_RESOLVED означает возникновение проблем в службах DNS на одном из участков:

1. У вас на компьютере – тогда не будут открываться сразу несколько сайтов.
2. У провайдера – та же самая беда, но у же не на вашей стороне, тоже есть обходы.
3. У владельца сайта – тогда не открывается один конкретный сайт.

При этом не открываются только сайты или какие-то отдельные странички в играх. В основном приложения на телефоне работают стабильно – проверьте в тех же месседжерах, что с интернетом все в порядке.

А теперь смотрим основные действия и делаем их по порядку. Эти шаги решат вашу проблему в 99% случаев!

Перезагрузка

Это самый простой способ, подходящий почти для любой ошибки, связанной с работой с сетями.

Просто перезагрузите и роутер (если соединение через него), и смартфон или планшет!

Для чего это нужно – иногда сетевые настройки сбиваются. И их можно задать и руками, но обычно проще всего перезагрузиться – тогда они будут получены автоматически. А действий для этого нужно приложить минимально. Пробуем!

Меняем DNS

Для первого и второго случая проблемы самым оптимальным вариантом будет просто заменить DNS серверы провайдера на альтернативные, которые будут работать в любую погоду и солнечную активность. Предлагаю – Google Public DNS. Что делаем:

1. Идем в «Центр управления сетями» (Windows 7) или «Параметры сети и интернет» (Windows 10):

1. Настройки параметров адаптера:

1. А далее для своего адаптера делаем так:

Такую же операцию можно проделать на своем телефоне – просто полазьте немного в настройках Wi-Fi или мобильного интернета. Уверен, DNS есть везде. И везде его можно поменять на такие адреса. В итоге все должно забегать! Вот как это делается на Андроиде в Samsung Galaxy:

1. Выбираем нашу Wi-Fi сеть, тапаем по ней и удерживаем, пока не появится меню.
2. Изменить конфигур. сети – Показать дополнительные параметры:

1. Вбиваем DNS, все остальное необязательно:

Проверки работы DNS

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

1. DNS-клиент. Перейдите в Службы (правой кнопкой по Пуску – Управление компьютеров – Службы и приложения – Службы). Убедитесь, что служба DNS-клиент работает, иначе включите ее. Без нее все сайты будут падать:

1. Чистим DNS-кэш. Бывает, что он забивается, указывает на старые пути расположения сайта, где он уже не лежит. Так что можно попробовать его почистить, и пусть он попробует заново найти нужный адрес. В командную строку вбиваем команду:

1. Если и это не помогает, отдельно пробуем перезапустить сетевой адаптер без перезагрузки. В командную строку:

Другие действия

Что еще нужно проверить, если ничего выше не помогло:

1. Не открываются все сайты или только этот один? Если один – скорее всего проблема на стороне владельца. Нужно всего лишь подождать. Может 5 минут, может день, а может разработчик совсем забросил его навсегда. Но суть – проблема в этом случае не лежит на вашей стороне, и вы ее никак не решите.
2. Другие устройства – а открывается этот сайт с другого компьютера или телефона? Если да – проблема точно у вас на трубе. Если нет – проблема у провайдера (смена DNS в разделе выше обычно помогает), или на стороне сайта (не решается).
3. Браузеры – еще работу сайта может блокировать отдельный браузер. Если вы используете Chrome, попробуйте зайти со стандартного браузера Android или Edge на винде. Не поможет – проблема где-то зарыта глубже.
4. Кэш браузера – конкретно на пальцах показать не могу, но иногда кэш портит всю картину. Даже в очень странных ситуация вплоть до такой. Просто почистите его (иногда в разделе Очистить историю).
5. Антивирус – попробуйте-ка его временно отключить. Иногда им что-то не нравится, и они что-нибудь блокируют. Были очень странные случаи, так что на всякий пожарный сделайте и проверьте.

Источник

Долгий DNS resolve в Kubernetes

Эта статья посвящена проблемам работы DNS в Kubernetes, с которыми столкнулась наша команда. Как оказалось, иногда проблема лежит гораздо глубже, чем кажется изначально.

Вступление

Всегда наступает момент, когда в уже отлаженную работу вмешиваются обстоятельства, заставляя нас что-то менять. Так и наша небольшая команда была вынуждена перенести все используемые приложения в Kubernetes. Причин было много, объективных и не очень, но история, собственно, не об этом.

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

11 часов, начало рабочего дня. В системе мониторинга не хватает части сообщений от одного из приложений.

Диагностика

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

При ближайшем рассмотрении стало понятно, что логи попадают в консоль, а вот в Elastic их уже нет.

Немного о системе мониторинга: Elasticsearch-кластер с тремя нодами, развернутый в том же Kubernetes, отображение при помощи Kibana. В Elastic логи попадали при помощи пакета Serilog.Sinks.Elasticsearch, который отправлял запросы через реверс-прокси на основе Nginx (изначально все приложения писались с расчетом на то, что в Elasticsearch не используется авторизация, так что пришлось исхищряться). Проверка логов Nginx показала, что иногда запросов от приложения вообще не поступает.

Быстрый поиск в интернете не нашел никаких похожих проблем у пользователей Serilog, зато рассказал, что у Serilog есть selflog для логирования внутренних ошибок. Недолго думая, подключаю его к самому Serilog:

Делаю новый билд, запускаю релиз, проверяю логи приложения. В Kibana.

Сообщения от логера в Elasticsearch о том, что он не может отправить сообщения в Elasticsearch вызывают у меня легкую истерику. Зато становится понятно, что HttpClient логгера периодически уходит в таймаут при попытке отправить сообщение. Не всегда, но достаточно часто, для того чтобы на проблему нельзя было просто закрыть глаза.

В этот момент возникает стойкое ощущение, что проблема кроется гораздо глубже, чем казалось изначально. В курилке обсуждаю варианты с коллегой. Коллега вспоминает, что мы до сих пор не перенесли одно API в Kubernetes, потому что запросы к нему иногда начинали занимать по 5-10 секунд вместо 100-150мс на земле. Логика его работы как раз подразумевала обращения через HTTP к сторонним сервисам. В тот раз все списали на географическую удаленность кластера от этих самых сторонних сервисов и отложили перенос до лучших времен.

Начинает вырисовываться картина – периодически, но не всегда, при выполнении HTTP запроса из контейнера запрос начинает занимать неприлично много времени.

Что бы убедиться, что проблема не привязана к конкретному приложению или фреймворку, в первом попавшемся контейнере запускаю bash-скрип, в цикле опрашивающий google.com и выводящий время запроса:

Догадка оказалась верна – спорадически начинают появляться те самые задержки в 5 секунд.

Чувствуя близость решения проблемы, собираю тестовый под:

Суть пода – в бесконечном цикле раз в секунду делаем запрос на google.com при помощи curl. Результаты запроса нас не интересуют, так что перенаправляем их в /dev/null, а в консоль выводим подробные метрики из curl.

В качестве адреса можно указать что угодно, включая сервисы, развернутые в самом кластере. Главное условие – он должен быть указан в виде доменного имени и резолвиться используемым в кластере DNS (почему именно так – далее). Конфигурация написана для Kubernetes 1.14, для других версий, возможно, потребуются небольшие изменения.

Запускаем, смотрим его логи:

Из логов видно, что основная проблема – долгий DNS-lookup, который занимает 99% времени запроса – те самые 5 секунд. Проблема может возникать как каждые два запроса, так и не проявлять себя несколько минут.

Диагноз

В очередной раз идем в интернет.

Окей, гугл — 5 seconds dns resolve kubernetes.

Гугл мгновенно выдает с десяток статей и записей в блогах, большинство из которых ссылаются на одну из двух публикаций:

Из них можно узнать, что проблема:

1. Существует довольно давно (самое раннее упоминание, что я смог найти – 2017 год, но, вероятно, проблема существовала практически всегда) и до сих пор не имеет стабильно работающего решения.
2. Проявляется во внезапном росте времени DNS lookup. В некоторых случаях, задержка может доходить до 10-15 секунд.
3. Возникает, если несколько DNS-серверов доступны по одному VIP, скрытыми за DNAT.
4. Не зависит от используемого сетевого плагина.

Корень проблемы – возникновение race conditions в conntraсking механизмах Linux при использовании SNAT и DNAT. Вероятность этой проблемы Tobias Klausmann рассматривал еще в 2009 году, а в Linux 5.0 было внесено два патча, уменьшающих вероятность этого события.

Однако, в случае с Kubernetes DNS, race condition продолжают происходить.

При использовании glibc (образы на основе Ubuntu, Debian и т. д.), работает это следующим образом:

1. glibc использует один и тот же UDP сокет для параллельных запросов (A и AAAA). Так как UDP это connectionless протокол, вызов connect(2) не отправляет никаких пакетов, поэтому в таблице conntrack не создается записи.
2. DNS-сервер в Kubernetes доступен по VIP при помощи DNAT правил в iptables.
3. В процессе DNAT трансляции, ядро вызывает netfilter хуки в следующем порядке:
   a. nf_conntrack_in: создает conntrack hash object и добавляет его в список не подтвержденных записей.
   b. nf_nat_ipv4_fn: производит трансляцию и обновляет кортеж conntrack.
   c. nf_conntrack_confirm: подтверждает запись, добавляет ее в таблицу.
4. Два параллельных UDP запроса соревнуются за подтверждение записи. Дополнительно, они используют различные инстансы DNS-серверов. Один из них выигрывает гонку, второй проигрывает. Из-за этого увеличивается счетчик insert_failed, запрос теряется и уходит в таймаут.

Решение

Готового универсального решения до сих пор нет, но есть несколько возможных workaround:

1. Использовать по одному DNS-серверу на ноду и указывать его в качестве nameserver. Можно использовать LocalDNS cache
2. При использовании сетевого плагина Weave при помощи tc(8) добавить искусственную микро-задержку во все AAAA DNS запросы
3. Добавить флаг single-request-reopen в resolv.conf

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

Начиная с версии Kubernetes 1.9, в конфигурации pod появился блок dnsConfig, отвечающий за генерацию файла resolv.conf.

Добавив следующий блок в описание pod, мы заставим glibc использовать разные сокеты для A и AAAA запросов, избежав тем самым race condition.

Источник

Edit: Coincidentally, within 15 minutes of this post, the downloading restarted, albeit with an ETA that is alternating between 1 hour and 15 hours. I’ll leave this post in case anyone has insights to share.

I started a download a week ago using BitTorrent. It stopped downloading at a little over 80% not long after the download started. I’ve left my client open for hours since with no progress.

I’ve seen only one or two seeds since I started downloading, and I’m currently connected to 0 out of 1 seeds. I understand that if that seed doesn’t have space for more connections, that could explain why I’m not connected to them.

There are some things I don’t understand, though. Under peers, it says 2(5), so that means I’m uploading to someone, right? But there’s nothing under the upload column, and in the General tab, it confirms my upload speed is 0.0 kB/s. What’s happening with my connection to those two peers if my upload speed is 0?

Also, in the Logger tab, there’s a long list of «DNS resolution failed for tracker tracker name.» Is it possible this is related to the other issues?

Это действительно странная проблема для меня, ребята. Мой Utorrent не подключается ни к одному трекеру. В логгере написано

Не удалось разрешить DNS для трекера udp://……..
Не удалось разрешить DNS для трекера udp://……..
Не удалось разрешить DNS для трекера udp://……..
Не удалось разрешить DNS для трекера udp://……..

Я закрываю Utorrent на панели задач и снова открываю его. Уторрент не подключается к интернету. Нет зеленой галочки или желтого восклицательного знака. Моя загрузка начинается всякий раз, когда я вижу любую из двух меток. Но на этот раз нет отметки. Я попытался переустановить Utorrent, перезагрузить компьютер, повторно подключиться, ничего не работает. Мое подключение к Интернету в порядке. Я использую это подключение более 2 лет. эта проблема началась с последних 2-3 месяцев. Обычно переустановка Utorrent избавляет от проблем. Но на этот раз нет.

Следопыт говорит:

[DHT] ждет объявления
[Local peer discovery] работает [peer exchange] работает

и «тайм-аут соединения» для всех остальных трекеров.

Пожалуйста помоги.

Время прочтения
6 мин

Просмотры 5.1K

Эта статья посвящена проблемам работы DNS в Kubernetes, с которыми столкнулась наша команда. Как оказалось, иногда проблема лежит гораздо глубже, чем кажется изначально.

Вступление

Всегда наступает момент, когда в уже отлаженную работу вмешиваются обстоятельства, заставляя нас что-то менять. Так и наша небольшая команда была вынуждена перенести все используемые приложения в Kubernetes. Причин было много, объективных и не очень, но история, собственно, не об этом.

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

11 часов, начало рабочего дня. В системе мониторинга не хватает части сообщений от одного из приложений.

Диагностика

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

При ближайшем рассмотрении стало понятно, что логи попадают в консоль, а вот в Elastic их уже нет.

Немного о системе мониторинга: Elasticsearch-кластер с тремя нодами, развернутый в том же Kubernetes, отображение при помощи Kibana. В Elastic логи попадали при помощи пакета Serilog.Sinks.Elasticsearch, который отправлял запросы через реверс-прокси на основе Nginx (изначально все приложения писались с расчетом на то, что в Elasticsearch не используется авторизация, так что пришлось исхищряться). Проверка логов Nginx показала, что иногда запросов от приложения вообще не поступает.

Быстрый поиск в интернете не нашел никаких похожих проблем у пользователей Serilog, зато рассказал, что у Serilog есть selflog для логирования внутренних ошибок. Недолго думая, подключаю его к самому Serilog:

Serilog.Debugging.SelfLog.Enable(msg =>
{
  Serilog.Log.Logger.Error($"Serilog self log: {msg}");
});

Делаю новый билд, запускаю релиз, проверяю логи приложения. В Kibana.

> Caught exception while preforming bulk operation to Elasticsearch: Elasticsearch.Net.ElasticsearchClientException: Maximum timeout reached while retrying request. Call: Status code unknown from: POST /_bulk

Сообщения от логера в Elasticsearch о том, что он не может отправить сообщения в Elasticsearch вызывают у меня легкую истерику. Зато становится понятно, что HttpClient логгера периодически уходит в таймаут при попытке отправить сообщение. Не всегда, но достаточно часто, для того чтобы на проблему нельзя было просто закрыть глаза.

В этот момент возникает стойкое ощущение, что проблема кроется гораздо глубже, чем казалось изначально. В курилке обсуждаю варианты с коллегой. Коллега вспоминает, что мы до сих пор не перенесли одно API в Kubernetes, потому что запросы к нему иногда начинали занимать по 5-10 секунд вместо 100-150мс на земле. Логика его работы как раз подразумевала обращения через HTTP к сторонним сервисам. В тот раз все списали на географическую удаленность кластера от этих самых сторонних сервисов и отложили перенос до лучших времен.

Начинает вырисовываться картина – периодически, но не всегда, при выполнении HTTP запроса из контейнера запрос начинает занимать неприлично много времени.

Что бы убедиться, что проблема не привязана к конкретному приложению или фреймворку, в первом попавшемся контейнере запускаю bash-скрип, в цикле опрашивающий google.com и выводящий время запроса:

while true;
do curl -w "%{time_total}n" -o /dev/null -s "https://google.com/";
sleep 1;
done

Догадка оказалась верна – спорадически начинают появляться те самые задержки в 5 секунд.

Чувствуя близость решения проблемы, собираю тестовый под:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ubuntu-test-scripts
data:
  loop.sh: |-
    apt-get update;
    apt-get install -y curl;
    while true;
    do echo $(date)'n';
    curl -w "@/etc/script/curl.txt" -o /dev/null -s "https://google.com/";
    sleep 1;
    done
  curl.txt: |-
    lookup:        %{time_namelookup}n
    connect:       %{time_connect}n
    appconnect:    %{time_appconnect}n
    pretransfer:   %{time_pretransfer}n
    redirect:      %{time_redirect}n
    starttransfer: %{time_starttransfer}n
    total:         %{time_total}n
---
apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-test
  labels:
      app: ubuntu-test
spec:
  containers:
  - name: test
    image: ubuntu
    args: [/bin/sh, /etc/script/loop.sh]
    volumeMounts:
    - name: config
      mountPath: /etc/script
      readOnly: true
  volumes:
  - name: config
    configMap:
      defaultMode: 0755
      name: ubuntu-test-scripts

Суть пода – в бесконечном цикле раз в секунду делаем запрос на google.com при помощи curl. Результаты запроса нас не интересуют, так что перенаправляем их в /dev/null, а в консоль выводим подробные метрики из curl.

В качестве адреса можно указать что угодно, включая сервисы, развернутые в самом кластере. Главное условие – он должен быть указан в виде доменного имени и резолвиться используемым в кластере DNS (почему именно так – далее). Конфигурация написана для Kubernetes 1.14, для других версий, возможно, потребуются небольшие изменения.

Запускаем, смотрим его логи:

Из логов видно, что основная проблема – долгий DNS-lookup, который занимает 99% времени запроса – те самые 5 секунд. Проблема может возникать как каждые два запроса, так и не проявлять себя несколько минут.

Диагноз

В очередной раз идем в интернет.

Окей, гугл — 5 seconds dns resolve kubernetes.

Гугл мгновенно выдает с десяток статей и записей в блогах, большинство из которых ссылаются на одну из двух публикаций:

• A reason for unexplained connection timeouts on Kubernetes/Docker
• 5-15s dns lookups on Kubernetes

Можно даже найти открытую issue в репозитории weave.

Из них можно узнать, что проблема:

1. Существует довольно давно (самое раннее упоминание, что я смог найти – 2017 год, но, вероятно, проблема существовала практически всегда) и до сих пор не имеет стабильно работающего решения.
2. Проявляется во внезапном росте времени DNS lookup. В некоторых случаях, задержка может доходить до 10-15 секунд.
3. Возникает, если несколько DNS-серверов доступны по одному VIP, скрытыми за DNAT.
4. Не зависит от используемого сетевого плагина.

Корень проблемы – возникновение race conditions в conntraсking механизмах Linux при использовании SNAT и DNAT. Вероятность этой проблемы Tobias Klausmann рассматривал еще в 2009 году, а в Linux 5.0 было внесено два патча, уменьшающих вероятность этого события.

Однако, в случае с Kubernetes DNS, race condition продолжают происходить.

При использовании glibc (образы на основе Ubuntu, Debian и т. д.), работает это следующим образом:

1. glibc использует один и тот же UDP сокет для параллельных запросов (A и AAAA). Так как UDP это connectionless протокол, вызов connect(2) не отправляет никаких пакетов, поэтому в таблице conntrack не создается записи.
2. DNS-сервер в Kubernetes доступен по VIP при помощи DNAT правил в iptables.
3. В процессе DNAT трансляции, ядро вызывает netfilter хуки в следующем порядке:
   a. nf_conntrack_in: создает conntrack hash object и добавляет его в список не подтвержденных записей.
   b. nf_nat_ipv4_fn: производит трансляцию и обновляет кортеж conntrack.
   c. nf_conntrack_confirm: подтверждает запись, добавляет ее в таблицу.
4. Два параллельных UDP запроса соревнуются за подтверждение записи. Дополнительно, они используют различные инстансы DNS-серверов. Один из них выигрывает гонку, второй проигрывает. Из-за этого увеличивается счетчик insert_failed, запрос теряется и уходит в таймаут.

Решение

Готового универсального решения до сих пор нет, но есть несколько возможных workaround:

1. Использовать по одному DNS-серверу на ноду и указывать его в качестве nameserver. Можно использовать LocalDNS cache
2. При использовании сетевого плагина Weave при помощи tc(8) добавить искусственную микро-задержку во все AAAA DNS запросы
3. Добавить флаг single-request-reopen в resolv.conf

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

Начиная с версии Kubernetes 1.9, в конфигурации pod появился блок dnsConfig, отвечающий за генерацию файла resolv.conf.

Добавив следующий блок в описание pod, мы заставим glibc использовать разные сокеты для A и AAAA запросов, избежав тем самым race condition.

spec:
  dnsConfig:
    options:
    - name: single-request-reopen

К сожалению, у конкретно этого метода есть одно ограничение — если приложение не использует glibc (например, это образ на основе alpine, где используется musl), то файл resolv.conf будет проигнорирован.

P.S. В нашем случае для автоматизации этого процесса был написан простейший mutating webhook, который автоматически проставляет эту секцию конфигурации для всех новых pod в кластере. Код, к сожалению, привести не могу.

0 Пользователей и 1 Гость просматривают эту тему.

This is really a weird problem for me guys. My utorrent is not connecting to any tracker. In the logger it says

DNS resolution failed for tracker udp://……..
DNS resolution failed for tracker udp://……..
DNS resolution failed for tracker udp://……..
DNS resolution failed for tracker udp://……..

I close utorrent from the taskbar, and re-open it. Utorrent doesn’t connect to the internet. No green check mark or yellow exclamation mark. My downloading starts whenever I see any of the two marks. But this time there is no mark. I have tried reinstalling Utorrent, restarting PC, re-connecting , nothing works. My Internet connection is fine Been using this connection for more than 2 years. this problem started from the past 2-3 months. Usually, re-installing Utorrent saves the trouble. But this time not.

The trackers says:

[DHT] waiting for announce
[Local peer discovery] working
[peer exchange] working

and «connection timed out» for every other trackers.

Please help.