Резолвить что это

Как работают домены

Домены организованы в дерево. Корень дерева — зона “.”, можно сказать, домен нулевого уровня. Его потомки — несколько десятков доменов первого уровня: com, biz, org, ru, info, mobi, tv, ua, так называемые, TLD: Top-Level Domains. Для узла дерева, домена второго уровня example.com, все его непосредственные потомки (www.example.com, mail.example.com, foobar.example.com, …) образуют зону example.com.

Регистр букв в имени домена не имеет значения. EXAMPLE.COM и exAMple.Com обозначают один и тот же домен. Для удобства, имена доменов всегда пишут в нижнем регистре.

В имени домена разрешены символы a-z, 0-9 и дефис. Дефис не может быть первым и последним символом. Также запрещён частный случай, когда два дефиса стоят на 3 и 4 позиции (ab—cd). Это ограничение однозначно отделяет обычные ASCII домены от пуникода.

Для пользователей существуют юникодные домены, (например, сиськи.su) но технически их нет, браузер преобразует юникодную запись в ASCII при помощи специальной кодировки Punycode ( xn--h1aaf0ab0e.su ) и дальше работает старый добрый ASCII.

Реестр и регистраторы

В общем случае есть реестр зоны [первого уровня], регистраторы и продавцы (реселлеры регистраторов). У каждой зоны первого уровня есть реестр, можно ещё сказать, координатор. Это организация, которая хранит, обслуживает и предоставляет доступ для регистраторов к центральной базе данных доменов этой зоны. По понятным причинам, некоторые организации фактически обслуживают несколько зон, это касается, например, зон RU и РФ. Во многих национальных доменах [первого уровня] координатор и является единственным регистратором, то есть отсутствует институт распределённой регистрации доменов.

Реестр продаёт регистраторам право доступа к зоне. Реестр — это сугубо техническая организация, предоставляющая программный интерфейс (API) для регистраторов.

А вот регистраторы уже работают с розничными клиентами, людьми. В зоне RU реестром является РосНИИРОС, а самым крупным регистратором — РуЦентр.

Чтобы стать регистратором, нужно выполнить разные строгие требования реестра. Вот каковы требования к кандидату в регистраторы в России. Список регистраторов растёт, и на 15 ноября 2009 года насчитывает 23 штуки.

Регистрация домена

Регистрация состоит из обращения к регистратору (или реселлеру, для пользователя разницы нет); это как придти в магазин и сказать, мол, хочу купить такой-то домен. К слову, в зоне RU на конец 2009 года зарегистрировано порядка 2.5 млн. доменов, а в зоне COM — порядка 80 млн. То есть вероятность, что имя, которое вы хотите зарегистрировать, уже занято сильно варьируется в разных зонах первого уровня.

Если этот домен уже кем-то куплен (возможно, через другого регистратора, реестр-то один), то …пролёт.

Проверить, был ли домен свободен, можно и без намерений о покупке. Для этого нужно воспользоваться т.н. сервисом WHOIS. Например, здесь swhois.net или здесь nic.ru. Красноглазые друзья могут написать whois имя-домена.зона в консоли. Поскольку, формат ответа не стандартизирован, нельзя описать что конкретно искать в ответе, чтобы понять, что домен свободен, но, в целом, будет ясно. Если домен занят, то выводится куча (или немножко) информации о его владельце. Здесь кто-то может возразить, мол, да проще в браузере ввести адрес и сразу будет ясно. Действительно, в 99% случаев это работает, потому что, чаще всего, домен покупают, чтобы сделать на нём публичный сайт. Но это не всегда так. Некоторые домены куплены и принадлежат конкретным людям, но сайтов на них нет.

1. формальное временное право владения доменом. Самая близкая аналогия — аренда.
2. доступ к изменению NS-серверов домена

Домен продают именно вам, это, практически, ваша вещь, в реестре хранится информация о владельце. В случае проблем с регистратором, можно перенести домен к другому, при этом, на всех этапах переноса, владельцем домена является только его покупатель.

Нет никаких технических ограничений на этот счёт, но почему-то так сложилось, что все реестры регистрируют домены минимум, на 1 год (в зоне CO.UK на 2). По истечении этого срока регистрацию домена необходимо продлить. Продление, как правило, стоит немного дешевле регистрации. Некоторые реестры позволяют “продлевать домены” на несколько лет вперёд. Право владения доменом в зоне ru можно продлить только на 1 год. Ещё на год можно будет продлить в следующем году. Все регистраторы предоставляют услугу “автопродления”, когда с вашего баланса в нужный момент времени списывается сумма необходимая для продления домена.

