Можно ли собирать IP-адреса домена .local для построения DNS на основе dhcp? - PullRequest
Новая
       78

Можно ли собирать IP-адреса домена .local для построения DNS на основе dhcp?

0 голосов
/ 09 марта 2011

Предположим, вы находитесь в обычной среде DHCP,

Вы получите IP-адрес, например:

  • 192.168.0.101 для linuxpc1.localdomain в сегменте A
  • 192.168.1.102 для linuxpc2.localdomain в сегменте B

Я хочу посмотреть их, только установив avahi на тех linuxpcs с установленным именем хоста.

Итак, 192.168.2.103 linuxpc3.localdomain, работающий 

ping linuxpc1.local

будет работать.

Какой самый простой способ реализовать это, не затрагивая настройки сервера DHCP?

Или, если это сложно, по крайней мере, яхотел бы знать IP-адрес для имени, запускающего сценарий с хоста linuxpc3.localdomain. 

getipbyname-avahi.py linuxpc1.local
-> returns 192.168.0.101

Я не хочу настраивать NIS, LDAP или SQL ... Я думал, что повторно использовать возможность разрешения avahi для разрешенияIP-адрес dhcped хорош для начала.

Ответы [ 2 ]

2 голосов
/ 10 марта 2011

Почему бы просто не включить обновления DNS в DHCP?

Что-то вроде 

ddns-updates                on;
ddns-update-style           interim;
ddns-domainname             "network.athome.";
ddns-rev-domainname         "in-addr.arpa.";

в вашем dhcpd.conf (я предполагаю, что вы используете ISC), и он обновит DNS.

Если вы не можете изменить конфигурацию dhcp, возможно, вы можете использовать nsupdate в хуке клиентского скрипта.

0 голосов
/ 09 марта 2011

Возможное решение (или я должен сказать kludge).
Единственный способ добиться этого - расширить маску сети до 255.255.0.0 (маска сети класса B) для всех блоков linuxpc.
Однако вам придется сделать это на DHCP-сервере, точно так же, как вы настраиваете, что mac-адресу linuxpc1 eth0 будет присвоен IP-адрес 192.168.0.101.
Это означает объединение всех ваших частных подсетей класса C в один блок класса B.

Деталь
В противном случае, я не думаю, что вы можете сделать это с avahi прямо из коробки. Вот почему.

Avahi использует mDNS для публикации имен хостов.

В деталях все работает так:
В рамках этой логики обработки демон avahi вашего linuxpc3 будет отправлять дейтаграмму DNS UDP на порт 5353 (?) По IP-адресу 224.0.0.51.
Этот адрес является одним из многоадресных адресов, зарезервированных для zeroconf (см. iana multicast address ).

Если предположить, что адрес linuxpc3 равен 192.168.2.103 (в соответствии с вашим соглашением об именах), и при условии, что стандартная сетевая маска класса C равна 255.255.255.0, то только те поля с адресами между 192.168.2.1 и 192.168.2.254 получат соответствующий DNS A обновить запись (под которой я подразумеваю других демонов avahi / bonjour, работающих в этих полях).

В результате ни linuxpc1, ни linuxpc2 не узнают о паре имя-адрес / адрес хоста linuxpc3.local.

Если вместо этого маска сети всех этих блоков расширена до 255.255.0.0, то диапазон широковещания будет расширен, чтобы включить все адреса в сети 192.168 / 16.

RFC1918 , стандарт для частных сетей , явно разрешает конфигурировать блок 192.168.0.0 как одну подсеть класса B.

Обновление
Увидев ваши комментарии.

Первый вывод. У Avahi нет решения для вашей комбинации требований.
Avahi полагается на передачу в подсети.

В аналогичном контексте, в котором avahi также не был применим, я однажды прибегнул к автоматическому обновлению файлов / etc / hosts и записей DNS посредством обнаружения изменений событий подключения.

Все ПК могли видеть Интернет и обнаруживали изменения соединения (Linux в Диспетчер NetworkManager перехватывает - Windows через подписку на Служба уведомлений о системных событиях ).

Все машины сообщали о своем состоянии подключения и IP-адресах через сообщения на сайте www.dropbox.com и получали свои обновления из соответствующей локальной папки Dropbox.

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

...