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

Reply via email to