DNS резолвинг

Полагаю, что читатель знаком с понятием IP адрес и понимает, что домены, в общем-то, нужны только для удобства людей. IP пакеты ходят между компьютерами с числовыми адресами. Например, домену python.org соответствует IPv4 адрес 82.94.164.162. Чтобы выяснить это соответствие, используется DNS: Domain Name System. Это распределённая база данных, её работа довольно сложна, но интересна.

В системе DNS учавствуют серверы и клиенты. При помощи специального протокола DNS клиенты делают запросы, а серверы им отвечают. Обычно, для DNS запросов используется транспортный протокол UDP (иногда, TCP, но этот вариант используется намного реже из-за накладных расходов на создание соединения). Зарезервированный номер UDP и TCP порта для DNS: 53. Протокол бинарный, большинство запросов и ответов помещаются в UDP пакеты с ограничением 512 байт.

DNS не самодостаточна. Чтобы “всё завелось”, в конце концов, какой-то клиент должен сделать запрос к какому-то серверу, не зная его имени. Обычно, эту проблему решает DHCP сервер интернет-провайдера, который по специальному протоколу, помимо прочего, сообщает IP адреса своих кеширующих DNS серверов. Кроме того, существуют сервисы DNS серверов, такие как OpenDNS, которые работают благодаря постоянным IP адресам.

DNS запросы бывают “прямые” и рекурсивные. Прямой запрос предназначается конкретному серверу. Клиента интересует только та информация, которую может дать именно этот сервер. Рекурсивный запрос, наоборот, предполагает, что клиенту неважно откуда будет информация, важно получить ответ. Кеширующие DNS серверы при получении рекурсивного запроса сами инициируют новый запрос к вышестоящему (upstream) серверу. Такая цепочка может дойти до сервера регистратора или до корневых серверов (серверы зон первого уровня).

1. класс. На практике используется один класс: IN (Internet), но предусмотрена поддержка и других классов.
2. тип, например, A означает, что имя в этой записи является синонимом (alias) к указанному в значении IPv4 адресу. Это самый распространённый тип записей.
3. имя, например, www . В различных программах редактирования зон, часто используется специальное имя @ как короткая ссылка на имя зоны. Например, запись @ A 1.2.3.4 в зоне example.com означает присвоение указанного адреса для собственно имени example.com. После программы, в базу данных DNS заносится запись example.com IN A 1.2.3.4 . То есть в сетевом протоколе DNS такое имя как @ никогда не фигурирует, оно есть только для удобства настройки зоны.
4. значение, например, IP адрес 1.2.3.4 . Или текстовое имя другого домена. Или вообще, просто кусок текста. Всё зависит от типа записи.
5. TTL (time to live), например, 1440 . Время в секундах, в течение которого полученная информация в записи считается действительной. Используется для кеширования.

В DNS используется система делегирования полномочий. Корневые сервера реестра делегируют полномочия выдавать ответы по определённым зонам на NS (name server) этих зон. Когда кто-то спрашивает NS о его зоне, он помечает ответ как авторитетный (authoritative). Другие NS в ответ на ваш запрос, могут сказать я не знаю, но вот он знает . Такая цепочка может быть бесконечной. Предполагается, что в какой-то момент (на практике это первый же сервер после перенаправления) сервер даст вам конкретную информацию: либо я в ответе, вот записи , либо я не знаю и не знаю кто знает .

1. адрес (чаще всего имя домена, типа ns1.example.com ) т.н. первичного NS
2. email адрес администратора зоны
3. и несколько других полей. Версия (serial) зоны и таймауты, в течение которых действительна данная информация.

Существуют специальные, т.н. корневые сервера. Они хранят информацию о том какие зоны обслуживаются какими NS, то есть, SOA записи. Можно спросить корневой сервер об абсолютно любой записи любой зоны и гарантированно никогда не получить авторитетный ответ. 🙂 Но вы получите адрес NS, который, по-мнению корневого сервера обслуживает интересующую вас зону. Нужно повторить запрос к полученному NS. Такие повторы называются рекурсивным резолвингом.

Безопасность

