Ah, yes in more complex networking environments it definitely makes more sense to use the destination address! I don't believe my case is affected by that, and definitely breaking things isn't ideal.
An option to localise based on source IP definitely sounds like the right approach to me, although I have no idea what the dev toll would be. I also suspect and hope it's an option which would be generally useful to people outside just my use case! On Thu, 9 Apr 2020, at 20:20, Simon Kelley wrote: > > > On 09/04/2020 16:47, Jake Howard wrote: > > Hi, > > > > Thanks for the clarification! Yeah definitely sounds like it's Docker's > > iptables /magic/ causing the issues here. > > > > Any thoughts on a solve? Either on my end our a code change? Is using > > the destination address correct, or should it really be using the > > source? Configuration would probably help this one! > > Using the destination address is definitely correct: the point of this > is to reply to the DNS query with an answer which is "nearest" to the > source of the DNS query, by returning the address of the interface the > query arrives on, and not the addresses of other interfaces within the > machine. If it changes to using the source address, then a whole slew of > cases which work now would break. Namely where the source of the query > is on another network and the path from the source to the host running > dnsmasq includes a router. > > I don't know is the above is an issue for your use case. If not, an > option to use source addresses might make sense. Do you absolutely need > this to work, because of incomplete routing, or is it a minor > optimisation? If the former, completing the routing tables might be an > easier fix. > > > Simon. > > > > > > > Thanks, > > - Jake Howard > > > > On Wed, 8 Apr 2020, at 16:44, Simon Kelley wrote: > >> On 06/04/2020 17:35, Jake Howard wrote: > >> > Hello, > >> > > >> > Here's an info dump, which hopefully gives a bit more context: > >> > > >> > Hosts file: > >> > > >> > 192.168.1.200 some.domain > >> > 10.23.0.2 some.domain > >> > > >> > Log entry: > >> > > >> > Apr 6 17:03:58 dnsmasq[549]: query[A] some.domain from 192.168.1.92 > >> > Apr 6 17:03:58 dnsmasq[549]: /hosts.conf some.domain is 192.168.1.200 > >> > Apr 6 17:03:58 dnsmasq[549]: /hosts.conf some.domain is 10.23.0.2 > >> > > >> > > >> > Local Shell: > >> > > >> > $ dig some.domain @10.23.0.2 +short > >> > 192.168.1.200 > >> > 10.23.0.2 > >> > > >> > $ dig some.domain @192.168.1.200 +short > >> > 192.168.1.200 > >> > 10.23.0.2 > >> > > >> > (Local machine is on both the10. and 192.168. networks just fine) > >> > > >> > Network setup inside the container (ip a): > >> > > >> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > >> > group default qlen 1000 > >> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > >> > inet 127.0.0.1/8 scope host lo > >> > valid_lft forever preferred_lft forever > >> > 121: eth0@if122: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > >> > noqueue state UP group default > >> > link/ether 02:42:ac:1c:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0 > >> > inet 172.28.0.2/16 brd 172.28.255.255 scope global eth0 > >> > valid_lft forever preferred_lft forever > >> > > >> > Can't say i'm entirely sure what "destination address of the query" is, > >> > and how / why it differs from the source address shown in the log. If > >> > it's using the return address it can see, it's possible it's using the > >> > 172.28 address, and hence isn't switching correctly? > >> > > >> > How is the destination address calculated, is there something I can do > >> > to make this work as needed? Alternatively, is something in dnsmasq not > >> > playing correctly? > >> > > >> > Thanks! > >> > >> The destination address is the address after @ in your dig commands. The > >> query has source address 192.168.1.92 (that's what's logged) and > >> destination address 10.23.0.2 or 192.168.1.200 which were the packet > >> gets delivered to. It's that which is used to do the localisation in > >> dnsmasq. > >> > >> The problem is that neither of those addresses appears on the interface, > >> that's 172.28.0.2. So all that scary iptables stuff from docker that Dan > >> posted above is rewriting the source address of the packets originally > >> to either addresse to 172.28.0.2 and in the process, loosing the > >> information which dnsmasq could use to distinguish them. > >> > >> Simon. > >> > >> > >> > >> > > >> > On Sun, 5 Apr 2020, at 21:49, Simon Kelley wrote: > >> >> > >> >> > >> >> On 05/04/2020 14:48, Jake Howard wrote: > >> >> >> > >> >> >> Dnsmasq uses the _destination_ address of the query. I'm not > >> familiar > >> >> >> with Docker. Is it using NAT? > >> >> > > >> >> > Can't say i'm especially familiar with Docker's networking stack, > >> but it > >> >> > definitely looks and feels like something NAT-ish to me! > >> >> > Interestingly enough, the log entry for where the query came from is > >> >> > correctly detected, but I guess it's not using that address to > >> localise? > >> >> > > >> >> > eg: > >> >> > > >> >> > Apr 5 14:44:59 dnsmasq[505]: query[A] github.com from 10.23.0.23 > >> >> > Apr 5 14:44:59 dnsmasq[505]: forwarded github.com to 1.0.0.1 > >> >> > Apr 5 14:44:59 dnsmasq[505]: reply github.com is 140.82.118.3 > >> >> > > >> >> > > >> >> > Are the addresses used in the log and the destination address > >> different? > >> >> > Thanks, > >> >> > - Jake Howard > >> >> > >> >> > >> >> It uses the _destination_ address of the _query_ to localise, > >> that's not > >> >> logged. > >> >> > >> >> > >> >> Simon. > >> >> > >> >> > > >> >> > On Sat, 4 Apr 2020, at 19:01, Simon Kelley wrote: > >> >> >> On 31/03/2020 13:51, Jake Howard wrote: > >> >> >> > Hello! > >> >> >> > > >> >> >> > Had a breakthrough on what's going on, and it's down to a caveat I > >> >> >> > missed when reading the man page on localise-queries: > >> >> >> > > >> >> >> >> Return answers to DNS queries from /etc/hosts and > >> *--interface-name* > >> >> >> > which depend on the interface over which the query was received. > >> >> >> > > >> >> >> > And of course, this issue has to do with docker. With Docker, even > >> >> >> > though the container is listening on 2 different interfaces, and 2 > >> >> >> > different IPs, the inner container, and thus dnsmasq, only sees 1 > >> >> >> > interface, with all addresses coming from it. Hence localisation > >> >> isn't > >> >> >> > quite working. > >> >> >> > > >> >> >> > If I run dnsmasq with the exact same config but on the host, > >> where it > >> >> >> > can see the different interfaces, works perfectly! > >> >> >> > > >> >> >> > Testing was done in 2.79 and 2.76, with a config file practically > >> >> >> > identical to your CLI arguments. > >> >> >> > > >> >> >> > Technically, there's not a bug here per-say, but it'd be really > >> >> handy if > >> >> >> > there was a way of looking at the source IP when determining which > >> >> >> > record to return rather than just the interface? > >> >> >> > >> >> >> Dnsmasq uses the _destination_ address of the query. I'm not > >> familiar > >> >> >> with Docker. Is it using NAT? > >> >> >> > >> >> >> > >> >> >> Simon. > >> >> >> > >> >> >> > >> >> >> > > >> >> >> > Thanks! > >> >> >> > > >> >> >> > On Mon, 30 Mar 2020, at 20:42, Simon Kelley wrote: > >> >> >> >> On 28/03/2020 20:38, Jake Howard wrote: > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > My intention is to have 1 dnsmasq instance, accessible over 2 > >> >> >> interfaces > >> >> >> >> > (listening on all), and have the response to a query differ > >> based > >> >> >> on the > >> >> >> >> > interface, and therefore its incoming IP. From what i've read, > >> >> that's > >> >> >> >> > exactly what localise-queries is meant to do, but it doesn't > >> >> >> appear to > >> >> >> >> > be unless I put the entries into /etc/hosts directly. > >> >> >> >> > >> >> >> >> > >> >> >> >> OK, what you're expecting to happen and what I'm expecting to > >> >> >> happen are > >> >> >> >> the same. That's good. > >> >> >> >> > >> >> >> >> I just did a quick test, and it seems to work fine for me. The > >> >> >> >> example.com addresses are in /tmp/hosts. > >> >> >> >> > >> >> >> >> > >> >> >> >> srk@holly:~/dnsmasq/dnsmasq$ src/dnsmasq -d --log-queries > >> >> >> >> --localise-queries -p 10000 --addn-hosts=/tmp/hosts > >> >> >> >> dnsmasq: started, version 2.81rc4-5-gd162bee cachesize 150 > >> >> >> >> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus > >> >> no-i18n > >> >> >> >> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC > >> >> >> >> loop-detect inotify dumpfile > >> >> >> >> dnsmasq: reading /etc/resolv.conf > >> >> >> >> dnsmasq: using nameserver 127.0.1.1#53 > >> >> >> >> dnsmasq: read /etc/hosts - 9 addresses > >> >> >> >> dnsmasq: read /tmp/hosts - 2 addresses > >> >> >> >> dnsmasq: query[A] example.com from 127.0.0.1 > >> >> >> >> dnsmasq: /tmp/hosts example.com is 192.168.151.43 > >> >> >> >> dnsmasq: /tmp/hosts example.com is 192.168.150.43 > >> >> >> >> dnsmasq: query[A] example.com from 192.168.150.49 > >> >> >> >> dnsmasq: /tmp/hosts example.com is 192.168.150.43 > >> >> >> >> > >> >> >> >> > >> >> >> >> If it's not working for you, that's a bug, but we need to find > >> >> what it > >> >> >> >> is about your setup that tickles the bug. > >> >> >> >> > >> >> >> >> Can you boil it down to the simplest configuration that > >> displays the > >> >> >> >> problem, and also specify which version of dnsmasq you're using? > >> >> >> >> > >> >> >> >> > >> >> >> >> cheers, > >> >> >> >> > >> >> >> >> Simon. > >> >> >> >> > >> >> >> >> > >> >> >> >> > > >> >> >> >> > Thanks, > >> >> >> >> > - Jake Howard > >> >> >> >> > > >> >> >> >> > On Sat, 28 Mar 2020, at 17:59, Simon Kelley wrote: > >> >> >> >> >> On 19/03/2020 21:47, Jake Howard wrote: > >> >> >> >> >> > Hello! > >> >> >> >> >> > > >> >> >> >> >> > Is `localise-queries` meant to work against entries > >> added via > >> >> >> >> >> > `addn-hosts`? Querying a record returns both IPs, but always > >> >> >> in the > >> >> >> >> >> same > >> >> >> >> >> > order. The order is correctly fixed when the records are > >> >> put in > >> >> >> >> >> > `/etc/hosts` directly. > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Yes, localise-queries works with entries added via > >> addn-hosts, > >> >> >> but it > >> >> >> >> >> doesn't have anything to do with the order that records > >> appear, > >> >> >> so that > >> >> >> >> >> doesn't address your problem. What are you trying to achieve? > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> Simon. > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > Config: > >> >> >> >> >> > > >> >> >> >> >> > ``` > >> >> >> >> >> > localise-queries > >> >> >> >> >> > no-resolv > >> >> >> >> >> > cache-size=10000 > >> >> >> >> >> > log-queries > >> >> >> >> >> > log-facility=/var/log/pihole.log > >> >> >> >> >> > local-ttl=2 > >> >> >> >> >> > log-async > >> >> >> >> >> > server=8.8.8.8 > >> >> >> >> >> > server=8.8.4.4 > >> >> >> >> >> > server=1.1.1.1 > >> >> >> >> >> > server=1.0.0.1 > >> >> >> >> >> > interface=eth0 > >> >> >> >> >> > server=/use-application-dns.net/ > >> >> >> >> >> > > >> >> >> >> >> > addn-hosts=/etc/vpn-hosts.conf > >> >> >> >> >> > localise-queries > >> >> >> >> >> > > >> >> >> >> >> > ``` > >> >> >> >> >> > > >> >> >> >> >> > This is from pihole, but AFAIK that shouldn't make a > >> difference > >> >> >> >> if I'm > >> >> >> >> >> > modifying the config directly. > >> >> >> >> >> > > >> >> >> >> >> > Would appreciate some input, or being told i'm wrong! > >> >> >> >> >> > > >> >> >> >> >> > Thanks, > >> >> >> >> >> > > >> >> >> >> >> > - Jake Howard > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > _______________________________________________ > >> >> >> >> >> > Dnsmasq-discuss mailing list > >> >> >> >> >> > Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> >> >> >> > > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> _______________________________________________ > >> >> >> >> >> Dnsmasq-discuss mailing list > >> >> >> >> >> Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> >> >> >> > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > _______________________________________________ > >> >> >> >> > Dnsmasq-discuss mailing list > >> >> >> >> > Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> >> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Dnsmasq-discuss mailing list > >> >> >> >> Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> >> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > Dnsmasq-discuss mailing list > >> >> >> > Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> >> > > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Dnsmasq-discuss mailing list > >> >> >> Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> >> > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Dnsmasq-discuss mailing list > >> >> > Dnsmasq-discuss@lists.thekelleys.org.uk > >> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> >> > > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Dnsmasq-discuss mailing list > >> > Dnsmasq-discuss@lists.thekelleys.org.uk > >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> > > >> > >> > > >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss