Назад | Перейти на главную страницу

Почему авторитетный 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 можно перенести зону.

Но разрешение CNAMEs остановился. Я все еще могу решить A записи (switch-3 выше, например), CNAMEs нет.

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с?

Примечание: это внутренний DNS, не имеющий отношения к swtk.info домен зарегистрирован извне.

Такое поведение кажется очень dnsmasq-specific, действительно не очевидно, как это проследить с точки зрения 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) и --host-record и --interface-name при условии, что адрес попадает в один подсетей, указанных в --auth-zone.

Адреса аренды DHCP при условии, что адрес попадает в одну из подсетей, указанных в --auth-zone. (Если используются сконструированные диапазоны DHCP, которые зависят от адреса, динамически назначаемого интерфейсу, тогда для обеспечения выполнения этого условия следует использовать форму --auth-zone, которая определяет подсети по динамическому адресу интерфейса.)

В режиме по умолчанию, когда аренда DHCP имеет неквалифицированное имя и, возможно, полное имя, созданное с использованием --domain, тогда имя в авторитетной зоне создается из неполного имени и домена зоны. Это может или не может быть равным указанному в --domain. Если задано --dhcp-fqdn, то используются полные имена, связанные с арендой DHCP, и они должны соответствовать домену зоны.

Т.е., исходя из приведенного выше раздела их руководства, я понимаю, что ваш cname=ch1-lampe-bureau.swtk.info,switch-3 средства ch1-lampe-bureau.swtk.info. CNAME switch-3.swtk.info..

Кроме того, похоже, что имена, зарегистрированные с DHCP, добавляются только с именами внутри зоны аутентификации, если auth-zone=... также указывает подсеть, соответствующую назначенному им IP-адресу. (согласно --auth-zone=<domain>[,<subnet>[/<prefix length>][,<subnet>[/<prefix length>].....][,exclude:<subnet>[/<prefix length>]].....])

Так что в настоящее время switch-3.swtk.info. вероятно, не существует, но если вы укажете соответствующую подсеть для своей зоны, это имя должно появиться, после чего --cname тоже должен начать работать.