Зачем выполнение авторитетного dnsmasq нарушает разрешение CNAME?
У меня есть CNAME , настроенный в dnsmasq как
cname=ch1-lampe-bureau.swtk.info,switch-3
. Он разрешен правильно ( switch-3 - это устройство, которое получает свой IP-адрес через DHCP от dnsmasq) :
root@rpi1 ~# host switch-3
switch-3 has address 10.200.0.123
root@rpi1 ~# host ch1-lampe-bureau.swtk.info
ch1-lampe-bureau.swtk.info is an alias for switch-3.
switch-3 has address 10.200.0.123
Затем я хотел сделать dnsmasq авторитетным для моего домена, добавив
auth-zone=swtk.info
auth-server=rpi1.swtk.info
auth-peer=192.168.0.13
Зональный перенос, он работает: 192.168.0.13 может передавать зону.
Но разрешение ] CNAME остановлено. Я все еще могу разрешить записи A (например, switch-3 выше), CNAME - нет.
root@rpi1 ~# host switch-3
switch-3 has address 10.200.0.123
root@rpi1 ~# host ch1-lampe-bureau.swtk.info
Host ch1-lampe-bureau.swtk.info not found: 3(NXDOMAIN)
Какова связь между авторитетностью dnsmasq и его способность разрешать свои CNAME s?
Примечание: это внутренний DNS, не имеющий отношения к домену swtk.info , зарегистрированному извне.
Такое поведение, кажется, сильно dnsmasq - специфично, на самом деле не очевидно, как следовать этому с точки зрения DNS.
.
На мой взгляд, было бы целесообразно рассмотреть вопрос о создании "реального" сервера имен (и тогда вместо него будет актуальным общепринятое понимание DNS), но это, несомненно, сделает настройку менее интегрированной.
Я сам не являюсь пользователем dnsmasq, но мне кажется, что следующий раздел из dnsmasq руководства объясняет его поведение и требования в этом сценарии (курсив добавлен):
Когда dnsmasq настроен на работу в качестве авторитетного сервера, то Для заполнения авторитетной зоны используются следующие данные:
--mx-host, --srv-host, --dns-rr, --txt-record, --naptr-record, --caa-record, пока имена записей находятся в авторитетном домене.
--cname, пока имя записи находится в авторитетном домене. Если цель CNAME не квалифицирована, то она квалифицируется с помощью параметра авторитетное имя зоны. CNAME, используемое таким образом (только) может быть подстановочные знаки, как в
--cname=*.example.com,default.example.com IPv4 и IPv6 адреса из /etc/hosts (и --addn-hosts ) и --хост-запись и -интерфейс-имя при условии, что адрес попадает в одну из подсетей, указанных в --auth-зоне.
Адреса арендованных DHCP, при условии, что адрес попадает в одну из подсети, указанные в --auth-зоне. (Если построены DHCP-диапазоны, это это использование, которое зависит от адреса, динамически назначенного на интерфейс, затем форма --auth-зона, определяющая подсети по для обеспечения этого следует использовать динамический адрес интерфейса. условие выполняется.)
В режиме по умолчанию, когда аренда DHCP имеет безоговорочное имя и возможно, квалифицированное имя, построенное с использованием -домена, затем имя в авторитетная зона построена из безоговорочного названия и домена зоны. Это может быть или не быть равнозначно тому, что указано в -домен. Если установлено --dhcp-fqdn, то используются полностью квалифицированные имена, связанные с DHCP-арендой, и они должны совпадать с именами зоны domain.
Ie, основываясь на вышеприведенном разделе их руководства, я понимаю, что ваше cname=ch1-lampe-bureau.swtk.info,switch-3 означает ch1-lampe-bureau.swtk.info. CNAME-переключатель-3.swtk.info..
Кроме того, оказывается, что имена, зарегистрированные с DHCP, добавляются только с именами внутри зоны auth, если auth-зона=... также указывает подсеть, совпадающую с их IP-адресом. (согласно --auth-zone=<домен>[,<подсеть>[/<префиксная длина>]][,<подсеть>[/<префиксная длина>].....][,исключить:<подсеть>[/<префиксная длина>]].....])
Итак, в настоящее время switch-3.swtk.info. вероятно, не существует, но если вы укажете соответствующую подсеть для вашей зоны, то должно появиться это имя, и тогда -имя также должно заработать.