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!

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

Reply via email to