Ubuntu не резолвит имена

Обновлено: 04.07.2024

NETCONFIG_DNS_STATIC_SERVERS="8.8.8.8 8.8.4.4"
Может кто сталкивался с подобным? Где собака порылась? Чего то видимо не хватает в конфигах или глобальные изменеия в работе сети при переходе с 15 на Tumbleweed.

Мне кажется, какая-то нестыковка в адресах: "nameserver 192.168.244.2" и "NETCONFIG_DNS_STATIC_SERVERS="8.8.8.8 8.8.4.4"".

У меня так выглядят эти параметры:

(почему-то дублируется 192.168.0.1, рассмотрю теперь)

Через YaST настройте.

dig с nslookup дружно утверждают, что dns исправен. Только, похоже, что resolver его не использует.
Посмотрите, что прописано в /etc/nsswitch.conf в директиве hosts

После обновления было hosts: files mdns_minimal [NOTFOUND=return] dns имена не резолвились. закомментировал эту строчку добавив

. Имена вообще резолвиться перестали через dig и nslookup.
Пробовал и через yast настроить результат тот же.
по итогу вернул
/etc/nsswitch.conf | grep hosts
hosts: files mdns_minimal [NOTFOUND=return] dns
пингов по имени нет dig и nslookup работают Последний раз редактировалось Serega86 11.03.2019 10:18, всего редактировалось 1 раз.

Дальше становиться вообще не понятно.
ls -la /var/run/netconfig/
итого 8
drwxr-xr-x 4 root root 140 мар 11 09:19 .
drwxr-xr-x 39 root root 1040 мар 11 09:19 ..
-rw-r--r-- 1 root root 0 мар 11 09:19 chrony.servers
drwxr-xr-x 2 root root 60 мар 11 09:19 ens33
drwxr-xr-x 2 root root 60 мар 11 09:19 lo
-rw-r--r-- 1 root root 649 мар 11 09:19 resolv.conf
-rw-r--r-- 1 root root 581 мар 11 09:19 yp.conf

ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 30 мар 6 09:31 /etc/resolv.conf -> /var/run/netconfig/resolv.conf
ls -la /etc/yp.conf
lrwxrwxrwx 1 root root 26 мар 5 15:05 /etc/yp.conf -> /var/run/netconfig/yp.conf
yp.conf это созданый yast аналог resolv.conf ?
пинг 8.8.8.8 есть Spoiler ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=43.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=43.6 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 12ms
rtt min/avg/max/mdev = 43.621/43.683/43.745/0.062 ms

Почему-то не определяются IP с DNS, хотя адрес DNS вроде прописан и связь с ним есть. Вот содержимое конфигов:

search local nameserver 192.168.0.14

allow-hotplug eth0 iface eth0 inet static

Маршрутизатор работает нормлано, т.е. пинг до любого хоста по IP идет, а по имени нет.

Система на Debian 5.0, DNS на Win2k3 сервере.

В чём трабл никак не пойму. Как можно определить причину?

Да как бы DNS на AD под Win2k3 и моя виндовая раб.(очень точное сокращение :-)) станция все пингует нормально.

Но я уже разобрался: забыл про

domain domain.local вместо search local

А то что инет адреса не пингуются это заморочки с форвардингом к DNS провов.

Так что всем спасибо, проблема решена.

Хотя нет, проблема одна осталась: нет пингов по ping domain.local. Ping host или ping host.domain.local есть, а ping domain.local нет. Или их и не должно быть (всетаки не винда)?

ну так
dig domain.local что пишет?
лучше использовать search domain.local local
всё должно быть, если настроено нормально

с винды для тестов nslookup

>Как можно определить причину?
dig domain.local +qr +search +recurse +showsearch
как-то так

Или я чего-то недопонимаю или как-то топорно резолв работает. ping domain есть, ping domain.local отсутствует, dig domain.local срабатывает. Такое ощущение, что к указанному имени сразу лепится что-то и search, а не делается сначала попытка найти запись как есть.

search local nameserver 192.168.0.14

чо, так в одну строку и прописано? nameserver с новой строки надо.

nslookup нормально срабатывает при любой форме записи.

Видимо это какие-то недоработки утилиты ping.

если хочется как есть, то писать надо ping domain.local. с последней точкой, вроде так должно работать

Проверил, не работает. :)

Ну сделай strace ping chmz.local, и посмотри, чего ему не хватает

по ип пингуется?
тогда только tcpdump в помощь и dig с выводом пакетов запроса

Но другие машины в локальной сети могут разрешать имена хостов.

Моя локальная сеть:

1 x маршрутизатор Cisco с запущенным DD-WRT v24-sp2 с включенным DNSMasq. Я настроил это с помощью имен хостов и IP-адресов в моей локальной сети.
1 x Kubuntu 12.10 (разрешает все имена хостов правильно, если они введены в DNSMasq на маршрутизаторе)

2 x NAS (также разрешает все имена правильно)

1 x Ubuntu Server 12.04 (это НЕ разрешает локальные имена хостов, если они не введены в / etc / hosts)

Как получить последние 2 для использования записей DNSMasq на маршрутизаторе? Каждая машина настроена на использование маршрутизатора в качестве сервера имен, и все устройства правильно разрешают внешние адреса.

на сервере, если я пингую другой ПК (wstation)

Если я добавлю .local [ 1122]

3 ответа

О текущем выводе

Ясно указывает, что ваш компьютер добавляет .local.domain к запросам, не относящимся к полному доменному имени. Это что-то настроенное неправильно или, по крайней мере, неправильно в вашей настройке. (если вы не используете суффикс .local.domain специально)

Разрешение имен и периоды

Одна важная вещь, о которой многие люди не знают, - это то, что полное имя всегда должно заканчиваются точкой ( . ). Если вы его не укажете, машина попытается разрешить его в локальном поисковом домене (например, mydomain.tld). Таким образом, в этом случае запрос для mypc.local станет mypc.local.mydomain.tld . Чтобы предотвратить это, запросите с периодом.

Конфигурация резолвера

Конфигурация резолвера здесь имеет большое значение. В Ubuntu (и Debian) это настраивается в файле / etc / network / interfaces (при условии, что вы не используете NetworkManager):

Разрешение имен в Linux также может быть выполнено другими способами. Дело не только в том, что для всего этого запрашивается локальный DNS-сервер. Взгляните на ваш файл /etc/nsswitch.conf для конфигурации разрешения hosts :

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

Настройка сетевого взаимодействия сервисов не самая простая задача и часто осуществляется без глубокого понимания как требуется настраивать систему и какие настройки на что влияют. После миграции сервисов в 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, но поставляются отдельно.

А еще я веду телеграм канал Об IT без галстуков и блог. На канале рассказываю о проблемах менеджмента и как их решать, пишу о принципах мышления при решении бизнес задач, о том как стать эффективным и высокоплачиваемым специалистом.

Теперь, когда у разработчика есть возможность вызвать функцию семейства 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 не полезет.

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

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

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

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

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

Почему-то не определяются IP с DNS, хотя адрес DNS вроде прописан и связь с ним есть. Вот содержимое конфигов:

search local nameserver 192.168.0.14

allow-hotplug eth0 iface eth0 inet static

Маршрутизатор работает нормлано, т.е. пинг до любого хоста по IP идет, а по имени нет.

Система на Debian 5.0, DNS на Win2k3 сервере.

В чём трабл никак не пойму. Как можно определить причину?

Да как бы DNS на AD под Win2k3 и моя виндовая раб.(очень точное сокращение :-)) станция все пингует нормально.

Но я уже разобрался: забыл про

domain domain.local вместо search local

А то что инет адреса не пингуются это заморочки с форвардингом к DNS провов.

Так что всем спасибо, проблема решена.

ну так
dig domain.local что пишет?
лучше использовать search domain.local local
всё должно быть, если настроено нормально

с винды для тестов nslookup

>Как можно определить причину?
dig domain.local +qr +search +recurse +showsearch
как-то так

search local nameserver 192.168.0.14

чо, так в одну строку и прописано? nameserver с новой строки надо.

nslookup нормально срабатывает при любой форме записи.

Видимо это какие-то недоработки утилиты ping.

если хочется как есть, то писать надо ping domain.local. с последней точкой, вроде так должно работать

Проверил, не работает. 🙂

Ну сделай strace ping chmz.local, и посмотри, чего ему не хватает

по ип пингуется?
тогда только tcpdump в помощь и dig с выводом пакетов запроса

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

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

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

А еще я веду телеграм канал Об IT без галстуков и блог. На канале рассказываю о проблемах менеджмента и как их решать, пишу о принципах мышления при решении бизнес задач, о том как стать эффективным и высокоплачиваемым специалистом.

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

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

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

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

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

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

Certain zones should always be present in nameserver configurations:

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

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

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

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

Какой можно сделать вывод из всего написанного?

Ubuntu не резолвит имена

BIND не резолвит неполные имена с WinXP клиента. А полные резолвит. По ip тоже все нормально. Причем с самого сервера все нормально резолвится.
Не могу понять в чем причина.

$TTL 3h
@ IN SOA debrout64.kir.loc. root.kir.loc. (
3
3h
1h
1w
1h)
IN NS debrout64.kir.loc.

debrout64 IN A 192.168.1.100
comp IN A 192.168.1.11

$TTL 3h
@ IN SOA debrout64.kir.loc. root.kir.loc. (
3
3h
1h
1w
1h)
IN NS debrout64.kir.loc.

100 IN PTR debrout64.kir.loc.
11 IN PTR comp.kir.loc.

named-checkconf named-checkzone нормально проходят.

nslookup с сервера:

Name: comp.kir.loc
Address: 192.168.1.11

Читайте также: