[Dnsmasq-discuss] Problems using 'split horizon' approach

[Simon Kelley]

Dave Ewart wrote:

> 
> In /etc/hosts in our dnsmasq host (on the 10.a.b.c network), there is an
> entry for apollo:
> 
> 10.99.0.2  apollo.ceu.ox.ac.uk apollo smtp.ceu.ox.ac.uk smtp imap.ceu.ox.ac.uk imap

> Generally, this works fine, e.g.
> 
> $ host apollo
> apollo.ceu.ox.ac.uk has address 10.99.0.2
> 
> The aliases work properly too:
> 
> $ host imap
> imap.ceu.ox.ac.uk has address 10.99.0.2
> 
> and so on.
> 
> However, after running live for a few minutes/hours (it varies), the
> host lookups return the following:
> 
> $ host apollo
> apollo.ceu.ox.ac.uk has address 163.1.168.2
> apollo.ceu.ox.ac.uk has address 10.99.0.2
> $ host apollo
> apollo.ceu.ox.ac.uk has address 10.99.0.2
> apollo.ceu.ox.ac.uk has address 163.1.168.2

> Clearly, the dnsmasq cache is being 'contaminated' by information from
> the upstream DNS, but what I don't understand is why that server is even
> *consulted* for a host which exists in the local /etc/hosts ...
> 
> Can anyone shed any light on what's going on here?

There's one scenario which could explain this: Does there exist a CNAME 
which isn't in /etc/hosts on the dnsmasq machine, but which points to 
one of the names which is getting "contaminated"? If so then looking up 
the CNAME will result in the query being forwarded and the result will 
be the non-shadowed value of the target of the CNAME. That behaviour is 
actually documented somewhere. The non-shadowed value of the CNAME 
target shouldn't go into the cache, (I just looked, and the code seems 
to exist to stop it) so if this then affects subsequent searches then 
it's a bug which should be fixed.

The workaround is to add the CNAME to /etc/hosts on the dnsmasq machine, 
so that it gets answered locally.

The reason you are seeing the two addresses alternate is so that 
load-balancing via DNS will work - the order in which multiple A records 
for the same domain get returned is permuted on every cache lookup.

Cheers,

Simon.