[Dnsmasq-discuss] Equivalent of localise-queries for DHCP-assigned
simon at thekelleys.org.uk
Wed Dec 10 09:26:59 GMT 2008
Drews, Paul wrote:
> I have a group of machines on two private subnets that look like the
> 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
> () 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.
More information about the Dnsmasq-discuss