[Dnsmasq-discuss] domain per interface

Simon Kelley simon at thekelleys.org.uk
Wed Mar 19 16:28:37 GMT 2008


/dev/rob0 wrote:
> On Tue March 18 2008 18:42:44 richardvoigt at gmail.com wrote:
>> If all else fails, you can run two instances of dnsmasq with two
>> separate config files, each bound to a different interface.
> 
> Indeed, but that's something I would like to avoid. Here's what I
> have now:
> 
>>>  dnsmasq.conf :
>>>  ...
>>>  dhcp-range=wifi,192.168.3.127,192.168.3.192,255.255.255.0,12h
>>>  dhcp-option=wifi,15,wifi.example.net
>>>  ...
>>>
>>>  (where 192.168.3.1 is the wireless interface IP address)
> 
> But that only works for the domain pushed to clients, not for the
> domain used by dnsmasq for forward/reverse DNS names of clients. I get
> "search wifi.example.net" in their resolver files, but that's rather
> useless, since no names have ".wifi.example.net." in them.
> 
> I think that in ISC dhcpd/named, this could be done with a subnet
> declaration block with "option domain-name wifi.example.net;" inside
> it, and of course a corresponding dynamic zone declaration in
> named.conf. That's another avenue I don't want to pursue, because I
> want to keep dnsmasq for authoritative DNS. (I'm using named for
> recursion only, on port 35, with dnsmasq using "server=127.0.0.1#35".)
> 
> Simon, am I out of luck here?

Yes. This has come up before. The problem is that no domain information
is stored in the lease database: dnsmasq assumes that the domain is that
given by --domain. To support multiple domains, the lease file format
would need to change, which is a compatibility problem.

> 
> I guess I could also do dhcp-script and nsupdate(8) to update a zone
> in named.conf. But even then, will the dnsmasq block it? If dnsmasq
> knows the answer, named is never consulted. What about this:
> 
> server=/wifi.example.net/127.0.0.1#35
> server=/3.168.192.in-addr.arpa/127.0.0.1#35
> 
> Will dnsmasq ignore the names it has served to DHCP clients?

DHCP names take preference over server config, sorry.


Cheers,

Simon.





More information about the Dnsmasq-discuss mailing list