[Dnsmasq-discuss] Equivalent of localise-queries for DHCP-assigned leases

Drews, Paul paul.drews at intel.com
Thu Dec 11 00:07:13 GMT 2008


Thanks, the "dhcp-fqdn" was the critical feature that made this possible,
Although some additional fiddling was required.  Here's what I wound up
With:

() aslspecwebprime is the top-level machine running dnsmasq.  It has a NIC on each subnet,
   with static IP addresses.
() aslspecweb26 is only on the 192.168.2.* subnet
() aslspecweb27 is only on the 192.168.1.* subnet
() aslspecweb13 has a NIC on each subnet
() all machines are Fedora 9 (linux)

My dnsmasq invocation is:

/usr/local/sbin/dnsmasq \
  --domain=specweb1,192.168.1.0,192.168.1.254 \
  --domain=specweb2,192.168.2.0,192.168.2.254 \
  --domain=specwebdefault \
  --localise-queries \
  --bind-interfaces \
  --pid-file  \
  --conf-file  \
  --listen-address 192.168.1.1 \
  --listen-address 192.168.2.1 \
  --listen-address 127.0.0.1 \
  --dhcp-leasefile=/var/lib/specweb/leases \
  --dhcp-range 192.168.1.2,192.168.1.254,255.255.255.0,,1h \
  --dhcp-range 192.168.2.2,192.168.2.254,255.255.255.0,,1h \
  --dhcp-fqdn \
  --dhcp-option=option:dns-server,192.168.1.1,192.168.2.1 \
  --dhcp-host=net:multihomed,aslspecweb13 \
  --dhcp-option=multihomed,option:domain-name,"specweb1 specweb2"

() The "domain=" lines designate a domain name for each subnet
() The "domain=specwebdefault" is required to have a fallback domain-name 
   outside any range whenever you have dhcp-fqdn.  It isn't actually used.
() localise-queries is required for resolving the "aslspecwebprime" name.
   "aslspecwebprime.specweb1" and "aslspecwebprime.specweb2" have to appear
   in aslspecwebprime's /etc/hosts file, with the respective static IP
   addresses.
() There's a "listen-address" for each subnet.  The "listen-address" for
   127.0.0.1 is part of letting dnsmasq resolve name queries originating on
   aslspecwebprime.  Another part of this is inserting "nameserver 127.0.0.1"
   as the FIRST nameserver in /etc/resolv.conf on aslspecwebprime.  The
   remaining part of this is appending " specweb1 specweb2" to the "search"
   entry on aslspecwebprime's /etc/resolv.conf file.
() Single-homed clients automatically get suitable dhcp options sent to
   them to set up their /etc/resolv.conf properly.  This doesn't work for
   the multi-homed system aslspecweb13, because the final NIC to get
   initialized ends up having its "search" and "nameserver" overriding
   anything that went before rather than adding to what went before.  The
   last 3 lines above workaround this.  The "option:dns-server" line sets
   the list of "nameserver" lines that go into a client system's
   /etc/resolv.conf file.  The "option:domain-name" line sets the list
   of domain names that go onto the "search" line in /etc/resolv.conf so
   a multi-homed host will try qualifying a bare hostname with BOTH subnet
   domain names when looking it up.  This has to be done ONLY for the
   multi-homed host, hence the "net:multihomed" tag specific to the
   aslspecweb13 hostname.  I probably should make the option:dns-server
   specific to this tag as well.

The only moderately painful thing about this setup is that I have to edit
the name of the multi-homed host if it changes.  Fortunately there is only one
and it changes only rarely.  No configuration changes need to get made on
any of the machines in the subnets other than plugging them into the network
correctly.

By the way, the dhcp-fqdn causes sufficient information to go into the
"leases" file that it would be possible to auto-generate enough stuff into
/etc/hosts for --localize-queries to work properly.

As Simon mentioned, dnsmasq version 1.46 or higher is required for the
dhcp-fqdn feature.

-----Original Message-----
From: Simon Kelley [mailto:simon at thekelleys.org.uk] 
Sent: Wednesday, December 10, 2008 1:27 AM
To: Drews, Paul
Cc: dnsmasq-discuss at lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Equivalent of localise-queries for DHCP-assigned leases

