Рейтинг:0

ISC-DHCP и BIND 9 DNS: сбой обновления DDNS для подсети /27

флаг ph

У меня проблема с обновлением DDNS с сервером ISC-DHCP.

Мой раздел подсети /etc/dhcp/dhcpd.conf, который не работает:

подсеть 193.198.186.192 сетевая маска 255.255.255.224 {
  диапазон 193.198.186.200 193.198.186.222; № МТ 20211210
  опция маска подсети 255.255.255.224;
  вариант доменных имен-серверов 161.53.235.3, 161.53.2.70;
  вариант доменного имени "slava.alu.hr";
  ddns-имя домена "slava.alu.hr";
  зона слава.алу.хр. {
   основной 127.0.0.1;
   ключ DDNS_UPDATE;
  }
  зона 192-27.186.198.193.в-адрес.арпа. {
   основной 127.0.0.1;
   ключ DDNS_UPDATE;
  }
  широковещательный адрес опции 193.198.186.223;
  опциональные роутеры 193.198.186.193;
  время аренды по умолчанию 43200;
  максимальное время аренды 86400;
}

Мое сетевое делегирование для моего 193.198.186.192/27 — это буквально 192/27.186.198.193.in-addr.arpa. и они не кажутся желающими изменить это.

Глянь сюда:

root@domac:~# host -t любой 193.198.186.195
195.186.198.193.in-addr.arpa — это псевдоним для 195.192/27.186.198.193.in-addr.arpa.
195.192/27.186.198.193.in-addr.arpa указатель доменного имени test-record.slava.alu.hr.
root@domac:~#

Это требует от моей записи /etc/bind/named.conf.local:

зона "192/27.186.198.193.in-addr.arpa" в {
        тип мастер;
        файл "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
        разрешить обновление {ключ DDNS_UPDATE; };
};

Однако ISC DHCPd считает «/» в имени зоны синтаксической ошибкой.

Есть ли способ указать BIND или ISC DHCPd принимать разные имена в объявлениях зон /etc/bind/named.conf.local и /etc/dhcp/dhcpd.conf?

Когда я изменяю объявление в dhcpd.conf на:

  зона 186.198.193.in-addr.arpa. {
   основной 127.0.0.1;
   ключ DDNS_UPDATE;
  }

и /etc/bind/named.conf.local запись в:

зона "186.198.193.in-addr.arpa" в {
        тип мастер;
        файл "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
        разрешить обновление {ключ DDNS_UPDATE; };
};

тогда работает динамическое обновление DHCPd:

10 декабря 15:42:59 domac dhcpd[11512]: DHCPREQUEST для 193.198.186.211 от e8:48:b8:5b:8c:46 (НОУТБУК-МТОДОРОВ) через 193.198.186.193
10 декабря 15:42:59 domac dhcpd[11512]: DHCPACK от 193.198.186.211 до e8:48:b8:5b:8c:46 (НОУТБУК-МТОДОРОВ) через 193.198.186.193
10 декабря 15:42:59 domac dhcpd[11512]: добавлена ​​новая карта переадресации от LAPTOP-MTODOROV.slava.alu.hr до 193.198.186.211
10 декабря 15:42:59 domac dhcpd[11512]: добавлена ​​обратная карта из 211.186.198.193.in-addr.arpa. на НОУТ-МТОДОРОВ.slava.alu.hr

и я вижу это из области моего DNS-сервера:

root@domac:~# хост-ноутбук-mtodorov.slava.alu.hr
LAPTOP-MTODOROV.slava.alu.hr имеет адрес 193.198.186.211
root@domac:~# host -t любой 193.198.186.211
211.186.198.193.in-addr.arpa доменное имя указатель LAPTOP-MTODOROV.slava.alu.hr.
root@domac:~#

... но теперь делегирование DNS нарушено. У меня не может быть всего 186.198.193.in-addr.arpa. зону для подсети нашего домена, и они также не будут одобрять динамические обновления на центральном DNS-сервере.

У меня не может быть обоих, если только нет способа указать DHCP или BIND добавить в зону с другим именем в BIND, чем в DHCP.

Кажется, у меня заканчиваются варианты.

Большое спасибо, если знаете ответ.

С уважением, Марвин

P.S.

Я пробовал следующее, и это не сработало:

зона "192-27.186.198.193.in-addr.arpa" в {
        тип мастер;
        файл "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
};

зона "186.198.193.in-addr.arpa" в {
        тип мастер;
        файл "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
        разрешить обновление {ключ DDNS_UPDATE; };
};

(Две зоны с одним и тем же файлом.)

Что я получил:

root@domac:/etc/bind# named-checkconf
/etc/bind/named.conf.local:49: доступный для записи файл '/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': уже используется: /etc/bind/named.conf .локальный: 44
root@domac:/etc/bind#

