Проверьте что доменные имена успешно резолвятся в ip адреса

>> Добрый день, дорогие друзья.
>> Возникла небольшая проблема.. Не резолвятся некоторые доменные имена, к примеру victoriaclassic.ru.
>> В чем может быть проблема не подскажете, спасибо.
> А каие попытки диагностики были предприняты?

Проверены файлы /etc/resolv.conf на BIND сервере, там стоит ip адрес сервера и localhost.

в /etc/named.conf стоит listen-on port 53 < 127.0.0.1; any; >; listen-on-v6 port 53 < ::1; >;

Server: 127.0.0.1
Address: 127.0.0.1#53

————
QUESTIONS:
victoriaclassic.ru, type = A, > ANSWERS:
AUTHORITY RECORDS:
-> victoriaclassic.ru
origin = ns1.nameself.com
mail addr = support.regtime.net
serial = 1373833282
refresh = 10800
retry = 900
expire = 604800
minimum = 10800
ttl = 8844
ADDITIONAL RECORDS:
————
Non-authoritative answer:
*** Can’t find victoriaclassic.ru: No answer

В чем может быть причина.

]# cat /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

acl «uni-nets» <
79.98.208.0/21;
10.0.0.0/8;
31.15.16.0/21;
31.177.104.0/21;
94.127.176.0/21;
95.174.88.0/21;
>;

options <
version «unilink ns1»;
listen-on port 53 < 127.0.0.1; any; >;
listen-on-v6 port 53 < ::1; >;
directory «/var/named»;
dump-file «/var/named/data/cache_dump.db»;
statistics-file «/var/named/data/named_stats.txt»;
memstatistics-file «/var/named/data/named_mem_stats.txt»;
allow-query < localhost; >;
allow-transfer < 79.98.212.28; 79.98.212.27; >;
recursion yes;
use-v4-udp-ports < range 32768 65535; >;

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file «/etc/named.iscdlv.key»;

logging <
channel default_syslog <
syslog daemon; # send to syslog’s daemon facility
severity warning; # only send priority info and higher
print-severity yes;
>;
channel default_debug <
file «data/named.run» versions 5 size 10M;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
>;

channel default_log <
file «data/default.log» versions 5 size 10M;
severity warning;
print-category yes;
print-severity yes;
print-time yes;
>;

channel notify_log <
file «data/notify.log» versions 5 size 10M;
severity warning;
print-category yes;
print-severity yes;
print-time yes;
>;

channel query_log <
file «data/query.log» versions 5 size 10M;
severity warning;
print-category yes;
print-severity yes;
print-time yes;
>;

channel update_log <
file «data/update.log» versions 5 size 10M;
severity warning;
print-category yes;
print-severity yes;
print-time yes;
>;

category notify <
notify_log;
>;

category update <
update_log;
>;

category queries <
query_log;
>;

category default <
default_log;
>;

view «internal»
<
match-clients < localhost; "uni-nets"; >;
match-destinations < localhost; "uni-nets"; >;
allow-query < localhost; "uni-nets"; >;
recursion yes;
include «/etc/named/local.conf»;
include «/etc/named/rfc1918.conf»;

zone «.» IN <
type hint;
file «named.ca»;
>;

>;
view «external»
<
match-clients < any;>;
match-destinations < any;>;
recursion no;
allow-query < any; >;
allow-query-cache < none; >;
include «/etc/named/local.conf»;

zone «.» IN <
type hint;
file «named.ca»;
>;

>;
#include «/etc/named.rfc1912.zones»;
include «/etc/named.root.key»;

>[оверквотинг удален]
> >;
> allow-query-cache < none; >;
> include «/etc/named/local.conf»;
> zone «.» IN <
> type hint;
> file «named.ca»;
> >;
> >;
> #include «/etc/named.rfc1912.zones»;
> include «/etc/named.root.key»;

Корневые сервера прописаны в /var/named/named.ca

>[оверквотинг удален]
>> include «/etc/named/local.conf»;
>> zone «.» IN <
>> type hint;
>> file «named.ca»;
>> >;
>> >;
>> #include «/etc/named.rfc1912.zones»;
>> include «/etc/named.root.key»;
> Корневые сервера прописаны в /var/named/named.ca
> Кто нибудь может помоч??