Drews, Paul wrote:
> I have a group of machines on two private subnets that look like the
> following:
> 
> 
> 
> Machine1_with_dnsmasq |              | +----+---+      +---+----+ |
> |      |        | mach2      |      |      mach3 |      | machine4
> 
> 
> () Machine1 at the top should handle DHCP and DNS duties for both
> subnets.  It has a NIC per subnet. () mach2 and mach3 each sit on
> different subnets () machine4 has two NICs, one on each subnet
> 
> Machines will be plugged and unplugged from this setup often so I
> would like to have dnsmasq automatically assign addresses and resolve
> names just by plugging machines into the subnets without a lot of
> manual updating of hosts files, etc.
> 
> The "--localise-queries" does almost what I want: when mach2 asks to
> resolve the name of machine4, it needs to get the IP address of the
> machine4 NIC that sits on mach2's subnet, but when mach3 asks to
> resolve machine4, it needs to get the IP address of machine4's NIC on
> mach3's subnet.  Localise-queries would do this if machine4's two
> addresses were listed in machine1's /etc/hosts file.  But they're
> not; they were assigned through DHCP.
> 
> Here's what I've tried:
> 
> () Run a single dnsmasq on machine1, with different DHCP ranges for
> the two different NICs leading to the two subnets.  DHCP works fine.
> Mach2 and mach3 get correct IP addresses for their subnet.  Machine4
> gets different, properly subnet-specific IP addresses for its two
> different NICs.  DNS is a problem, though.  When mach2 tries to
> resolve machine4's name to an IP address, it is likely to get an
> address for the NIC in the "other" subnet, which is unreachable.
> 
> () Run two instances of dnsmasq on machine1, one instance for each
> subnet.  This takes some fiddling with DHCP options to make sure
> machine4 gets both IP addresses to land in its /etc/resolv.conf file
> so that it can resolve names in either subnet.  DHCP all works fine.
> DNS works fine from mach2 or mach3.  But from machine4 when an
> attempt is made to resolve mach2, it appears that sometimes the query
> runs up the "wrong" subnet, the dnsmasq instance on that subnet can't
> resolve it, and name resolution fails without ever trying the other
> subnet.
> 
> () I also tried a single-instance dnsmasq approach with using the
> dhcp-script feature to try to catch the leases and update the
> /etc/hosts file.  This didn't work since the second IP address lease
> from machine4 always gets reported without a hostname so I didn't
> have enough information to update /etc/hosts
> 
> It looks like the most promising approach is to use a dnsmasq
> instance per subnet with each instance being told about the other(s)
> as "upstream" DNS servers.  This seemed to sometimes work, sometimes
> slowly, sometimes not at all.  I need to spend some quality time
> debugging on it, but I suspect that there may have been some nasty
> loops set up.  Can this be avoided?  Also, I'm worried that this
> approach may become intractable when I need to scale up to more
> subnets.  It also has the side-effect that mach2 can resolve mach3
> even though it is unreachable.  I can live with that.
> 
> Any ideas on how to set this up?
> 

Here's a suggestion, I've not tried it, so there may be fundamental 
flaws which have not occurred to me.

1) Use dnmsasq-2.46, you'll need functionality only available there,

2) Define different domains for the two physical subnets. (say 
network1.here and network2.here)

3) Set --dhcp-fqdn so that when a machine "fred" gets a DHCP lease on 
each network, it gets the names fred.network1.here on network1 and 
fred.network2.here for the two IP addresses.

4) Set the search list in each client to search network1.here and 
network2.here for plain names. You can set this automatically using a 
dhcp option (112?) but be warned that not all clients will honour it 
without some fiddling.



This brings to mind another "mode" for handling multiple DHCP clients 
with the same name which would solve your problem more directly.

The traditional behaviour (and the only one available before 2.46) is 
that a name ("name" here implies unqualified) is only ever associated 
with one DHCP lease.

--dhcp-fqdn brings a second behaviour, unqualified names are not used, 
and qualified names (with domain added based on IP address) are used, so 
that the same (unqualified) name can go to two different DHCP leases, 
provided that their IP addresses map to different domains.

A third option might be to allow unqualified domains when a name is 
associated with more than one lease and the "localise" function. That 
would work fine for your machine2, but it could get very confusing when 
two _different_ machines ask for or are otherwise allocated the same name.

HTH

Simon.



More information about the Dnsmasq-discuss mailing list