Хорошая попытка :-( Программисты были достаточно умны, чтобы предотвратить этот взлом!

Любая идея, как сделать так, чтобы две зоны ссылались на одну и ту же базу данных зон, одна из которых соответствовала бы назначенной зоне делегирования, а другая соответствовала бы 186.198.193.in-addr.arpa зону, которую ISC DHCP умеет только обновлять?

  1. Я даже пытался заключить 192/27.186.198.193.in-addr.arpa в кавычках, чтобы избежать синтаксической ошибки, и я получил это:

    10 декабря 23:17:45 domac dhcpd[26555]: /etc/dhcp/dhcpd.conf строка 187: ожидается имя хоста. 10 декабря 23:17:45 domac isc-dhcp-server[26545]: /etc/dhcp/dhcpd.conf строка 187: ожидается имя хоста. 10 декабря 23:17:45 domac isc-dhcp-server[26545]: зона «192/27.186.198.193.in-addr.arpa». 10 декабря 23:17:45 domac isc-dhcp-server[26545]: ^ 10 декабря, 23:17:45 domac isc-dhcp-server[26545]: обнаружены ошибки файла конфигурации — выход 10 декабря 23:17:45 domac isc-dhcp-server[26545]: выход. 10 декабря 23:17:45 domac dhcpd[26555]: зона "192/27.186.198.193.in-addr.arpa."

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

Марвин

Patrick Mevzek avatar
флаг cn
Снова см. RFC2317 для бесклассового делегирования in-addr.arpa. Только записи CNAME должны иметь имена с `/`, которые в таком случае допустимы для CNAME, но на самом деле недействительны для NS (делегирования). Если у вас есть CNAME для 129.128/26.2.0.192.in-addr.arpa, зона для делегирования — 2.0.192.in-addr.arpa. Так что в вашем случае делегирование должно быть для 186.198.193. .in-addr.arpa`, а не `192/27.186.198.193.in-addr.arpa`, а затем, конечно же, настроить в нем записи ресурсов.
mt42 avatar
флаг ph
Я понял, что DHCP хочет обновить `186.198.193.in-addr.arpa` и не может синтаксически обрабатывать `192/27.186.198.193.in-addr.arpa`. Но мне делегировали `192/27.186.198.193.in-addr.arpa` от администраторов верхнего уровня, и я не могу это изменить. Я также не могу динамически обновлять эту зону. Я подумал о двух именах зон, совместно использующих одну и ту же базу данных файлов ... Одна зона определена для делегирования и только для чтения, а другая - для обновлений DDNS от DHCP с той же базой данных. Позволит ли BIND 9.1.5 такой взлом? Читаю справку по BIND, но такого случая не появилось...
mt42 avatar
флаг ph
Я не могу динамически или иным образом обновлять `186.198.193.in-addr.arpa`, поскольку я не владелец и мне не разрешено динамическое обновление этой зоны. Он используется несколькими организациями. Я должен думать об обходном пути. Это проблема, потому что общедоступные IP-адреса, отличные от NAT, назначаются через NAT.
mt42 avatar
флаг ph
Мне также делегирован `192/27.186.198.193.in-addr.arpa` с верхнего уровня, и я тоже не могу это изменить. Я должен подумать об использовании обоих имен для одних и тех же данных зоны, одно только для чтения, а другое динамически обновляется ISC DHCP.
Patrick Mevzek avatar
флаг cn
«Я не могу динамически или иным образом обновлять 186.198.193.in-addr.arpa, поскольку я не владелец и мне не разрешено динамическое обновление этой зоны. Она используется несколькими организациями». Это именно то, с чем имеет дело RFC2317. Посмотри на это.
Patrick Mevzek avatar
флаг cn
Также вы можете использовать любое имя зоны и заменить `/` на `-`, если это проще для вашего случая использования. Это прописано в RFC: в примерах здесь используется «/», потому что это кажется более заметным и педантичные рецензенты посчитали, что аргумент «это не имена хостов» нужно было повторить. Советуем не быть столь педантичными и не точно копировать приведенные выше примеры, например. заменить более консервативный символ, например дефис, вместо "/". . Обратите внимание на «не имена хостов», так что это объясняет, почему вы не можете использовать их в качестве имен хостов позже, это специально.
Patrick Mevzek avatar
флаг cn
«Я подумал о двух именах зон, совместно использующих одну и ту же базу данных файлов…» Можно, но не с динамическими обновлениями.
mt42 avatar
флаг ph
Пока не появится лучшее решение, я использовал обходной путь, описанный здесь: https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update. Все равно спасибо, Патрик!
mt42 avatar
флаг ph
Я полностью прочитал RFC 2317, но мне не принадлежит зона делегирования, поэтому я не могу изменить или заменить `/` на `-`. Мне пришлось динамически обновлять вспомогательную зону и делегировать записи CNAME из делегированной зоны в динамически обновляемую вспомогательную зону. Но это обходной путь и уловка. Резолверы иногда путают с несколькими перенаправлениями CNAME. Реальным решением было бы обновить источник DHCP, чтобы добавить директиву псевдонима зоны (в кавычках, чтобы он мог синтаксически обрабатывать `/`), чтобы он мог обновлять зоны, такие как `192/27.186.198.193.in-addr.arpa`.
mt42 avatar
флаг ph
Директива псевдонима зоны - это просто мысль, которая возникла, подойдет любой метод обновления подсетей sub / 24 :-)

Ответить или комментировать

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