>[оверквотинг удален]
>>> zone «.» IN <
>>> type hint;
>>> file «named.ca»;
>>> >;
>>> >;
>>> #include «/etc/named.rfc1912.zones»;
>>> include «/etc/named.root.key»;
>> Корневые сервера прописаны в /var/named/named.ca
>> Кто нибудь может помоч??
> Проблема решилась.

ну походу просто какой-то бородатый список корневых серверов использовал из старых форумов, а потом погуглил, подигал, и все встало. ИМХО.

>[оверквотинг удален]
>>>> type hint;
>>>> file «named.ca»;
>>>> >;
>>>> >;
>>>> #include «/etc/named.rfc1912.zones»;
>>>> include «/etc/named.root.key»;
>>> Корневые сервера прописаны в /var/named/named.ca
>>> Кто нибудь может помоч??
>> Проблема решилась.
> ну и?

У не резолвившегося ip менялся хостинг.

>[оверквотинг удален]
>>>>> file «named.ca»;
>>>>> >;
>>>>> >;
>>>>> #include «/etc/named.rfc1912.zones»;
>>>>> include «/etc/named.root.key»;
>>>> Корневые сервера прописаны в /var/named/named.ca
>>>> Кто нибудь может помоч??
>>> Проблема решилась.
>> ну и?
> У не резолвившегося ip менялся хостинг.

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

>[оверквотинг удален]
>>>>>> >;
>>>>>> #include «/etc/named.rfc1912.zones»;
>>>>>> include «/etc/named.root.key»;
>>>>> Корневые сервера прописаны в /var/named/named.ca
>>>>> Кто нибудь может помоч??
>>>> Проблема решилась.
>>> ну и?
>> У не резолвившегося ip менялся хостинг.
> Я тоже думал так, что не такие корневые серверы, оказалось всё намного
> проще. Спасибо всем за помощь..

Хорошим тоном является все-таки огласить в конце решенной темы в чем была проблема и как ее исправили.

>[оверквотинг удален]
>>>>>>> include «/etc/named.root.key»;
>>>>>> Корневые сервера прописаны в /var/named/named.ca
>>>>>> Кто нибудь может помоч??
>>>>> Проблема решилась.
>>>> ну и?
>>> У не резолвившегося ip менялся хостинг.
>> Я тоже думал так, что не такие корневые серверы, оказалось всё намного
>> проще. Спасибо всем за помощь..
> Хорошим тоном является все-таки огласить в конце решенной темы в чем была
> проблема и как ее исправили.

прошу прощения. пост как-то мимо меня прошел ).

Источник

Чиним резолвинг адресов в VPN-локалке (openconnect) для docker и systemd-resolved

systemd-resolved

Поставил пакеты network-manager-openconnect network-manager-openconnect-gnome
Настроил соединение и оно даже подключилось. Проблема первая, каждый раз когда я подключался снова, он забывал имя пользователя, что раздражает. Я нашел решение и создал
баг. Решение простое, с консоли задаем свое имя в особом виде nmcli con mod prgcvp vpn.secrets ‘form:main:username=yourName’,’save_passwords=yes’
После чего оно будет запомнено. Да, галочку «запомнить пароль» я ставил и пароль он даже запомнил, но вот в тексте галочки про имя пользователя ничего не сказано, так что он честно его забыл 🙂 Напомню, что настройки менеджера лежат в /etc/NetworkManager/system-connections/.

И если параметры знаешь, то можно и руками отредактировать нужное соединение.

Подключаться стало удобно и возникла вторая проблема, имена ресурсов в VPN сети не разрешаются в адреса DNS сервером. Сервер есть, все настройки на месте, но nslookup someserver.local выдает ошибку, а nslookup someserver.local somednsIP выдет правильный ответ. Странно, подумал я, как так, сервер есть, отвечает, а если его конкретно не указать, ошибка? Ответ оказался прост. Когда systemd-resolved пытается найти адрес сервера по имени, он выступает фасадом для других DNS серверов. Делается это так, ссылка /etc/resolv.conf может указывать на несколько мест:

