Is it possible to collect .local domain ip addresses hierarchically for building dhcp based dns?

Question

Suppose you are in normal dhcp environment,

You'll get an ip address like:

192.168.0.101 for linuxpc1.localdomain on segment A
192.168.1.102 for linuxpc2.localdomain on segment B

I want to look them up by only installing avahi on those linuxpcs with hostname set.

So on 192.168.2.103 linuxpc3.localdomain, running

ping linuxpc1.local

would work.

What is the easiest way realizing this not affecting the dhcp server settings?

Or if this is difficult, at least I would want to know the ip address for the name running a script from linuxpc3.localdomain host.

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

I don't want to setup NIS or LDAP or SQL ... I thought reusing avahi capability of resolving dhcped ip address is good to start.

There is something like this http://ileech.sourceforge.net/index.php?content=RendezvousProxy — holmes, Mar 09 '11 at 04:33
I don't know if this helps and I want something more generic and builtin, which should be more robust. — holmes, Mar 09 '11 at 04:36
Of course NIS/LDAP should be the way to go, but that setup was too tough for me. I wanted something lighter, so one host registers to a known server (DNS fqdn available), that server just collects any sub segment network's .local names gathered by avahi. Then if you point the known server as the nameserver, you could look them up by names. — holmes, Mar 09 '11 at 04:41
So I can just create some scripts to do this, but is it sure no one has done all this kind of thing? — holmes, Mar 09 '11 at 04:42

score 2 · Accepted Answer · answered Mar 10 '11 at 05:22

2

Why don't you just enable DNS updates in DHCP ?

Something like

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

in your dhcpd.conf (I'm assuming you use ISC's) and it will update the DNS.

If you can't change the dhcp configuration probably you can use nsupdate in a client script hook.

answered Mar 10 '11 at 05:22

Diego Torres Milano

65,697
9
111
134

I think this is what I had been looking for. – holmes Mar 10 '11 at 06:04
I would like a little bit more information for tidying a locally setup dns server and the client side script in the networkmanager or something that gets called when dhcp ip address is updated. – holmes Mar 10 '11 at 06:06
You should put your script containing nsupdate at /etc/NetworkManager/dispatcher.d and it will be run when the network state changes (up, down). – Diego Torres Milano Mar 10 '11 at 06:53
Thank you, this might had been obvious, but it was quick to get the answer. – holmes Mar 10 '11 at 13:33

score 0 · Answer 2 · edited Oct 07 '21 at 06:11

Possible solution (or kludge should I say).
The only way I can see of achieving this is to extend the network mask to 255.255.0.0 (class B network mask) for all the linuxpc boxes.
You will have to do that, however, on the DHCP server, in the same way you configure that linuxpc1 eth0 mac address will be assigned ip address 192.168.0.101.
This means merging all your Class C private sub-networks into a single class B chunk.

Detail
Otherwise, I don't think you can do that with avahi straight out of the box. Here is why.

Avahi uses mDNS to publicize hostnames.

In detail, things work like this:
As part of it's processing logic, your linuxpc3's avahi daemon will send a DNS UDP datagram on port 5353 (?) on ip address 224.0.0.51.
This address is one of the multicast addresses reserved for zeroconf (see iana multicast addresses).

Assuming linuxpc3 address is 192.168.2.103 (following your naming convention), and assuming a standard class C network mask of 255.255.255.0, then only those boxes with addresses between 192.168.2.1 and 192.168.2.254 will receive the corresponding dns A update record (by which I mean the other avahi/bonjour daemons running in these boxes).

As a result, neither linuxpc1 nor linuxpc2 will be made aware of the linuxpc3.local hostname/address pair.

If instead the network mask of all these boxes is extended to 255.255.0.0 then the broadcast range will be extended to include all addresses in the 192.168/16 network.

RFC1918, the standard for private networks explicitly allows the 192.168.0.0 block to be configured as a single class B subnetwork.

Update
Having seen your comments.

First conclusion. Avahi has no solution for your combination of requirements.
Avahi relies on subnetwork broadcast.

In a similar context in which avahi was not applicable either, I once resorted to automate the update of /etc/hosts files and DNS records through the detection of connection events changes.

All PCs could see the internet and were detecting conection changes (Linux in NetworkManager dispatcher hooks - Windows through subscription to the System Event Notification Service).

All machines were reporting their connectivity status and ip addresses through messages in www.dropbox.com and were getting their updates from their respective local dropbox folder.

If you want to implement this in stead, or a similar solution, I have to warn you this is quite a bit of work.

Thanks for answering, but my premise here is to not change anything in the environment. — holmes, Mar 09 '11 at 08:13
And the priority is just being able to figure out the ip addresses, don't care about the implementation details. So anything like uploading the avahi-browsed result to a fqdn browseable wiki server, and just make other PCs to refer to the wiki server can be a solution. But this is too ridiculous, and if there were a standard-ish solution, then I would be happy. — holmes, Mar 09 '11 at 08:16

Is it possible to collect .local domain ip addresses hierarchically for building dhcp based dns?

2 Answers2