Что означает “Нет доступного авторитета на делегировании”? (или NS запись не возвращена DNS)

Я владею доменом (в дальнейшем именуемым example.com), он зарегистрирован в OVH. У него есть несколько записей A и MX, все они обслуживаются корректно DNS-серверами OVH.

Теперь я хочу делегировать home.example.com на домашний сервер (PiHole) на 192.168.10.2. Этот DNS-сервер работает и корректно обслуживает многие записи.

Чтобы делегировать подсеть, я добавил следующее в DNS-зону example.com:

home           IN NS    ns-home.example.com.
ns-home        IN A     192.168.10.2

OVH автоматически увеличивает серийный номер зоны. Чтобы убедиться, что он правильный, я проверил это:

root@srv ~# dig @1.1.1.1 example.com SOA

example.com. 3600 IN SOA dns102.ovh.net. tech.ovh.net. 2024122001 86400 3600 3600000 60

2024122001 – это то, что я также вижу в DNS-зоне на OVH. Значит, новая версия зоны была развернута.

Проблема: запись A возвращается корректно, но NS – нет:

root@srv ~# dig @1.1.1.1 ns-home.example.com A
ns-home.example.com. 3600 IN A 192.168.10.2

dig @1.1.1.1 home.example.com NS
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation home.example.com.)
;; QUESTION SECTION:
;home.example.com.               IN      NS

Что означает этот ответ? Что еще нужно сделать для делегирования подсети?

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

Запрос, который вы сделали для NS, был рекурсивным¹; это означает, что ответ не поступал из записей делегирования на OVH – он на самом деле будет следовать за делегированием вплоть до возвращения записей NS из вашей PiHole.

Но записи NS делегирования указывают на частный IP-адрес, 192.168.10.2, к которому разрешатель CloudFlare 1.1.1.1 не может получить доступ – поэтому он никогда не сможет разрешить ничего за пределами этой делегации, как и любой другой публичный разрешатель. Вот что означает второй ответ; это означает “1.1.1.1 не смог связаться с ‘ns-home.example.com’ по адресу 192.168.10.2” (ns-home является “авторитетом”).

Имейте в виду: сервер, который вы указываете с помощью @, – это не просто “начальная точка” для dig; это сервер, который делает все преследование делегирования за вас, в то время как сам dig просто ждет ответа – так же, как ваша операционная система обрабатывает DNS-запросы.

Таким образом, недостаточно, чтобы делегации имели записи A/AAAA, доступные с точки зрения клиента, они также должны быть доступны с точки зрения разрешателя.

Поэтому, если вы абсолютно уверены, что разрешатель будет внутренним для вашей сети (например, если ваши ПК все запрашивают ваш локальный PiHole, и PiHole работает на Unbound или BIND9, чтобы локально отслеживать делегирования, не полагаясь на внешние), – тогда да, ваша текущая настройка будет работать, но вы должны протестировать это с dig @<pihole_ip>, а не с dig @<random_public_resolver>.

Тем не менее, если вы хотите, чтобы делегированная подсеть (и ее подподсети) были разрешимы с помощью любого публичного сервера, тогда делегация должна быть сделана на общедоступный IP-адрес. Вам нужно будет проверить, какое DNS-программное обеспечение использует PiHole, подходит ли оно для раскрытия в Интернете (т.е. оценка безопасности), настроить “портовый переадресации” для TCP/53 и UDP/53 с вашего основного шлюза LAN на PiHole (для IPv4), и наконец, изменить запись ns-home A/AAAA так, чтобы она указывала на ваш публичный IPv4-адрес (и/или публичный IPv6 вашего PiHole).

¹ Запрос имел установленный параметр “Рекурсия желательна”, что по умолчанию для dig, и это также единственный способ, которым вы получите ответ от 1.1.1.1 или другого разрешателя.

Отключить этот параметр можно с помощью +norecurse или +nordflag, но рекурсивный запрос должен быть сделан непосредственно к авторитетным серверам – т.е. серверам, которые уже держат DNS-данные для вашего домена. И если вы скажете ‘dig’ запрашивать на авторитетном сервере… тогда указание +norecurse становится несколько избыточным.

Поэтому, если вы хотите протестировать, была ли корректно опубликована ваша запись NS в OVH, вам нужно сделать:

dig [+norecurse] @nsXXX.ovh.net home.example.com NS

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

• dnstracer -s . home.example.com
• delv [-i] +ns home.example.com
  (опция -i подавляет валидацию DNSSEC для более минимального вывода)
• dig +trace home.example.com
  (может быть менее точным)
• DNSViz.