[Dnsmasq-discuss] Equivalent of localise-queries for
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
() 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:
--listen-address 192.168.1.1 \
--listen-address 192.168.2.1 \
--listen-address 127.0.0.1 \
--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 \
() 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
() 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
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
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
> 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