Проверка действительности записей ресурсов в зонах DNS

Я использую Perl для выполнения некоторых задач по манипулированию DNS.

Я использую НРД как мой DNS-сервер.

Я хочу выяснить, как лучше всего проверить, действительны ли имена всех записей ресурсов в файле зоны DNS.

Кажется, есть несколько возможностей (которые я могу придумать) для проверки:

nsd-checkzone
Уже сделанный модуль Perl https://metacpan.org/pod/Data::Validate::Domain
Выполните проверку вручную в perl, зная все RFC, описывающие, какое имя является допустимым, а что нет.

Основная проблема, на мой взгляд, возникает, когда речь идет о специальных именах Resource Records.

Например: я видел в Интернете, что есть возможность использовать * в качестве имени записи ресурса:

*                IN A      192.168.150.144

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

Я также видел некоторые "особые" имена записей ресурсов (в зонах обратного DNS), например, в этот RFC:

   192/26          NS      ns.C.domain.
   192/26          NS      some.other.third.name.server.
   0/25            NS      ns.A.domain.
   0/25            NS      some.other.name.server.

Еще у меня есть дополнительный вопрос:

Где я могу увидеть все эти специальные имена записей ресурсов, разрешенные в зонах прямого и обратного DNS, и их значение? (потому что я хочу знать их всех :))

Файлы зоны IMHO - это PITA для манипулирования текстовыми файлами ...

Для начинающих:

каждый RR должен выглядеть name ttl record_class record_type record_data НО :

name можно опустить, и тогда запись наследует поле от предыдущей записи.
ttl может быть опущено и станет значением $TTL
record_class часто также опускается, потому что почти никто не использует что-либо, кроме значения по умолчанию IN

И это только начало ваших проблем.

Особенно, если ваши зоны обслуживались вручную, может быть трудно отличить стенографию от опечаток и действительно хитрых уловок, которые могут сделать записи (даже в большей степени) контекстно-зависимыми. Ваши трудности с синтаксическим анализом могут усугубиться еще больше, если, например, в игру вступят $ -директивы.

Тогда, конечно, также есть разница между файлом зоны с допустимый синтаксис как подтверждено nsd-checkzone или named-checkzone и записи ресурсов, которые семантически действительны и работать по назначению.

Довольно типичный пример - запись CNAME в зоне example.com.

www IN CNAME www.example.net

что верно, но поскольку на www.example.net это не сокращение для полного доменного имени и файла зоны. Значение $ ORIGIN будет добавлено и по умолчанию станет следующим:

www IN CNAME www.example.net.example.com.

Это не всегда дело хотя.
Вместо того, чтобы использовать неявное значение $ ORIGIN или следовать соглашению и явно указывать $ ORIGIN на имя зоны, люди иногда явно определить $ ORIGIN только для . точка.

Снова пример записи CNAME в зоне example.com

$ORIGIN .

www IN CNAME www.example.net

Затем, когда будет добавлено значение $ ORIGIN, которое станет:

www IN CNAME www.example.net.

Это вопросы и ответы - это пример того, как расположение записи MX привело к правильному синтаксису, но повреждению электронной почты.

Этот мой ответ является примером плохой идеи, но допустимого синтаксиса, когда контекст записи ресурса зависит от точной позиции в файле зоны, а эффект сокращения изменится из-за многократного использования / злоупотребления директивой $ ORIGIN $.