Failed to establish a new connection: [Errno -2] Name does not resolve

Оптимизировал размер образа, который построен на базе Google Cloud SDK и столкнулся с ошибкой локальной сборки после переключения с google/cloud-sdk:497.0.0-slim на google/cloud-sdk:497.0.0-alpine:

Beginning update. This process may take several minutes.
ERROR: gcloud crashed (ConnectionError): HTTPSConnectionPool(host='dl.google.com', port=443): Max retries exceeded with url: /dl/cloudsdk/channels/rapid/components-2.json (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f2c42715950>: Failed to establish a new connection: [Errno -2] Name does not resolve'))

If you would like to report this issue, please run the following command:
  gcloud feedback

To check gcloud for common problems, please run the following command:
  gcloud info --run-diagnostics

Тестовый Dockerfile выглядит так:

FROM google/cloud-sdk:497.0.0-alpine

RUN gcloud components install gke-gcloud-auth-plugin && \
    gke-gcloud-auth-plugin --version

Проблемы с Google public DNS

Разобрался с "проблемой" в производительности сайта, мониторинг которого выполняет Zabbix. Проблема выглядела как резкие отклонения response time в графиках проверок.

Включил в Nginx логирование времени обработки запроса. Но никакой связи с пиками на графике в логе Nginx не заметил - время ответа сайта не меняется и находится в районе 150-200 ms. Следовательно проблема вовсе не в сайте.

Сначала подумал что врать может сам zabbix, но поиск по форумам не дал ничего интересного. Наврятли подобная проблема может остаться незамеченной.

Zabbix и сайт находятся в одной локальной сети, следовательно скорость соединения не может приводить к подобным отклонениям. Что может быть причиной проблемы если это не сайт и не сеть? Остается DNS и zabbix как раз использует google public dns (8.8.8.8, 8.8.4.4).

Для проверки прописываю в /etc/hosts нужные хосты и вуаля - проблема исчезает на глазах.

В процессе нашел ссылку где также указывают на проблемы с Google public DNS. Так что похоже проблема не только у меня.

В общем еще одно подтверждение правилу - если сервис не контролируется тобой, то подвести он может в любой момент.

Не работает dnssec-validation в bind9 в Ubuntu Precise

Столкнулся с багом в Ubuntu 12.04 LTS (Ubuntu Precise) - bind9, настроенный в качестве кеширующего dns, не может резолвить некоторые хосты. При этом в лог падает ошибка вида:

named[10137]: validating @0x7fa7cc019410: mail.frogger.nl A: got insecure response; parent indicates it should be secure
named[10137]: error (insecurity proof failed) resolving 'mail.frogger.nl/A/IN': 66.96.80.194#53
named[10137]: error (no valid NSEC) resolving 'mail.frogger.nl/A/IN': 85.17.41.33#53
named[10137]: error (no valid NSEC) resolving 'mail.frogger.nl/A/IN': 82.192.67.204#53

Проверка этого хоста на DNSSEC Analizer не показала никаких проблем. Если верить гуглу - я не одинок и проблема возникает с резолвингом хостов, где используется комбинация wildcard (*.frogger.nl, под который и попадает mail.frogger.nl) и DNSSEC. Соответствующие баг репорты открыты в Ubuntu #1203976 и Debian #690569.

В качестве затычки пока выключил валидацию dnssec:

options {
    dnssec-validation no; //was "dnssec-validation auto;"
}

Я пробовал сравнивать работу bind9 одинаковой версии (1:9.8.1.dfsg.P1-4) в Ubuntu и Debian: в Debian хост резолвится, а в Ubuntu - нет. Сравнение исходников пакета из Ubuntu и Debian не показывает никакой разницы. Пересборка пакета для Ubuntu тоже не улучшила ситуацию...

Возможно кто-то знает, почему один и тот же пакет bind9 по-разному ведет себя в Debian и Ubuntu?

[ipcheck] Problem with DNS setup on cpanel

Дошли руки разобраться с письмами "которые нельзя игнорировать", которыми спамит свежеустановленная WHM/cPanel. Письма выглядят так:

Subject: [ipcheck] Problem with DNS setup on cpanel

IMPORTANT: Do not ignore this email.

Your hostname (cpanel) could not be resolved to an IP address. This
means that /etc/hosts is not set up correctly, and/or there is no
dns entry for cpanel. Please be sure that the contents of
/etc/hosts are configured correctly, and also that there is a
correct 'A' entry for the domain in the zone file.
Some or all of these problems can be caused by /etc/resolv.conf
being setup incorrectly. Please check that file if you believe
everything else is correct.

You may be able to automatically correct this problem by using the
'Add an A entry for your hostname' option under 'Dns Functions' in
your Web Host Manager.

Суть письма сводится к тому, что скрипт /scripts/ipcheck не может выполнить преобразование hostname в ipaddress. Данный экземпляр cPanel крутится в CentOS 6.x контейнере под управлением OpenVZ.

Сначала появилась мысль, что слетел hostname. Проверил догадку:

# hostname
cpanel

# hostname --fqdn
cpanel.srv.example.com

# dnsdomainname.
srv.example.com

# hostname -i
1.2.3.4

На первый взгляд все правильно. Полез в сам скрипт, чтобы узнать как выполняется преобразование. Из кода видно, что скрипт пытается получить ip для $hostname = Cpanel::Sys::Hostname::gethostname() и судя по письму $hostname равен "cpanel", а не "cpanel.srv.example.com". Т.е. выполняется gethostbyname($hostname).

Чтобы исправить эту ситуацию достаточно подкрутить резолвер (правильно установить параметр search в /etc/resolv.conf). В случае с контейнером OpenVZ это выглядит так:

# vzctl set 300 --searchdomain srv.example.com

Осталось проверить правильность новых настроек, запустив /scripts/ipcheck, если все в порядке, то скрипт не вернет никакого вывода.