[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
latter).
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.
Paul
More information about the Dnsmasq-discuss
mailing list