Как стать автором
Обновить

Комментарии 16

Стоит отметить, что некоторые приложения, например, написанные на Go, могут полностью обходить glibc/musl и использовать собственные DNS-резолверы.

в Go вообще черная магия. Там есть 2 ресолвера - один написанный на Go, который парсит /etc/resolv.conf, и другой, который вызывает getaddrinfo через Cgo. Выбирается один из этих двух примерно так:

When cgo is available, the cgo-based resolver is used instead under a variety of conditions: on systems that do not let programs make direct DNS requests (OS X), when the LOCALDOMAIN environment variable is present (even if empty), when the RES_OPTIONS or HOSTALIASES environment variable is non-empty, when the ASR_CONFIG environment variable is non-empty (OpenBSD only), when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement.

The resolver decision can be overridden by setting the netdns value of the GODEBUG environment variable (see package runtime) to go or cgo

The decision can also be forced while building the Go source tree by setting the netgo or netcgo build tag. The netgo build tag disables entirely the use of the native (CGO) resolver, meaning the Go resolver is the only one that can be used. With the netcgo build tag the native and the pure Go resolver are compiled into the binary, but the native (CGO) resolver is preferred over the Go resolver. With netcgo, the Go resolver can still be forced at runtime with GODEBUG=netdns=go

как говорится, удачной отладки))

Здравствуйте. А вот допустим есть DNS сервер на Linux, BIND.

У него прописаны DNS гугла и яндекса.

Как я могу узнать, с помощью какого адреса я делаю разрешение в данный момент ?

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

Спасибо Вам большое. Обождем. Я смотрел в tcpdump, но не нашел, буду ждать следующую серию Ваших статей. Благодарю !

Прошли старые добрые времена, когда все было понятно в /etc/resolv.conf, теперь там отправляют в nameserver 127.0.0.53 и пишут "DO NOT EDIT THIS FILE BY HAND"

И про это ни слова в статье.

Про это обязательно будет в одной из следующих частей

Непонятно в чем проблема. В статье есть пример nameserver 192.168.1.1 , почему, находящийся неизвестно где, 192.168.1.1 вопросов не вызывает, а 127.0.0.53, который весь ваш, вдруг непонятно?

А "не редактируйте руками" обычно означает, что файл создаётся автоматически, и исправления будут потеряны при следующей перезаписи.

Проделки sysemd-resolved. Ох и намучался я с ним и так и не победил. Задача была включить разрешение имен через mDNS. В инструкциях написано, что должно быть включено глобально на интерфейсе, глобально в sysemd-resolved, и локально на интерфейсе в sysemd-resolved. Везде все включил, а оно не разрешает имя ни в какую. Подозрение упало на установленный компонент от avahi требуемый в far2l. Вероятно sysemd-resolved видит присутствие обрезка avahi и пытается не лезть. Плюнул.

А это второй уровень абстракции, здесь описано только чтение из resolv.conf.

таких как libnss_dns.so, libnss_files.so, libnss_myhostname.so и других.


Зачем эти ссылки?

P.S. Стандартный механизм сообщений об ошибках не работает, так как `Пользователь rearranged запретил личные сообщения` 🤷‍♂️

спасибо, что заметили, поправим

Оно наверное не случайно всё, но выглядит как пере- или недоинжиниринг. Вроде и задача не то что бы сложная, но реализация удручает, вернее реализациИ, или даже «потому и реализациИ»

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

Здравствуйте, уважаемый автор!Спасибо за статью, узнал новое про резолвинг в легковесных окружениях. Что касается "классики" в статье есть серьезный пробел в описании механизма NSS и настроек nsswitch.conf. В полном формате конфигурация также содержит описание действий каждого плагина резолвера, после его вызова для сервиса. Например:

hosts: dns [!UNAVAIL=return] files

An action may also be specified following a service specification. The action modifies the behavior following a result obtained from the preceding data source. Action items take the general form: [STATUS=ACTION] [!STATUS=ACTION] where STATUS => success | notfound | unavail | tryagain ACTION => return | continue | merge

Из https://www.man7.org/linux/man-pages/man5/nsswitch.conf.5.html

На мой взгляд этот функционал существенно расширяет возможности настройки системного резолвера Линукс и без его упоминания описание механизма будет неполным.

Да, хотелось бы какой-то живой практически понятный пример, ради чего (а главное - кому, поименно) это потребовалось? Ну все же было хорошо вроде. Вот resolv.conf, вот в нем адрес сервера, а вон в серверной сам тот DNS сервер стоит. Просто, логично, понятно. Абсолютно необходимый минимум сложности (меньше - только автоконфигурации, но там свои сложности). В общем "раньше было лучше".

А сейчас нафиговертили такое, что даже не очень понятно, как домашний ноутбук работает. Особенно, когда какая-нибудь кривая DNS запись показывается. Это на удаленном резолвере она? Или на локальном? Чтобы узнать, на локальном ли, надо, сначала, узнать, что локальных резолверов может быть несколько видов, разобраться, как опознавать каждый и проверить (для начала), какой у тебя, как он настроен.... при этом конфиги do not edit by hand и какая-то сущность в виде гномика их перезаписывает.

Да, со всем этим можно разобраться, но ведь раньше-то как-то работало, даже у меня, хотя степень извращенности моих сетевых настроек бывает сложнее чем у 95% точно.

А еще гадость, что это все постоянно меняется! Ты в какой-то момент идешь на принцип - "как так, я не знаю, как резолвит мой комп? Не устраивает! Буду сидеть и разбираться, пока не разберусь! Лучше раз разобраться, зато потом всю жизнь понимать!". Сидишь, уперся, разбираешься с тем, что еще недально было простым до боли в пятках. Разобрался. Проходит 5 лет - все уже по другому сделали. Еще сильнее усложнили, а твои прежние "знания" - не помогают, наоборот, они перешли в категорию "устаревшие заблуждения".

У меня есть смутное ощущение что это все требуется в 0.001% случаев, а во всех остальных - это работает так же, как работал бы старый добрый resolv.conf, но непонятнее.

Я бы еще понял, если бы было два резолвера. Простой и сложный. У всех по дефолту - простой. Когда нужны извращения - ставишь себе сложный. Но нет, даже в домашнем линуксе и на VPSке с наипримитивнейшими настройками - какой-то рокетсайнс накручен вокруг банальнейшей задачи успешно решенной в 1980ых.

Усложнять - легко, упрощать - сложно.

А как-же C-ARES от curl? ;)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий