Откуда берется эта PTR-запись?

Question

[neostickerpack]

Выводы команды dig, ping и nc показывают наличие PTR записи *.*.192.168.lan.quantum.ru для узла сети, данную запись отдает внутренний DNS сервер.
При этом, если резолвить не айпи, а днс имя -- команда выдает корректное значение с суффиксом домена.
В зоне обратных имен пусто.

Comments

[shurshur]

В чём вопрос? На один IP может ссылаться сколько угодно разных доменных имён. Но все их в PTR-записи не внесёшь.

[AUser0]

Если в зоне обратных имен пусто - значит эту запись у себя хранит кто-то ещё.
Ищите NS для 168.192.in-addr.arpa.

[neostickerpack]

shurshur, не понимаю почему запрос по айпи адресу выдает такой суффикс и какая NS запись за это отвечает. Вообще изначально на это пинала поддержка Астры линукс, после выявления ошибки аутентификации в домене MS AD станции под управлением астры.

[neostickerpack]

AUser0, Спасибо за наводку! возможно, есть предположения где и что ее хранит? есть смысл обращаться к провайдеру?

[AUser0]

neostickerpack, предполагать не буду - просто бессмысленно.

[shurshur]

neostickerpack, там всё так же, как и в обычных TLD. Есть зона arpa, зона 2 уровня in-addr.arpa, итд итп.

Можно посмотреть например dig +trace 249.21.88.77.in-addr.arpa.

[neostickerpack]

shurshur,



Я так понимаю, эту PTR отдает DNS сервер провайдера, т.к вместо того чтобы ссылаться сам на себя, он перенаправляет запросы туда..

[neostickerpack]

А вот это оказывается самым непонятным явлением..

[shurshur]

neostickerpack, нет, с ключом +trace это работает не так.

DNS - иерархическая система. Есть зона нулевого уровня . (точка), в ней домены первого уровня, в них домены второго уровня итд.

Обычный DNS-сервер без спецнастройки не знает никакого "DNS провайдера". Тем более что сам "DNS провайдера" как будет тогда работать? Можно поставить себе bind и посмотреть, как он устроен. Собственно, там идёт в поставке файл навроде root.named, в котором перечислены root-сервера. А дальше когда надо узнать xxx.yyy.zzz.com, то у рутсервера NS-запросом выясняется сервер зоны com, у следующего DNS-сервера выясняется сервер зоны zzz.com, итд итп. И зона arpa тоже не исключение. Ну это на пальцах, там есть тоже всякие нюансы.

DNS-сервер может принимать рекурсивные запросы, а может не принимать. В том числе часто настраивают так, что рекурсивные запросы принимаются лишь от доверенных адресов.

Например, пусть есть ns.company.com, у которого разрешены рекурсивные запросы сети 1.2.3.0/24, а остальным нет. При этом на этом сервере держатся зоны company.com и awesomeproduct.io. Тогда доверенным будут разрешены любые запросы, а сторонним - не все:

company.com - разрешён
awesomeproduct.io - разрешён
google.com - запрещён

Благодаря этому все другие DNS-сервера и обычные клиенты с нерекурсивными запросами смогут получать домены компании, но не смогут использовать этот сервер как замену своего обычного DNS-сервера компании/провайдера/гугловосьмёрок/итд.

Что касается указанного случая, то тут обычно бы 192.168.2.3 не ресолвился бы вообще. Но похоже что используется DNS-сервер провайдера quantum.ru, а у него эта зона описана явным образом и возвращает какие-то адреса. При этом если у себя поменять DNS, например, на гугловые воьсмёрки 8.8.8.8, то этот IP перестанет распознаваться (*)

(*) но есть нюанс, некоторые провайдеры искусственно заворачивают "восьмёрки" на свой DNS. Но что мешает для проверки этого использовать DNS Яндекса 77.88.8.8, CF 1.1.1.1, quad9 9.9.9.9, opendns 208.67.222.222 итд итп?

[neostickerpack]

shurshur, спасибо за развернутый ответ!
Провайдер подтвердил, что у него присутствуют PTR-записи для внутренних зон. Подскажите, пожалуйста, как я могу убедиться, что конкретный запрос обрабатывается именно локальным DNS-сервером?
На всех машинах ЛВС прописан локальный DNS, на локальном DNS - localhost.

[neostickerpack]

AUser0,

Вывод поиска с локального DNS..

[shurshur]

neostickerpack, соответственно, нужно выяснить, как этот сервер на localhost настроен. По идее, можно также его настроить под себя, создав на нём такую же зону с нужными себе записями.

У меня вон Mikrotik домашний сам себя в rDNS показывает:

$ host 10.7.8.1 10.7.8.1
Using domain server:
Name: 10.7.8.1
Address: 10.7.8.1#53
Aliases: 

1.8.7.10.in-addr.arpa domain name pointer router.lan.

[AUser0]

neostickerpack, ну вот что и следовало найти. Ваш DNS не отвечает за зону 2.168.192.in-addr.arpa.
Пока он не начнёт отвечать как NS этой зоны - не будет и PRT, указывающих на домены ваших серверов.

P.S. Ах, да, проверьте ещё и nslookup -type=ns 2.168.192.in-addr.arpa

[neostickerpack]

AUser0,


Тоже самое, понял
Пошел настраивать обратную зону, спасибо!

[neostickerpack]

shurshur,
Т.е из-за отсутствия обратной зоны локально, он обращается к зоне провайдера..
Буду настраивать свою, спасибо!!

Answer 1

[Rsa97]

$ dig @j.root-servers.net. in-addr.arpa
in-addr.arpa.		172800	IN	NS	a.in-addr-servers.arpa.

$ dig @a.in-addr-servers.arpa. 192.in-addr.arpa
192.in-addr.arpa.	86400	IN	NS	r.arin.net.

$ dig @r.arin.net. 168.192.in-addr.arpa
168.192.in-addr.arpa.	86400	IN	NS	blackhole-2.iana.org.
168.192.in-addr.arpa.	86400	IN	NS	blackhole-1.iana.org.

То есть, стандартный путь ведёт в чёрную дыру IANA, специальный сервер для несуществующих записей.
Зона 192.168.0.0/16 предназначена исключительно для локальных сетей и PTR для неё должен держать локальный DNS-сервер. Если у вас используется DNS-сервер провайдера, то, скорее всего, он и держит у себя локальные PTR'ы.

Comments

[neostickerpack]

Пообщался с провайдером, он их действительно держит для внутренних зон, НО
Я не использую DNS провайдера. На сетевом интерфейсе локального DNS-сервере строго прописано "localhost".

[Rsa97]

neostickerpack, DNS-сервер провайдер может быть настроен форвардером вашего локального DNS-сервера. Или провайдер перехватывает ваши DNS-запросы и даёт свои ответы.

[neostickerpack]

Rsa97, А как мне проконтролировать этот момент? или же просить провайдера удалить PTR-ы для внутренней зоны?

[Rsa97]

neostickerpack, А чем вам эти PTR'ы мешают?

[neostickerpack]

Rsa97, Ответ от поддержки Астры линукс по ошибке аутентификации машины в домен MS AD.

"По приложенным снимкам видно, что в настройках обратной зоны для указателя 192.168.2.3 установлено значение 3.2.192.168.lan.quantum.ru:

Для корректной авторизации пользователя в домене MS AD службе sssd требуется корректная запись DNS контролера домена MS AD в обратной зоне, либо ее отсутствие."

Понятно, впоследствии будет развернута FreeIPA (аналоги), но хотел для себя разобраться и решить этот косяк.

Плюсом совершенно некрасиво выглядит, когда половина машин имеют сетевые имена заданные вручную типа "WS-****", а половина *.*.192.168.lan.quantum.ru.

[Rsa97]

neostickerpack, Тогда вам надо не у провайдера удалять записи, а свой сервер настраивать мастером для зоны 2.168.192.in-addr.arpa, в которой и будут ваши PTR-записи.

[neostickerpack]

Rsa97, буду разбираться, спасибо!