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