named sub domain

Ну та посмотри ЧТО он пытается отресолвить

Подозреваю что nslookup считает, что если в параметре имеется точка то это FQDN и тупо хреначит точку в начале и ресолвит «name.subdomain.» и это (естественно) не ресолвится

Посмотрите что в логах, если ничего то ещё глянте tcpdump на тему какое именно имя оно запрашивает.

По-моему ты пытаешься какую-то ерунду сделать. Пункты 2 и 3 не должны одновременно быть валидными. Даже если оно раньше и работало то это случайно получилось.

Ну и зачем ты nslookup проверяешь собственно? nslookup это совсем не системный резолвинг, это отладочная утилита. Она нигде не должна использоваться кроме как когда ты её вручную вводишь из командной строки.

я раньше считал что строка: search domain.lan тупо прилепляет к имени этот домен, т.е. искать в начале там.

И это работало в cento6 и 7.

nslookup это совсем не системный резолвинг, это отладочная утилита.

да ping к примеру корректно пашет. Но дело в том что я тут ansible перетаскиваю а он начал выдавать фигню, и я выяснил что это из того что не правильно имена компьютеров резолвит.

И точно host и nslookup не пашут. А у меня в моих инвенторях всякие поддоменные компы, написаны именно так, name.subdomain и это много лет работало. И сейчас вон проверяю все пашет на 6ке и 7ке.

А вот в 9ке фиг мне :(

P.S. кстати ssh name.subdomain пашет без проблем.

А у меня в моих инвенторях всякие поддоменные компы, написаны именно так, name.subdomain и это много лет работало.

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

я раньше считал что строка: search domain.lan тупо прилепляет к имени этот домен, т.е. искать в начале там.

Так и есть, только не в начале, а в конце - если не получилось найти без этого суффикса.

да ping к примеру корректно пашет

ping ничего не резолвит сам, это не его задача вообще, он вызывает системную функцию gethostbyname(), которая уже читает resolv.conf и делает всё что надо. Точно то же самое делают и telnet и wget и почти все остальные консольные сетевые утилиты, если ты им даёшь домен вместо ip-адреса.

А вот nslookup сам шлёт днс-запрос и дампит его ответ (и именно почти сырой дамп ответа цель его работы, а вовсе не узнавание айпи-адреса). Вполне логично что у него логика отличается. Хотя я не проверял как он с search взаимодействует.

У тебя в RHEL9 используется systemd-resolved наверняка. Поэтому настраивать надо его, а конкретно:

ResolveUnicastSingleLabel=yes

Пункты 2 и 3 не должны одновременно быть валидными.

Должны. Если прописан нужный search в resolv.conf

subdomain пишется слева от name, если речь именно о сабдомене. Или я что-то сильно не понял в проблеме ТС. Пункт два работать не должен.

Моя внутренняя Ванга исправила ошибки ТСа в голове :)

Я смотрел на этот предмет и вроде это у меня не установлено и не работает.

Всегда это работало, много 10ок лет.

Это какой search вставит что-то в середину доменного имени?

ТС периодически плохо и косноязычно объясняет, я ж выше написал, что наванговал, что он имеет ввиду.

Я начал дампить порт.

С el7 - посылает запрос, получает что нету, прилепляет ему хвост домена и опять отправляет.
С el9 - посылает запрос, получает что нету, и отваливает.
Почему клиент с el9 не шлет второй запрос?

В обоих случаях на клиент первый раз

• посылает: A? name.subdomain. (31)
• возвращается : NXDomain 0/1/0 (106)

(все таки точку прилепляет)

cat /etc/resolv.conf на el9

Э … в первом сообщении.

А, я закономерно подумал, что это из el7 :)

судя по этой заметке: https://access.redhat.com/solutions/7104260
(мне дальше не кажут)

el9 плюет на resolv.conf - совсем. (ни какие параметры от туда видать не юзаются)

el9 плюет на resolv.conf - совсем.

Это врядли.

написано что там по умолчанию 1, т.е. как раз как у меня: name.subdoamin

search Search list for host-name lookup.
    The search list is normally determined from the local domain name; by default, it contains only the local domain name. This may be changed by listing the desired domain search path following the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read options ndots:n below to avoid man-in-the-middle attacks and unnecessary traffic for the root-dns-servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. 
    The search list is currently limited to six domains with a total of 256 characters. 

вот пашет: nslookup -ndots=2 name.subdomain

что раньше подефаульту 2 чтоли было? офигеть.

P.S. Что прикольно, в старых (el6,el7) опция интерфейса: ipv4.dns-search: –

а в el9 уже с доменом: ipv4.dns-search: domain.lan

Это хорошая практика для локальных сетей 70-80 годов, а сейчас 100 байтный пакет ни кто и не заметит, зато мороки меньше

а сейчас 100 байтный пакет ни кто и не заметит

Ну например опсосы округляют до килобайт, например МТС раньше округлял емнип до 70kb, сейчас стал до 100kb. 10 пакетов (не подряд) и уже метр насчитали.