Саму ссылку /etc/resolv.conf вы можете сами настроить что бы смотрела в любое из мест.
Так вот, дело в том, что openconnect при подключении к VPN получает таблицу route, DNS сервера, а так же search domain и этот домен от VPN сервера приходил неверный (так неправильно настроен у нас). От сервера приходило somedomain.local, а надо было просто local что бы somesrver.local был распознан.

Когда systemd-resolved прикинулся локальным DNS сервером и через /etc/resolv.conf всех отправил к себе за разрешением имен, логика его работы такова. Для каждого коннекта, которые можно посмотреть командой nmcli connection show (это те коннекты, которые знает NetworkManager) systemd-resolved помнит DNS сервера, которые получил по DHCP. Это можно посмотреть командой:

Когда в 127.0.0.53 приходит запрос на разрешение имени, systemd-resolved смотрит search domain у каждого из коннектов (эти домены он при подключении от DHCP получил тоже). Домены можно посмотреть командой:

Далее имя хоста проверяется на частичное совпадение с теми доменами, которые прикреплены к коннектам и самое длинное совпадение и определяет какой конкретно DNS сервер вызвать. Либо все идет в DNS сервер где search domain «

От сервера компании мне приходил неверный search domain (somedomain.local) для VPN коннекта и потому когда я пытался разрешить адрес someserver.local, systemd-resolved их не мог найти, так как предполагал, что DNS сервера, полученные из этого соединения нужны что бы распознавать имена someserver.somedomain.local. Поправил я это подменив search domain в NetworkManager командой
nmcli connection modify yourConnectionName ipv4.dns-search «local»
Доменов может быть несколько через пробел. В итоге все заработало.
Помимо этого я удалил пакет avahi-daemon, так как службы bonjur, которые обслуживает этот демон по умолчанию тоже резолвятся на домене local, а в нашей сетке именно это имя используется для локальной сети и будут конфликты.

docker

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

Контейнер запущен с network_mode: host в таком случае будет использоваться для резольвинга то, что лежит в /run/systemd/resolve/resolv.conf и там у меня первый же днс сервер выбирается для резольва local и он для этого не подходит. Итог, не работает. Зато все сервисы хост машины видно из контейнера, что еще и неправильно.

Контейнер запущен с network_mode: bridge с созданием отдельной сети. В таком случае сервисы хоста будет не видно, помимо этого будет использован все тот же не работающий у меня /run/systemd/resolve/resolv.conf

Контейнер запущен без настроек сети и использует дефолтный bridge, созданный докером при инсталляции (docker0). В этом случае используется для резольва имен внутренний докеровский DNS, который судя по всему нормально взаимодействует с systemd-resolved и все резолвит как надо. В /etc/resolv.conf будет такое:

Если надо показать сервисы хост машины для доступа из контейнера, то просто запускаем сервисы слушать на docker0 IP и получаем доступ.

Не забываем открыть порты, например у меня ufw зарезал 8080 и пришлось открывать.
Было бы отлично если бы docker просто использовал systemd-resolved dns stub как в последнем описанном варианте всегда. Но к сожалению это не так. В версии systemd-resolved 248, которая только вышла и в дистрах ее нет в документации есть параметр DNSStubListenerExtra, который может задать адрес где слушать для stub. Подробности тут.

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

Есть другое решение, когда контейнер пойдет на порт 53 мы будем перебрасывать его запросы в стаб systemd с помощью чего то вроде
socat UDP-LISTEN:53,fork,reuseaddr,bind=yourInterfaceIP UDP:127.0.0.53:53
Соответственно, этот DNS можно указать докеру при старте и весь функционал systemd будет работать. Но не стал это использовать.

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

Источник

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

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

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

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

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

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

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

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

В мануале еще пишут про особую логику с обработкой хостнейма _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 покажет список всех адресов которые удалось найти. С такими настройками она выведет следующее:

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

Если убрать из /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.

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

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

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

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

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

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

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

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

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

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

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

Источник

• ← Проверьте что выражение getchar eof действительно равно 1 или 0
• Проверьте что драйвер зарегистрирован в системе 1с →