Использование UDP, в частности, означает, что вы могли послать запрос одному компьютеру, а ответил другой. DNS протокол не даёт ровным счётом никаких средств для защиты передаваемой информации. Также нет никакого способа проверить, что ответ не был изменён кем-то по дороге до вашего компьютера. Отправка запроса к DNS серверу и ожидание ответа называется резолвингом (DNS resolving). Строго говоря, это название относится только к A запросам, которые используются для выяснения какой адрес соответствует указанному имени. В более общем смысле, обращение к DNS называется (сюрприз!) запросом (query). Но, в действительности, резолвинг A записей это 99% использования DNS. Оба названия имеют право на жизнь, к тому же нет принципиальной разницы.

DNS — распределённая база данных, к ней применимы стандартные правила доверия в распределённой среде. Доверять нельзя никому. Любой администратор может запустить DNS сервер, настроить у себя зону, к примеру, google.com, но другими адресами, ведущими на его серверы. Браузер не заметит подмены, человека тоже можно обмануть. В чём подвох? В том, что никакой браузер не будет спрашивать ваш левый DNS сервер.

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

Делегирование

Делегирование домена это изменение его SOA записи в родительской зоне. Делегирование домена temoto.ru это изменение записи temoto.ru SOA … в зоне ru. При покупке домена второго уровня, в зоне первого уровня появится SOA запись о новом домене. Зоны первого уровня обслуживаются DNS серверами реестров.

В общем случае, сразу после регистрации существование домена можно обнаружить только с помощью WHOIS. Для перекупки коротких/интересных имён этого достаточно, но чаще всего люди хотят сделать с доменом что-то полезное. Например, чтобы вводя в адресной строке http://mydomain.tld/ пользователь попадал на ваш сайт. Как правило, эту задачу решает регистратор. Например, Рэгги (и почти все остальные) предоставляет бесплатные DNS сервера при покупке домена. И делегирует ваш домен на свои NS. И в этих NS есть A запись, указывающая на IP адрес специального веб-сервера, который выдаёт страницу “домен зарегистрирован”.

Обычно говорят делегировать на такие-то сервера . Это подразумевает создание в корневом реестре не только SOA, но и нескольких NS записей. NS записи указывают на авторитетные NS сервера, которые обслуживают данную зону.

Кеширование

DNS — это, пожалуй, самый большой и успешный пример использования проксирующего кеширования.

Поскольку записи в зонах изменяются относительно редко, нет смысла после каждого клика по ссылке резолвить имя домена в ссылке. Помните, в DNS записи есть TTL? Однажды получив, скажем, IP адрес из записи example.com A 192.0.32.10 , с TTL, скажем 120, мы имеем полное право в течение 120 секунд предполагать, что адрес example.com является 192.0.32.10 . А вот после 120 секунд, теоретически, нужно сделать новый запрос. Поэтому, на практике, TTL делают довольно большим: 6, 12 часов, иногда больше.

Кроме того, велика вероятность, что многие из клиентов одного интернет-провайдера (ISP) ходят на пересекающееся множество сайтов, следовательно, они резолвят одни и те же имена. Хорошо, после резолвинга браузер запомнит адрес, но клиентов тысячи. Поэтому для экономии трафика и ускорения резолвинга все интернет-провайдеры устанавливают у себя т.н. кеширующий DNS сервер. На любой прямой запрос он ответит неудачей, потому что он не содержит никаких записей. Но получив рекурсивный запрос, кеширующий DNS сервер сделает такой же запрос к вышестоящему серверу и так далее, пока не будет получен авторитетный ответ, который по цепочке обратно будет возвращён клиенту.

Однако, если кеширующий DNS сервер недавно уже делал такой же запрос, получил необходимую запись и информация ещё не устарела (не истёк срок TTL), то он отдаст информацию “сразу”, не делая запроса к вышестоящему серверу. В этом весь смысл кеширования. К сожалению, на практике, многие интернет-провайдеры настраивают свои кеширующие DNS сервера таким образом, что они игнорируют TTL в записях и сохраняют их в кеше на более длительный срок. Поэтому, когда вы меняете адрес своего сайта, может пройти несколько дней, прежде чем абсолютно везде, на всей планете этот адрес действительно изменится. Но в основном, конечно, всё проходит намного быстрее. Всё зависит от TTL.

В популярном (и дырявом) DNS пакете BIND нет чёткого разделения между кеширующим и авторитетным DNS серверами. Из-за этого новички-администраторы делают неверные предположения о схеме работы DNS и допускают ошибки.

Итоги

