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

[Dave Ewart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have an email server, apollo.ceu.ox.ac.uk, which as you will see from
doing a host lookup has an IP in the public DNS of 163.1.168.2, which is
fine.

However, this server is actually located on our LAN and has an address
in the 10.a.b.c range - requests to the public address are served by
means of fairly standard port-forwarding.

Now the dnsmasq-related issue:

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

This results in a presumably fairly typical 'split horizon' setup for
this host.

All clients on the local network use the dnsmasq host for their DNS
lookups.

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

The address which is returned first for any particular query seems to be
the one which is used and so 50% of the queries for 'apollo' result in
the 'incorrect' address being returned for Apollo, at least as far as
the LAN is concerned.  I have 'got around' this problem for now by using
our firewall to rewrite locally-generated requests for 163.1.168.2 to go
to 10.99.0.2 instead, but I'm confused about why the problem occurs.

The dnsmasq host is a Debian Woody installation, its /etc/resolv.conf is:

    search ceu.ox.ac.uk
    nameserver 10.0.0.12

10.0.0.12 is the local IP of the dnsmasq host itself

/etc/default/dnsmasq contains:

    RESOLV_CONF="/etc/resolv.conf.dnsmasq"

/etc/resolv.conf.dnsmasq contains:

    nameserver 129.67.1.1

where that IP address is our upstream DNS.

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?

Dave.
- -- 
Dave Ewart
davee at ceu.ox.ac.uk
Computing Manager, Cancer Epidemiology Unit
Cancer Research UK / Oxford University
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
N 51.7518, W 1.2016
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC8eQabpQs/WlN43ARAo5qAJ4sEP3qX9iE4XDJyg0kR+u2nbEjWACbBUv3
QQo0unITjrASfEIb20BpdCY=
=JQuW
-----END PGP SIGNATURE-----