[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.