Re: [Dnsmasq-discuss] Problems using 'split horizon' approach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, 22.08.2005 at 12:19 +0100, Simon Kelley wrote: $ host apollo apollo.ceu.ox.ac.uk has address 10.99.0.2 $ host -t any apollo apollo.ceu.ox.ac.uk has address 163.1.168.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 etc. The tcpdump shows that during the 'any' request, the dnsmasq host cannot serve it (presumably because it only has an 'A' record?) and the request is forwarded to the upstream DNS server, which returns the public IP, which then gets included in the cache. Is this the expected behaviour of dnsmasq in these circumstances? Did we ever establish which version you are using? ISTR that you are using Debian woody, and maybe therefore the very old 1.4 dnsmasq release. If that's the case, then yes, I would expect that behaviour, and the fix it to upgrade to dnsmasq 2.22 in sarge. If you are using dnsmasq 2.22 then I'm very interested, since this problem was long ago thought to be fixed in the 2.x series. If needs be the Debian dnsmasq-2.22_2 package will build from source and run quite successfully on a Woody system. My apologies. I did build dnsmasq from the 2.22 source, but it appears it failed to install properly. After properly installing it, the above described behaviour does not appear to re-occur. Thanks Simon ... Dave. - -- Dave Ewart da...@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) iD8DBQFDCbdJbpQs/WlN43ARAouAAKD08BJpKUmUsc0M44IWRKo5KCxBOQCfdLe5 7kKqzQ/pl+PSws1DHSBlp60= =bYdJ -END PGP SIGNATURE-
Re: [Dnsmasq-discuss] Problems using 'split horizon' approach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon, I've now worked out exactly what DNS request 'poisons' the dnsmasq cache. (This appears to be completely reproducible, although it is possible there are other, related queries which might have the same effect.) After doing a tcpdump, it became clear that the cache became poisoned after dnsmasq received an 'ANY' request for the system with the split-horizon setup. i.e. $ host apollo apollo.ceu.ox.ac.uk has address 10.99.0.2 $ host -t any apollo apollo.ceu.ox.ac.uk has address 163.1.168.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 etc. The tcpdump shows that during the 'any' request, the dnsmasq host cannot serve it (presumably because it only has an 'A' record?) and the request is forwarded to the upstream DNS server, which returns the public IP, which then gets included in the cache. Is this the expected behaviour of dnsmasq in these circumstances? Dave. - -- Dave Ewart da...@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) iD8DBQFDAx0wbpQs/WlN43ARApNsAJ9rJFnmTX1fOFlrNdx0aKVpMiJoyACeJ4V6 o14T4LzzSq0Hma9gYPEwD1o= =+RR/ -END PGP SIGNATURE-
[Dnsmasq-discuss] Problems using 'split horizon' approach
-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 da...@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-
Re: [Dnsmasq-discuss] Problems using 'split horizon' approach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, 04.08.2005 at 11:55 +0100, Simon Kelley 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. Well, I don't *think* that's happening, since there are no publically-defined CNAMEs which don't also exist in /etc/hosts. I've restarted dnsmasq, which clears the 'contamination' and have started tcpdump on port 53 with a shed load of verbosity, so hopefully I can find out what requests are making this happen. 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. That makes sense and is as I suspected ... Cheers, Dave. - -- Dave Ewart da...@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) iD8DBQFC8gpHbpQs/WlN43ARArsKAJ0WjQTAh6H9u9PBqwKQSc6qFmoSyACcCLcF sZRQ0flQEDGa8vUrrD1dqTQ= =uI8W -END PGP SIGNATURE-
