[Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts

Jake Howard jake+dnsmasq at theorangeone.net
Mon Apr 13 18:40:03 BST 2020


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 at 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 at 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 at lists.thekelleys.org.uk
> >> >> >> >> >> >
> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> >> >> >> > 
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> Dnsmasq-discuss mailing list
> >> >> >> >> >> Dnsmasq-discuss at lists.thekelleys.org.uk
> >> >> >> >> >>
> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> >> >> >>
> >> >> >> >> > 
> >> >> >> >> > 
> >> >> >> >> > _______________________________________________
> >> >> >> >> > Dnsmasq-discuss mailing list
> >> >> >> >> > Dnsmasq-discuss at lists.thekelleys.org.uk
> >> >> >> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> >> >> > 
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> _______________________________________________
> >> >> >> >> Dnsmasq-discuss mailing list
> >> >> >> >> Dnsmasq-discuss at lists.thekelleys.org.uk
> >> >> >> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> >> >>
> >> >> >> > 
> >> >> >> > 
> >> >> >> > _______________________________________________
> >> >> >> > Dnsmasq-discuss mailing list
> >> >> >> > Dnsmasq-discuss at lists.thekelleys.org.uk
> >> >> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> >> > 
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Dnsmasq-discuss mailing list
> >> >> >> Dnsmasq-discuss at lists.thekelleys.org.uk
> >> >> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> >>
> >> >> > 
> >> >> > 
> >> >> > _______________________________________________
> >> >> > Dnsmasq-discuss mailing list
> >> >> > Dnsmasq-discuss at lists.thekelleys.org.uk
> >> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> >> > 
> >> >>
> >> > 
> >> > 
> >> > _______________________________________________
> >> > Dnsmasq-discuss mailing list
> >> > Dnsmasq-discuss at lists.thekelleys.org.uk
> >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >> > 
> >>
> >>
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20200413/647588ab/attachment-0001.html>


More information about the Dnsmasq-discuss mailing list