[Dnsmasq-discuss] looking up 'dotless' names in two domains

Paul Chambers bod at bod.org
Thu Jun 14 20:37:09 BST 2007

I may be having a 'blond' day, so forgive me if this is a dumb question...

I have dnsmasq set up with a fairly conventional config. I currently 
have expand-hosts enabled, and 'domain' set up for my local domain.

I also have a VPN connection I use some of the time, and have a few 
strategic 'server' lines to forward queries for hosts in my employer's 
domain to the internal nameservers, since many servers are 'internal' to 
that network and won't resolve otherwise.

I have two problems:

a) if something attempts to resolve a host in my employer's domain, and 
the VPN connection isn't up, then the lookup fails, even if that host 
may also have a 'public' DNS record/IP address. Typical scenario is 
sending an email to a co-worker. The VPN connection is not normally up, 
and even when it is, it will be closed by the remote end after a few 
hours. I could stick explicit 'address' entries in for the mail server, 
like I've already had to do to resolve the VPN server address. But that 
seems like a workaround, not a solution. What I'd really like is a more 
dynamic setup, something like the support for the ppp daemon's 
resolv.conf rewriting, but much smarter. For example, being able to say 
these server/address statements are conditional on a particular 
interface being up, or a specific route being available (I'd prefer the 

b) the default domain suffix is different for this network, and several 
of my employer's web servers insist on redirecting to absolute HTTP URLs 
with the 'dotless' name (Sharepoint in particular). dnsmasq takes the 
dotless name and adds my domain to it, and the lookup fails because it's 
in my employer's domain. I'd like to be able to configure dnsmasq to try 
the 'dotless' search against more than one domain. Preferably in 
conjunction with the 'dynamic' support above. I may have to turn 
'expand-hosts' off and add explicit entries in /etc/hosts to work around 
this, which is a pretty ugly solution.

None of this is exactly life-threatening, but given how trouble-free and 
elegant dnsmasq is in other areas, this stands out all the more.


More information about the Dnsmasq-discuss mailing list