Люди используют осмысленные символьные имена доменов, т.к. оперировать адресами типа 192.0.32.10 неудобно. Домены имеют иерархическую структуру начиная с доменов первого уровня (TLD) и без ограничений по глубине.

Реестр это организация, которая отвечает за техническое функционирование DNS-серверов зоны первого уровня. Регистраторы заключают договора с реестрами и предоставляют услуги по регистрации, продлению, делегированию и переносу доменов для частных лиц и компаний.

DNS это распределённая база данных, которая состоит из зон. Зона — это набор DNS записей. Клиенты делают запросы к серверам посредством DNS протокола. Как правило, запросы отправляются по UDP. DNS уязвим к широкому спектру атак, включая man-in-the-middle.

В DNS очень активно используется кеширование. Это позволяет снизить нагрузку на сеть и часто является причиной непонимания между покупателями доменов и поддержкой регистратора.

Автор: Сергей Шепелев , 2009-11-16 .

Resolve IP адресов в Linux: понятное и детальное описание

Настройка сетевого взаимодействия сервисов не самая простая задача и часто осуществляется без глубокого понимания как требуется настраивать систему и какие настройки на что влияют. После миграции сервисов в docker контейнерах с centos 6 на centos 7 я столкнулся со странным поведением вебсервера: он пытался присоединиться к сервису по IPv6, а сервис же слушал только IPv4 адрес. Стандартный совет в такой ситуации — отключить поддержку IPv6. Но это не поможет в ряде случаев. Каких? В этой статье я задался целью собрать и детально объяснить как приложения resolve ‘ят адреса.

Публикация будет полезна начинающим администраторам и разработчикам.

Прочитав эту статью, вы узнаете:

• какой алгоритм в Linux для резолва хостнеймов;
• как переопределить логику определения хостнеймов;
• какие функции и библиотеки использует ОС;
• какие ловушки существуют при конфигурировании и как их не допускать;

У операционной системы Linux есть несколько источников для определения адреса по hostname. Весь необходимый функционал для определения находится в GNU C Library (glibc). glibc является по-сути фреймворком и реализовывает множество полезных функций для разработчика, предоставляя свой API для упрощения разработки. Среди прочего, glibc имплементирует POSIX. Такие функции как open , read , write , malloc , printf , getaddrinfo , dlopen , pthread_create , crypt , login , exit для Linux систем предоставляет именно glibc.

Известные многим утилиты host , dig и nslookup используют glibc, но поставляются отдельно.

Теперь, когда у разработчика есть возможность вызвать функцию семейства getaddrinfo из glibc для определения адреса, то возникает потребность конфигурировать возвращаемые значения. Например, использовать ли сперва /etc/hosts или запрос к DNS-серверу. В glibc подобное конфигурирование производится с помощью схемы под названием Name Service Switch (NSS).

Если объяснять на пальцах, то NSS позволяет задавать базы данных и очередность поиска в этих базах для предоставления сервиса. В нашем случае, сервис — это поиск по hostname, а базой данных может выступать /etc/hosts или DNS сервер. Это не единственный сервис настраиваемый посредством NSS, предоставляются сервисы mail алиасов, сервис поиска пользователей и групп. Ознакомится со списком можно в руководстве.

Благодаря NSS можно без пересборки приложений, в рантайме, конфигурировать упомянутые базы данных. Производится конфигурирование в файле /etc/nsswitch.conf . Ниже пример конфига из стандартного /etc/nsswitch.conf в Centos 7.

files, dns и myhostname являются алиасами баз данных для поиска. files на большинстве систем подразумевает использование /etc/hosts , dns база — это DNS-сервер к которому будет осуществляться запрос поиска hostname, а myhostname — это самая необычная база, о существовании которой мало кто знает и она не является частью стандартной поставки в glibc. В некоторых дистрибутивах присутствует еще и база mdns4_minimal. Ниже по тексту предоставлен разбор этих баз данных.

Базы используются в том порядке в котором они обьявлены в /etc/nsswitch.conf и если в текущей базе запись найдена, то происходит выход из цепочки и возврат результата. При отсутствии результата происходит переход к следующей базе в списке. Если ни в одной базе не найден результат, то такой ответ и дается на запрос glibc функции getaddrinfo . Поведение перехода к следующей базе и условия такого перехода можно дополнительно конфигурировать, например, при недоступности DNS (не путать с отсутствием записи) завершить цепочку. Понятное и простое объяснение принципа настройки условий для /etc/nsswitch.conf даны в этой статье.

