[Dnsmasq-discuss] Upstream CNAME records

[Andreas Pelme]

On Wed, Jan 25, 2006 at 08:52:10PM +0000, Simon Kelley wrote:
> Andreas Pelme wrote:
> > Hi,
> > 
> > I am using Dnsmasq for my LAN, but I am having problems with some
> > lookups.
> > 
> > I have records in /etc/hosts on my router, for example:
> > 192.168.0.2             svn.pelme.se            svn
> > 
> > On the LAN, svn.pelme.se should resolv to 192.168.0.2, but outside, on
> > the internet, svn.pelme.se is a CNAME for pelme.se.
> > 
> > When I look up svn.pelme.se from a machine on the LAN i get this:
> > andreas at solros:~$ host svn.pelme.se 
> > svn.pelme.se has address 192.168.0.2
> > svn.pelme.se is an alias for pelme.se.
> > svn.pelme.se is an alias for pelme.se.
> > pelme.se mail is handled by 30 mx3.pelme.se.
> > pelme.se mail is handled by 10 mx1.pelme.se.
> > pelme.se mail is handled by 20 mx2.pelme.se.
> > 
> > That is not really what i want because the pelme.se /etc/hosts entry
> > looks like this:
> > 192.168.0.3             www.pelme.se            pelme.se
> > 
> > Then it looks up pelme.se and finds out this is 192.168.0.3, so the
> > result is "192.168.0.2" and/or "192.168.0.3". This is not what I want.
> > 
> > I saw this in dnsmasq(8):
> > 
> > Addresses  in  /etc/hosts  will  "shadow" different addresses for
> > the same names in the upstream DNS, so "mycompany.com 1.2.3.4" in
> > /etc/hosts will ennsure that queries for "mycompany.com" always return
> > 1.2.3.4 even if queries in the upstream DNS would otherwise return
> > a different address. There is  one  exception  to  this:  if the
> > upstream DNS contains a CNAME which points to a shadowed name, then
> > looking up the CNAME through dnsmasq will result in the unshadowed
> > address associated with the target of the CNAME. To work around this,
> > add the CNAME to /etc/hosts so  that the  CNAME  is shadowed too.
> > 
> > Is it possible to *not* forward requests upstream at all when a host is
> > found in /etc/hosts, and *not* reply with the upstream CNAME record? It
> > would help me a lot. The records should point to the same address
> > outside the LAN, but not on the inside.
> > 
> > I guess this is not a bug because it is documented in the man-page.
> > 
> > If this really is the way things should work, is it hard to modify
> > Dnsmasq to not ask upstream servers if a record is found in hosts?
> > 
> Andreas,
> 
> Please could you repeat the test above using "dig" instead of "host"?
> You host command seems to behave differently to the one on my system,
> and it's not clear exactly what the query is returning. Also, what
> version of dnsmasq are you running?
> 
> 
> Cheers,
> 
> Simon.
> 

Now when I look up with dig things seems to be different. I have a
couple of different boxes, several Windows XP machines, one laptop
running Ubuntu 5.10 and one server running Debian 3.1, behind the
gateway, running Debian 3.1.

Actually, I have never had problems from the XP boxes, but I had
troubles from the Ubuntu box. When I opened Firefox and entered e.g.
http://svn.pelme.se it is clear that it *sometimes* resolved to 192.168.0.3
(www.pelme.se/pelme.se) via the CNAME, and not 192.168.0.2 as intended.

I replaced host-bind9 with host from dnsutils, I am not sure about the
difference, maybe the bind9 version is wierd. When using it and dig
everything seems to work just fine. Right now I am not sure about what
is going on, but it seems to work. I do not think this is an error or bug in
Dnsmasq, probably just some stupid configuration over here on my laptop.

I dont see how replacing the host -program could change the behaviour of
Firefox's DNS lookups, and I am pretty sure it does not.

Well, everything seems to be working now, I guess that something was just
wierd at the Ubuntu laptop that caused this.

BTW: I am running Dnsmasq from Debian stable, which is version 2.22.

Thanks for your help and your excellent work on Dnsmasq!

Cheers,
-- 
Andreas Pelme <andreas at pelme.se>
+46(0)704773720
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20060125/42ff8e1f/attachment.pgp