Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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: 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: 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 u
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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: 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: 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! >> >> >> > >> >> >>
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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: 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: 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 > >> >> >
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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: 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: 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 1 --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 > >
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
Jake Howard wrote on 4/5/2020 6:48 AM: >> >> 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? > > Thanks, > - Jake Howard Default Docker iptables chains (for containers running published services on 80/443) # Generated by xtables-save v1.8.2 on Sun Apr 5 20:00:11 2020 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE -A POSTROUTING -s 172.17.0.4/32 -d 172.17.0.4/32 -p tcp -m tcp --dport 443 -j MASQUERADE -A POSTROUTING -s 172.17.0.4/32 -d 172.17.0.4/32 -p tcp -m tcp --dport 80 -j MASQUERADE -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A DOCKER -i docker0 -j RETURN -A DOCKER ! -i docker0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.17.0.4:443 -A DOCKER ! -i docker0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.4:80 COMMIT # Completed on Sun Apr 5 20:00:11 2020 # Generated by xtables-save v1.8.2 on Sun Apr 5 20:00:11 2020 *filter :INPUT ACCEPT [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] :DOCKER-ISOLATION-STAGE-1 - [0:0] :DOCKER-ISOLATION-STAGE-2 - [0:0] :DOCKER-USER - [0:0] -A FORWARD -j DOCKER-USER -A FORWARD -j DOCKER-ISOLATION-STAGE-1 -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -o docker0 -j DOCKER -A FORWARD -i docker0 ! -o docker0 -j ACCEPT -A FORWARD -i docker0 -o docker0 -j ACCEPT -A DOCKER -d 172.17.0.4/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 443 -j ACCEPT -A DOCKER -d 172.17.0.4/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 80 -j ACCEPT -A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2 -A DOCKER-ISOLATION-STAGE-1 -j RETURN -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP -A DOCKER-ISOLATION-STAGE-2 -j RETURN -A DOCKER-USER -j RETURN COMMIT # Completed on Sun Apr 5 20:00:11 2020 Dan > > 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 1 --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:
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
On Sun, Apr 05, 2020 at 02:48:34PM +0100, Jake Howard wrote: > On Sat, 4 Apr 2020, at 19:01, Simon Kelley wrote: > > On 31/03/2020 13:51, Jake Howard wrote: > > > On Mon, 30 Mar 2020, at 20:42, Simon Kelley wrote: > > >> On 28/03/2020 20:38, Jake Howard wrote: > > >>> > > >> > > >> 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. > > >> ... works for me ... > > >> 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? > > >> > > > 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. Ah "Docker". It would have helped to share that information earlier ... > > > If I run dnsmasq with the exact same config but on the host, where it > > > can see the different interfaces, works perfectly! Acknowledge (and thanks for the compliment) > > > 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? > > 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? Please elaborate that question, especially "destination address". Regards Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
> > 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 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 1 --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=1 > >> >> > 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.n
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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 1 --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=1 >> >> > 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.theke
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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? 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 1 --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=1 > >> > 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 > ___
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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 1 --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=1 >> > 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
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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. 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=1 > > 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
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
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=1 > 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] Fwd: dnsmasq localise-queries + addn-hosts
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. Config: ``` localise-queries no-resolv cache-size=1 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
