[Dnsmasq-discuss] Using dnsmasq with different domains for different
subnets.
Simon Kelley
simon@thekelleys.org.uk
Wed, 01 Dec 2004 21:10:25 +0000
David Sankel wrote:
> Hello,
>
> I'm pushing dnsmasq a little further than I have before by allowing
> it to host for two different subnets (on the same card, but different
> VLANs). This works fine and dandy,
Useful to know, I'm not aware of testing with VLANs before.
> but I would like it to use a
> different domain for each subnet; For example, freenet and offices.
> Is there anyway I can do this with dnsmasq?
>
> My current conf has something like this:
>
> domain=invalid
>
> dhcp-range=offices,192.168.10.50,192.168.10.150,12h
> dhcp-range=freenet,192.168.1.50,192.168.1.150,12h
>
> # option 15 sets the domain name
> dhcp-option=offices,15,offices
> dhcp-option=freenet,15,freenet
>
> Although the dhcp works perfectly, the domain name doesn't resolve to
> what I'd like. For example toledo.tst resolves but toledo.offices
> doesn't. I've tried commenting out the domain= part and I don't seem
> to get any closer.
You are not the first person to request this: the reason that it has not
been implemented is an unfortunate design decision long ago. The
hostnames associated with DHCP leases are stored in the lease file
without the domain part. That's fine when the domain part can always be
assumed to be given by the domain= option, but more difficult otherwise.
The obvious way to implement variable domains is to key them with netid
tags, the same way DHCP options are selected, but netid tags can come
from things like vendor-class information or dhcp-host options which are
not available in the leases file either, so reconstructing the domain
associated with a lease at startup is non-trivial.
Of course I could just extend the lease file format, but that makes
headaches for upgrading, and especially for downgrading.
One way around this might be to limit the domain to a particular
dhcp-range, on the assumption that most people would want to use it that
way rather than with vendor or user classes or individual dhcp-host
lines (most setups have a correspondence between subnets and subdomains,
after all) Since associating a lease with a DHCP range is easy, that
would provide the missing information without having to alter the lease
file.
So, in your example, we would have
dhcp-range=192.168.10.50,192.168.10.150,12h,offices.myco.com
dhcp-range=192.168.1.50,192.168.1.150,12h,freenet.myco.com
The "offices.myco.com" and "freenet.myco.com" would override the
domain=<domain> options for just that particular range (thereby getting
the DNS correct, and sending the correct DHCP option 15).
It's currently possible for a host to send a fully qualified domain and
it's hostname: this gets ignored if the domain part doesn't match the
domain=<domain> option (to stop a host claiming to be www.google.com)
and used otherwise. That facility would probably only be available in
configurations which didn't use the new domain system, but stuck to a
single global domain. [Otherwise there's a nasty circularity: a
dhcp-host line might be selected on a name, that affects which of
several dhcp-range options on a subnet are used, which affects the valid
domain part, which affects wether the name was valid in the first
place.....]
It all gets very complicated: does the team think it's worth it?
Cheers,
Simon.