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 the 10. 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!

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

Reply via email to