База files, а в частности /etc/hosts , из коробки в Centos 7 выглядит следующим образом:

Можно отметить, что для localhost имеются две записи: IPv4 и IPv6 адрес. Это может сыграть злую шутку и в конце материала я расскажу почему.

База dns при определении адреса использует name server указанный в конфиге /etc/resolv.conf . Вот пример моего /etc/resolv.conf на хост системе:

Name server’а используются тоже по цепочке и в порядке их объявления. В моем случае, первым выступает локальный DNS сервер (я использую dnsmasq) для задания локальных адресов .priv зон. Если находится совпадение, то возвращается адрес из локальной сети. Все остальные запросы отправляются на основной DNS сервер с адресом 192.168.100.1 .

База myhostname присутствует в поставке Centos и Ubuntu, но не является частью glibc . Не зная этого факта я потратил много времени пытаясь выяснить почему мне возвращаются IPv6 адреса для определения хоста. Он работает следующим образом:

• При запросе локального хостнейма (того что возвращает команда hostname ) плагин возвращает все IP адреса публичных интерфейсов (т.е. все кроме loopback), при отсутствии таких интерфейсов возвращается IPv4 адрес 127.0.0.2 и IPv6 адрес ::1 ;
• При запросе хостнейма localhost или localhost.localdomain возвращает IPv4 адрес 127.0.0.1 и IPv6 адрес ::1 ;
• При запросе хостнейма оканчивающегося на .localhost или .localhost.localdomain возвращает IPv4 адрес 127.0.0.1 и IPv6 адрес ::1 ;

В мануале еще пишут про особую логику с обработкой хостнейма _gateway, но видимо это какой-то патч, так как с Centos 7 у меня он не завелся.

База mdns4_minimal или же mdns_minimal требуется для корректной работы Avahi. При необходимости можно обратиться к документации Arch по Avahi, где коротко и понятно дана информация
по использованию.

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

Обычно администраторы проверяют хостнейм используя команду host. Это некорректно, так host, как и dig, используют только DNS резолвинг, но не используют NSS. Nginx, например, использует функцию getaddrinfo, а она использует NSS. Это приводит к тому, что вбитый в /etc/hosts хостнейм может работать с nginx, но не резолвится иными способами. Куда хуже, когда в /etc/hosts вбиты IPv6 адрес для хостнейма, а в настройках DNS возвращается только IPv4 адрес. В этом случае, администратор может проверить что команда host возвращает только IPv4 адрес и успокоится, а потом приложение использующее getaddrinfo из glibc запустится и найдет для того же хостнейма IPv4 и IPv6 адрес. Источник ошибок…

Для проверки результатов возвращаемой каждой из баз документация рекомендует воспользоваться утилитой getent.

Ниже немного примеров работы с getent с включенным IPv6.

В /etc/nsswitch.conf содержится следующая цепочка баз:

В /etc/hosts содержится следующее инфо

Команда getent ahosts <hostname> покажет список всех адресов которые удалось найти. С такими настройками она выведет следующее:

Команда позволяет точечно опросить конкретную базу и выяснить что срезолвит база. Рассмотрим для каждой базы возвращаемые значения:

Если убрать из /etc/hosts строки для localhost, то вывод видоизменится:

Теперь база dns и myhostname возвращает ответы, а база files не содержит данных. Для DNS запросов используется неймсервер конфигурируемый в /etc/resolv.conf в моем контейнере, например

На хост машине установлен dnsmasq который проксирует и кэширует ответы DNS серверов. Ответ от DNS будет зависеть от настроек DNS сервера к которому поступил запрос. RFC 1912 рекомендует в пункте 4.1 сконфигурировать DNS сервера таким образом, чтобы localhost указывал на 127.0.0.1.

Certain zones should always be present in nameserver configurations:

These are set up to either provide nameservice for «special»
addresses, or to help eliminate accidental queries for broadcast or
local address to be sent off to the root nameservers. All of these
files will contain NS and SOA records just like the other zone files
you maintain, the exception being that you can probably make the SOA
timers very long, since this data will never change.

The «localhost» address is a «special» address which always refers to
the local host. It should contain the following line:

В моем случае, dnsmasq из коробки содержит записи для localhost, как и рекомендует RFC.

Отключается это либо удалением записей из /etc/hosts на самом DNS сервере, либо же включением опции no-hosts в /etc/dnsmasq.conf .

После включения опции getent для базы myhostname вернет непустой результат, но как и отмечалось выше, с включенным myhostname будет возвращаться IPv4 и IPv6 адрес. На системах со статическими IP адресами можно смело выключить myhostname плагин и конфигурировать локальные хосты с использованием /etc/hosts . Альтернативный вариант — это отключение IPv6.

Статус IPv6 на сервере можно получить из параметров ядра. Значение 0 возвращается при включенном IPv6, а 1 при выключенном.

В выводе ifconfig интерфейсы слушающие IPv6 содержат строчку inet6. Ниже пример вывода с выключенным и включенным IPv6 соответственно:

Выключить IPv6 можно вызовом

Что изменится после выключения? Я откатил все конфиги на стандартные: в /etc/hosts присутствует localhost с адресами IPv4 и IPv6, в dnsmasq выключена опция no-hosts . Отключил IPv6 командами выше и вывод getent стал следующим:

Воу, в первом выводе у нас дублируется адрес 127.0.0.1. Чтобы разобраться почему так происходит стоит обратиться к исходному коду glibc и к коду утилиты getent. Ниже кусок кода утилиты getent.

Флаг AI_V4MAPPED функции getaddrinfo производит маппинг IPv6 адресов на IPv4 если не были найдены IPv6 адреса в результате опроса базы. Флаг AI_ADDRCONFIG вынудит getaddrinfo проверить наличие IPv6/IPv4 адресов сконфигурированных в системе и в случае отсутствия хотя бы одного IPv6/IPv4 адреса не будет возвращаться IPv6/IPv4 независимо от того что ответит конкретная база.

Поскольку у getent включены оба флага, а в /etc/hosts присуствуетя для localhost адреса 127.0.0.1 и ::1 , то getaddrinfo получит из NSS базы hosts (в примере выше мы обсуждали именно эту базу), адреса 127.0.0.1 и ::1 , затем не обнаружив ни одного IPv6 адреса в системе (выключены параметрами ядра) и произведет маппинг ::1 -> 127.0.0.1 .

Чтобы лучше понять эту концепцию, приведу примеры с выводом getaddrinfo на той же системе, с разными настройками ai_flags и ai_family. В /etc/hosts включены для localhost IPv4 и IPv6 адреса.
Исходный код можно найти на моем github.

Из вывода видно, что с _aifamily равным _AIUNSPEC (возвращать и IPv4, и IPv6) и без AI_ADDRCONFIG флага getaddrinfo возвращает два адреса, IPv4 и IPv6, что многие администраторы не ожидают увидеть. Это происходит независимо от того выключен ли IPv6 в параметрах ядра. Если в /etc/hosts убрать адрес ::1 , то из вывода getaddrinfo (с флагом AF_UNSPEC ) вовсе исчезнут IPv6 адреса.

С включенным IPv6 и наличием ::1 в /etc/hosts будет возвращаться IPv4 и IPv6. Для предотвращения возврата адреса IPv6 требуется закомментировать IPv6 адрес в /etc/hosts . Если адреса будут найдены в /etc/hosts , то в dns и myhostname базу glibc не полезет.

Осталось проверить как ведет себя getaddrinfo для dns базы. Для этого оставлю в /etc/nsswitch.conf для hosts только dns базу и порезолвлю google.com. Вывод ниже с включенным IPv6.

А вот вывод с выключенным IPv6:

Как видно, ситуация с AI_ADDRCONFIG очень похожа.

Напоследок приведу пример как не учитывая все вышесказанное вляпаться в проблемы. IPv6 включен, /etc/nsswitch.conf стандартный.

Что вернет host localhost или dig ANY localhost ? Что вернет getaddrinfo , например, с флагами как у nginx?

nginx будет пытаться подключаться к двум адресам: 127.0.0.1 и ::1 , а приложение может и не ожидать такого. Источник для ошибок.

Домен не резолвится с сервера, с других серверов резолвится, как исправить?

Домен не резолвится (не отвечает) с сервера, с других серверов резолвится, как это исправить? По ip достучаться можно.

1 ответ

Не резолвится домен означает что домен не доступен или не отвечает.

Попробовать добавить адреса других DNS-серверов в /etc/resolv.conf.

Например, добавить google DNS-сервер 8.8.8.8, или вебазилловский DNS-сервер 208.88.224.54. Для этого нужно добавить строку nameserver 8.8.8.8 в /etc/resolv.conf :

Если не хватает прав (отказано в доступе), то под sudo:

Проверить, резолвится ли домен и какой DNS сервер использует можно командой nslookup: