Re: [Dnsmasq-discuss] getting different responses from high traffic DNSmasq

[Chris Novakovic]

On 18/02/2021 09:44, Boris Behrens wrote:

This happened after the update from v2.76 to v2.80

Is there a way how I can debug that deeper.


If you're in a position to compile Dnsmasq from source and have an 
easily reproducible failure case (it sounds like you do), you could 
perform a bisection on the Dnsmasq Git repository to identify the commit 
that introduced the failure:


https://git-scm.com/docs/git-bisect

In brief:

git clone git://thekelleys.org.uk/dnsmasq.git
git bisect start
git bisect bad 91421cb7 # v2.80
git bisect good f186bdcb # v2.76
# make ...
# Run dnsmasq, try reproducing your failure case
# If it works as expected:
git bisect good
# If it doesn't:
git bisect bad
# Repeat from make ...

There are 140 commits between 2.76 and 2.80, so you'll need to build and 
test at most eight times to identify the breaking commit.




Am Mi., 17. Feb. 2021 um 19:06 Uhr schrieb Boris Behrens :


Hello people,
I've got a strange issue with a high traffic (>5 requests / sec) where it 
sometimes does not responde with the NXDOMAIN but with NOERROR.

When we ask the upstream DNS directly we always get a NXDOMAIN response.

We use DNSmasq 2.80-1.1ubuntu1.2
We worked around this issue by disabling the cache.

Someone got an idea what the problem is?

The following request are made in a frame of 2 seconds:

/src # dig consul.mgmt.DOMAIN.TLD @10.0.0.204 -t ANY
; <<>> DiG 9.14.12 <<>> consul.mgmt.DOMAIN.TLD @10.0.0.204 -t ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10713
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 111292d8f7ef4f7ce124a223602d53418932dae2b1b0e5ea (good)
;; QUESTION SECTION:
;consul.mgmt.DOMAIN.TLD.  IN  ANY

;; AUTHORITY SECTION:
mgmt.DOMAIN.TLD.  3600  IN  SOA ipa2.DOMAIN.TLD. hostmaster.mgmt.DOMAIN.TLD. 
1613268909 3600 900 1209600 3600

;; Query time: 2 msec
;; SERVER: 10.0.0.204#53(10.0.0.204)
;; WHEN: Wed Feb 17 17:32:49 UTC 2021
;; MSG SIZE  rcvd: 133

---
/src # dig consul.mgmt.DOMAIN.TLD @10.0.0.204 -t ANY
; <<>> DiG 9.14.12 <<>> consul.mgmt.DOMAIN.TLD @10.0.0.204 -t ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54953
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2bd32278271acc813fbfb58b602d5345fddaeac8e012297f (good)
;; QUESTION SECTION:
;consul.mgmt.DOMAIN.TLD.  IN  ANY

;; Query time: 1 msec
;; SERVER: 10.0.0.204#53(10.0.0.204)
;; WHEN: Wed Feb 17 17:32:53 UTC 2021
;; MSG SIZE  rcvd: 81

---
/src # dig consul.mgmt.DOMAIN.TLD @10.0.0.204 -t ANY
; <<>> DiG 9.14.12 <<>> consul.mgmt.DOMAIN.TLD @10.0.0.204 -t ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46107
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: daeb796bf30117b9d54983db602d534f207b56ad08f7ad15 (good)
;; QUESTION SECTION:
;consul.mgmt.DOMAIN.TLD.  IN  ANY

;; AUTHORITY SECTION:
mgmt.DOMAIN.TLD.  3600  IN  SOA ipa2.DOMAIN.TLD. hostmaster.mgmt.DOMAIN.TLD. 
1613268909 3600 900 1209600 3600

;; Query time: 1 msec
;; SERVER: 10.0.0.204#53(10.0.0.204)
;; WHEN: Wed Feb 17 17:33:03 UTC 2021
;; MSG SIZE  rcvd: 133


Our config:
bind-interfaces
interface=ens18
all-servers
bogus-priv
no-resolv
no-hosts
server=/DOMAINS.TLD/10.0.255.11
server=/DOMAINS.TLD/10.0.255.12
server=/puppet/10.0.255.11
server=/puppet/10.0.255.12
rev-server=10.0.0.0/8,10.0.255.11
rev-server=10.0.0.0/8,10.0.255.12
#server=/DOMAINS/10.0.0.201#8600
#server=/DOMAINS/10.0.0.202#8600
#server=/DOMAINS/10.0.0.203#8600
#server=/DOMAINS/10.0.0.204#8600
#server=/DOMAINS/10.0.0.205#8600
server=/DOMAINS/10.0.240.11#8600
server=/DOMAINS/10.0.240.12#8600
server=/DOMAINS/10.0.240.13#8600
server=/consul/10.2.240.201#8600
server=/consul/10.2.240.202#8600
server=/consul/10.2.240.203#8600
server=8.8.8.8
server=8.8.4.4
addn-hosts=/etc/hosts.dnsmasq
no-negcache
cache-size=0
--
Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im 
groüen Saal.






___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] doc issue: dhcp on multiple interfaces

[Chris Novakovic]

On 26/04/2018 12:52, Harald Dunkel wrote:
> So it should be
> 
>     dhcp-range=tag:em1,10.0.0.10,10.0.0.254,12h
>     dhcp-range=tag:em2,10.0.1.10,10.0.1.254,12h
> 
> Or is it
> 
>     dhcp-range=set:em1,10.0.0.10,10.0.0.254,12h
>     dhcp-range=set:em2,10.0.1.10,10.0.1.254,12h

Assuming your intention is to restrict DHCP ranges to particular
interfaces, you should use "tag:".

> If I omit the "tag:" and "set:", which one is it?

That appears to be undefined behaviour, according to the man page. :)

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] doc issue: dhcp on multiple interfaces

[Chris Novakovic]

On 26/04/2018 12:52, Harald Dunkel wrote:
> So it should be
> 
>     dhcp-range=tag:em1,10.0.0.10,10.0.0.254,12h
>     dhcp-range=tag:em2,10.0.1.10,10.0.1.254,12h
> 
> Or is it
> 
>     dhcp-range=set:em1,10.0.0.10,10.0.0.254,12h
>     dhcp-range=set:em2,10.0.1.10,10.0.1.254,12h

Assuming your intention is to restrict DHCP ranges to particular
interfaces, you should use "tag:".

> If I omit the "tag:" and "set:", which one is it?

That appears to be undefined behaviour, according to the man page. :)

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] doc issue: dhcp on multiple interfaces

[Chris Novakovic]

On 26/04/2018 11:24, Harald Dunkel wrote:
> maybe I am too blind to see, but apparently something like
> 
> dhcp-range=em1,10.0.0.10,10.0.0.254,12h
> dhcp-range=em2,10.0.1.10,10.0.1.254,12h
> 
> is not mentioned in the man page. Is it possible that the
> interface part was lost?

If you're referring to the ability to limit particular DHCP ranges to
particular interfaces, the information's all in there (albeit admittedly
in pieces):

> The tag system works as follows: For each DHCP request, dnsmasq collects a 
> set of valid tags from active configuration lines which include set:, 
> including one from the dhcp-range used to allocate the address, one from any 
> matching dhcp-host (and "known" or "known-othernet" if a dhcp-host matches) 
> The tag "bootp" is set for BOOTP requests, and a tag whose name is the name 
> of the interface on which the request arrived is also set.

> -F, 
> --dhcp-range=[tag:[,tag:],][set:,][,|][,[,]][,  time>]
> -F, 
> --dhcp-range=[tag:[,tag:],][set:,][,|constructor:][,][,][,  time>]
> 
>   [...]
>   
>   The optional set: sets an alphanumeric label which marks this 
> network so that dhcp options may be specified on a per-network basis. When it 
> is prefixed with 'tag:' instead, then its meaning changes from setting a tag 
> to matching it. Only one tag may be set, but more than one tag may be matched.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DNSMASQ Not Sending ACK?

[Chris Novakovic]

On 22/09/2017 19:24, Jason Kary (jkary) wrote:
> Thank you for the update.  We are running version 2.66

2.66 is four and a half years old now, and those parts of the codebase
have been overhauled quite a lot since then --- is there any way you can
test your setup with 2.77 plus the patch in [2] from my initial reply
(or, better still, master/HEAD in the git repository)? Also, it'd be
helpful if you could post your full dnsmasq configuration.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCP Relay across VLANs

[Chris Novakovic]

On 15/09/2017 01:26, Ray Ramadorai wrote:
> Software versions working case:
> 
> Kernel:  Linux Openwrt 3.18.23 #1 SMP Sun Jan 31 15:32:38 CET 2016
> x86_64 GNU/Linux
> 
> DNSMasq:  Dnsmasq version 2.73  Copyright (c) 2000-2015 Simon Kelley
> 
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP
> no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC
> loop-detect inotify
> 
>  
> 
> Software versions NOT working case:
> 
> Kernel:  Linux LEDE 4.4.71 #0 SMP Wed Jun 7 19:24:41 2017 x86_64 GNU/Linux
> 
> Dnsmasq version 2.77  Copyright (c) 2000-2016 Simon Kelley
> 
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP
> no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID
> loop-detect inotify

DHCP relay was broken by a commit shortly before 2.76 was released [1],
and this breakage was itself recently fixed by a commit that'll
eventually make it into 2.78 [2]. If you're able to compile dnsmasq
yourself, could you check that [2] fixes the problem you're seeing?

[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ff325644c7afae2588583f935f4ea9b9694eb52e
[2]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1649f709e7351f0c6bbfedc5bd32744b330e2bcd

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] pxe booti: dnsmasq 2.76 not sending dhcp-force-option 66

[Chris Novakovic]

On 02/09/2017 13:46, Floris Bos wrote:
> Pi 3 does not like instant replies.
> 
> Add to dnsmasq.conf:
> 
> dhcp-reply-delay=1

Just a warning, however: Floris's patch that adds this feature [1] was
committed between 2.76 and 2.77, so you'll either have to upgrade to
2.77 or recompile 2.76 with that patch applied (and I seem to recall it
not applying cleanly, having tried to do just that previously).

[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=503c609149fcbde42e345116844fe55db59c233f

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ProxyDHCP with dnsmasq 2.77 - wrong suffix

[Chris Novakovic]

On 31/08/2017 08:39, Aaron Salwat wrote:
> I've noticed what seems to be a bug with the NBP suffix for BIOS
> clients in version 2.77 for dnsmasq, which was working fine in 2.76.
> 
> I have not confirmed if the issue occurs within a normal DHCP/PXE
> environment, only for proxyDHCP.
> 
> 
> Along with my DHCP server, the following configuration allows proper
> booting for my BIOS and UEFI clients.
> 
> 
> pxelinux options 209, 210 have been hardcoded into the NBP files, as I
> could not for the life of me find a way to send these options using the
> --pxe-service fields.
> 
> 209 = /pxeboot/
> 
> 210 = bios.cfg
> 
> 210 = efi64.cfg (for syslinux.e64, likewise for syslinux.e32)
> 
> 
> Relevant lines within dnsmasq.conf:
> 
> dhcp-no-override
> 
> dhcp-range=10.0.60.200,proxy,255.255.255.0
> 
> pxe-service=x86PC,"Boot BIOS PXE",lpxelinux
> pxe-service=IA32_EFI,"Boot UEFI-32bit PXE",syslinux.e32
> pxe-service=BC_EFI,"Boot UEFI-BC PXE",syslinux.e64
> pxe-service=X86-64_EFI,"Boot UEFI-64bit PXE",syslinux.e64
> 
> Using dnsmasq 2.76, the above configuration successfully finds and boots
> the "/pxeboot/lpxelinux.0" NBP file.
> 
> Change over to 2.77,  and I see the following within dnsmasq logs:
> dnsmasq-tftp[732]: file /pxeboot/lpxelinux not found
> 
> Interestingly, if I add the suffix to the config, so that dnsmasq.conf
> now shows:
> pxe-service=x86PC,"Boot BIOS PXE",lpxelinux.0
> 
> I now receive the following within dnsmasq logs:
> dnsmasq-tftp[772]: file /pxeboot/lpxelinux.0.0 not found
> 
> 
> The simple workaround is to just remove the suffix from the
> "lpxelinux" file, then it all flows normally.
> Please disregard me if I am wrong, but this behaviour seems to be
> the complete reverse of what is described on the man page, under
> "--pxe-service".

This was a regression introduced just before 2.77 was released. It has
since been patched [1] and will be fixed in 2.78. If this is a
significant problem for your setup, you could apply that patch manually
in the meantime.

[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2446514e716075cfe2be35e2a9b9de4eacdbac99

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Fix broken translations after commit 730c6745

[Chris Novakovic]

Commit 730c6745 makes a number of fixes to typos, among them the
messages reporting that asynchronous logging is unavailable in Solaris
and Android in src/dnsmasq.c. This is a gettext-localised string, and
the corresponding msgids in each of the translations weren't updated to
reflect the typo fixes, breaking these two translations for all
localisations.

This commit ports the typo fixes to the affected msgids in po/*.po,
fixing all translations for these strings.
From 93cc62dabb33bd141741684fa7e95303966506c5 Mon Sep 17 00:00:00 2001
From: Chris Novakovic <ch...@chrisn.me.uk>
Date: Mon, 17 Jul 2017 18:40:20 +0100
Subject: [PATCH] Fix broken translations after commit 730c6745

Commit 730c6745 makes a number of fixes to typos, among them the
messages reporting that asynchronous logging is unavailable in Solaris
and Android in src/dnsmasq.c. This is a gettext-localised string, and
the corresponding msgids in each of the translations weren't updated to
reflect the typo fixes, breaking these two translations for all
localisations.

This commit ports the typo fixes to the affected msgids in po/*.po,
fixing all translations for these strings.
---
 po/de.po| 6 +++---
 po/es.po| 6 +++---
 po/fi.po| 6 +++---
 po/fr.po| 6 +++---
 po/id.po| 6 +++---
 po/it.po| 6 +++---
 po/no.po| 6 +++---
 po/pl.po| 6 +++---
 po/pt_BR.po | 6 +++---
 po/ro.po| 6 +++---
 10 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/po/de.po b/po/de.po
index 9856141..dac96f1 100644
--- a/po/de.po
+++ b/po/de.po
@@ -12,7 +12,7 @@ msgstr ""
 "Project-Id-Version: dnsmasq 2.77\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2009-06-18 12:24+0100\n"
-"PO-Revision-Date: 2017-05-11 19:45+0200\n"
+"PO-Revision-Date: 2017-07-17 18:30+0100\n"
 "Last-Translator: Conrad Kostecki <c...@conrad-kostecki.de>\n"
 "Language-Team: German <d...@li.org>\n"
 "Language: de\n"
@@ -1300,11 +1300,11 @@ msgid "conntrack support not available: set 
HAVE_CONNTRACK in src/config.h"
 msgstr "Conntrack-Unterstützung nicht verfügbar: Aktiviere HAVE_CONNTRACK in 
src/config.h"
 
 #: dnsmasq.c:205
-msgid "asychronous logging is not available under Solaris"
+msgid "asynchronous logging is not available under Solaris"
 msgstr "asynchrone Protokollierung unter Solaris nicht verfügbar"
 
 #: dnsmasq.c:210
-msgid "asychronous logging is not available under Android"
+msgid "asynchronous logging is not available under Android"
 msgstr "Asynchrone Protokollierung unter Android nicht verfügbar"
 
 #: dnsmasq.c:215
diff --git a/po/es.po b/po/es.po
index 06cdf94..c266a4a 100644
--- a/po/es.po
+++ b/po/es.po
@@ -7,7 +7,7 @@ msgstr ""
 "Project-Id-Version: dnsmasq 2.67\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2009-06-18 12:24+0100\n"
-"PO-Revision-Date: 2013-10-04 13:24+0100\n"
+"PO-Revision-Date: 2017-07-17 18:30+0100\n"
 "Last-Translator: Vicente Soriano <vic...@gmail.com>\n"
 "Language-Team:\n"
 "Language: es\n"
@@ -1354,12 +1354,12 @@ msgstr "servidor TFTP no disponible: fijar HAVE_TFTP en 
src/config.h"
 
 #: dnsmasq.c:205
 #, fuzzy
-msgid "asychronous logging is not available under Solaris"
+msgid "asynchronous logging is not available under Solaris"
 msgstr "registro asíncrono no está disponible bajo Solaris"
 
 #: dnsmasq.c:210
 #, fuzzy
-msgid "asychronous logging is not available under Android"
+msgid "asynchronous logging is not available under Android"
 msgstr "registro asíncrono no está disponible bajo Solaris"
 
 #: dnsmasq.c:215
diff --git a/po/fi.po b/po/fi.po
index ddf202d..01c716f 100644
--- a/po/fi.po
+++ b/po/fi.po
@@ -7,7 +7,7 @@ msgstr ""
 "Project-Id-Version: dnsmasq 2.24\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2009-06-18 12:24+0100\n"
-"PO-Revision-Date: 2005-11-28 22:05+\n"
+"PO-Revision-Date: 2017-07-17 18:30+0100\n"
 "Last-Translator: Simon Kelley <si...@thekelleys.org.uk>\n"
 "Language-Team: Finnish <translation-team...@lists.sourceforge.net>\n"
 "Language: fi\n"
@@ -1282,11 +1282,11 @@ msgid "conntrack support not available: set 
HAVE_CONNTRACK in src/config.h"
 msgstr ""
 
 #: dnsmasq.c:205
-msgid "asychronous logging is not available under Solaris"
+msgid "asynchronous logging is not available under Solaris"
 msgstr ""
 
 #: dnsmasq.c:210
-msgid "asychronous logging is not available under Android"
+msgid "asynchronous logging is not available under Android"
 msgstr ""
 
 #: dnsmasq.c:215
diff --git a/po/fr.po b/po/fr.po
index 355045b..00a4e67 10064

Re: [Dnsmasq-discuss] [PATCH] Fix broken translations after commit 730c6745

[Chris Novakovic]

On 17/07/2017 18:50, Chris Novakovic wrote:
> Commit 730c6745 makes a number of fixes to typos, among them the
> messages reporting that asynchronous logging is unavailable in Solaris
> and Android in src/dnsmasq.c. This is a gettext-localised string, and
> the corresponding msgids in each of the translations weren't updated to
> reflect the typo fixes, breaking these two translations for all
> localisations.
> 
> This commit ports the typo fixes to the affected msgids in po/*.po,
> fixing all translations for these strings.

I thought it'd be churlish of me to set myself as the Last-Translator
for each localisation, given that I didn't actually do any translating... :)

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Funny came behaviour

[Chris Novakovic]

On 09/07/2017 09:17, Gareth Howell wrote:
> I have dnsmasq serving IP addresses. I also have domain=agdon.net
>  and a couple of cname= lines
> (see https://pastebin.com/aGLrWa5K for more detail)
> 
> However, if you look at the transcript
> at https://pastebin.com/YdVpx7y1  you will see that dig behaves properly
> but pings behave oddly. The client is a Mac.

"expand-hosts" doesn't apply to CNAME records created with the "cname"
option, which explains the odd behaviour you're seeing --- you'll need
to manually add the FQDN to the record:

cname=dashticz.agdon.net,domoticz.agdon.net
cname=piaware.agdon.net,d15c087.agdon.net

This shouldn't be a problem, since dnsmasq will be pushing the domain
search list "agdon.net" via DHCP so your Mac's resolver will look up
dashticz.agdon.net when given dashticz anyway.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Tag from interface name?

[Chris Novakovic]

On 08/07/2017 20:46, Simon Kelley wrote:
> On 04/07/17 09:06, Chris Novakovic wrote:
>> On 03/07/2017 15:53, Brian Rak wrote:
>>> I'd like to be able to classify DHCP requests based on the interface
>>> they come in on.  I'd like to have a tag based on the interface name
>>> (so, if the request came in over br0, I'd have a br0 tag to match on).
>>>
>>> Is there any way of accomplishing this with dnsmasq currently?  My
>>> interfaces don't actually have an IP address assigned, so I can't match
>>> by IP.
>>
>> Dnsmasq provides this for you already --- it's just not mentioned in the
>> man page for some reason.
>>
> 
> You just have to look harder :)
> 
> "The  tag  system  works as follows: For each DHCP request, dnsmasq col‐
>  lects a set of valid tags from active configuration lines which include
>  set:,  including  one  from  the  dhcp-range  used to allocate the
>  address, one from any matching dhcp-host (and "known"  if  a  dhcp-host
>  matches)  The  tag  "bootp"  is set for BOOTP requests, and a tag whose
>  name is the name of the interface on which the request arrived is  also
>  set."

Consider me sufficiently schooled :)


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Tag from interface name?

[Chris Novakovic]

On 03/07/2017 15:53, Brian Rak wrote:
> I'd like to be able to classify DHCP requests based on the interface
> they come in on.  I'd like to have a tag based on the interface name
> (so, if the request came in over br0, I'd have a br0 tag to match on).
> 
> Is there any way of accomplishing this with dnsmasq currently?  My
> interfaces don't actually have an IP address assigned, so I can't match
> by IP.

Dnsmasq provides this for you already --- it's just not mentioned in the
man page for some reason.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] --dont-mirror-queries option - updated for 2.77

[Chris Novakovic]

Here's the "don't mirror queries" patch from last year updated for 2.77,
partially as a courtesy to anyone who was using it and partially to
stimulate discussion about including functionality like this in a future
version of dnsmasq.

To quickly recap:

- The patch prevents dnsmasq from forwarding an incoming DNS query to an
upstream server if its IP address matches the IP address from which the
query originated. This makes it possible for two dnsmasq DNS servers to
be mutually dependent on each other, without the risk of inducing
forwarding loops.

- There seemed to be agreement that this would also be a useful thing to
have outside of my mad network setup.

- Simon expressed the possibility of genericising the patch by including
a trace of dnsmasq instances that a query had been processed by in an
EDNS0 record, which could then be checked to prevent all forwarding
loops, not just those of length 2.

- Concerns raised about Simon's idea included the possibility of
firewalls interfering with the larger DNS packets this would create, and
the privacy implications of the details of internal DNS setups leaking
out over public networks.

My patch is certainly a hack, and I'd like to see something like this
genericised in the way Simon described. Here's a proposal that ought to
keep everyone happy:

- Every dnsmasq instance stamps the EDNS0 record with some identifier (I
don't know dnsmasq well enough to know what the source of this could be,
sorry) for each request it forwards to upstream servers.

- If an incoming request's EDNS0 record contains the dnsmasq instance's
identifier, dnsmasq replies with REFUSED.

- This behaviour becomes the default. A new option --no-dns-loop-detect
avoids stamping the identifier into any forwarded queries, for people
who don't want this behaviour (an optional list of upstream servers can
be given as an argument to --no-dns-loop-detect to specify that queries
should be stamped except for those forwarded to the listed servers).
Another option --only-dns-loop-detect only stamps the identifier into
queries forwarded to the specified servers. Both options are allowed to
be specified in --servers-file files, so the list of upstream servers
affected by this can be changed as the upstream servers change.

The extra options would be useful for people who don't want information
about their internal DNS infrastructure to leak publicly, or know that
upstream servers are protected by firewalls that may drop large DNS
query packets with EDNS0 records.

I'm afraid I don't know anywhere near enough about dnsmasq to implement
either Simon's original idea or my proposed refinement, but hopefully
someone does...

On 04/03/2016 21:35, Simon Kelley wrote:
> On 01/03/16 21:23, Kurt H Maier wrote:
>> On Tue, Mar 01, 2016 at 06:50:14PM +, Simon Kelley wrote:
>>> On 24/02/16 23:38, Kurt H Maier wrote:
>>>
>>> This approach assumes that all the servers are dnsmasq, and running the
>>> loop-detection code, which is a reasonable assumption. Once a query
>>> escapes from the "cloud" of interconnected dnsmasq servers towards an
>>> upstream server, the EDNS0 options are no longer required and can be
>>> stripped without problem. (They will be stripped from replies.)
>>
>> Part of the concern here was that in some of these deployments we have  
>> 'enclaves' of devices with dnsmasq on the edge nodes.  I'm concerned
>> about the interaction on those edges, because EDNS0 data suddenly
>> disappearing has caused problems for me in the past.  I'm also concerned
>> about whether we'll have to re-architect our DNS infrastructure to avoid
>> EDNS0 data growing too large. Do you have draft code for this solution 
>> anywhere?
>>
>> Thanks,
>> khm
>>
>>
> No draft code yet. No version of dnsmasq has ever removed EDNS0 from
> queries, and note that queries are all we're concerned about here. The
> EDNS0 options should not be included in replies. Packet size of queries
> is not generally a problem.
> 
> 
> Cheers,
> 
> Simon.

From f17894815ee3fe0828bec118433c56e3014f Mon Sep 17 00:00:00 2001
From: Chris Novakovic <ch...@chrisn.me.uk>
Date: Wed, 7 Jun 2017 23:39:06 +0100
Subject: [PATCH] Added --dont-mirror-queries option

This commit adds the --dont-mirror-queries option. When enabled, this
option prevents dnsmasq from forwarding an incoming DNS query to an
upstream server if its IP address matches the IP address from which the
query originated. This makes it possible for two dnsmasq DNS servers to
be mutually dependent on each other, without the risk of inducing
forwarding loops.
---
 man/dnsmasq.8 |  6 ++
 src/dnsmasq.h |  3 ++-
 src/forward.c | 27 ++-
 src/option.c  |  3 +++
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
in

Re: [Dnsmasq-discuss] Dnsmasq-2.77 pxelinux.0 question

[Chris Novakovic]

On 05/06/17 12:38, Steven Shiau wrote:
> I have a question about using dnsmasq 2.77 as the PXE booting service.
> This is running on Debian Sid amd64 version, the package is from Debian
> repository:
> 
> root@debian:~# dpkg -l dnsmasq
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---=
> ii  dnsmasq2.77-1   all  Small
> caching DNS proxy and DHCP/TFTP server
> 
> root@debian:~# dpkg -l dnsmasq-base
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---=
> ii  dnsmasq-base   2.77-1   amd64Small
> caching DNS proxy and DHCP/TFTP server
> 
> I have configured dnsmasq.conf as:
> root@debian:~# cat /etc/dnsmasq.conf
> log-dhcp
> dhcp-no-override
> enable-tftp
> tftp-root=/tftpboot/nbi_img
> dhcp-range=192.168.120.3,proxy
> 
> ## PXEClient:Arch:0
> pxe-service=X86PC, "Boot BIOS PXE", pxelinux.0
> 
> ## PXEClient:Arch:7
> pxe-service=BC_EFI, "Boot UEFI BC", bootx64.efi
> 
> ## PXEClient:Arch:9
> pxe-service=X86-64_EFI, "Boot UEFI X86-64", bootx64.efi
> 
> pxe-prompt="Booting PXE Client", 1
> 
> However, when I boot the PXE client, it fails and the error messages is
> "PXE-T01: file /tftpboot/nbi_img/pxelinux/pxelinux.0.0" not found"
> as attached.
> 
> I remember in dnsmasq <= 2.75, it used to append ".0" to the PXE
> basename file. However, for dnsmasq 2.76, the PXE basename is not
> appended with ".0" if I use basename as "pxelinux.0".
> 
> I did not see any related description about this change in the changelog
> for dnsmasq-2.77:
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q2/011542.html
> 
> Is this just a regression, or is it meant to revert to the old way? Or
> where am I wrong?

This appears to be a regression that was introduced in commit f77700aa,
right before the release of 2.77. The logic of appending "." was
inverted by that commit. I'm just testing a quick patch I wrote that
restores the expected behaviour, then I'll post it to the list...

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Fix logic of appending "." to PXE basename

[Chris Novakovic]

Commit f77700aa, which fixes a compiler warning, also breaks the
behaviour of prepending "." to basenames in --pxe-service: in
situations where the basename contains a ".", the "." suffix is
erroneously added, and in situations where the basename doesn't contain
a ".", the "." suffix is erroneously omitted.

A patch against the git HEAD is attached that inverts this logic and
restores the expected behaviour of --pxe-service.
>From 38a119885b1a2a16c515ba65681d0a9a97bb7cd0 Mon Sep 17 00:00:00 2001
From: Chris Novakovic <ch...@chrisn.me.uk>
Date: Mon, 5 Jun 2017 22:13:46 +0100
Subject: [PATCH] Fix logic of appending "." to PXE basename

Commit f77700aa, which fixes a compiler warning, also breaks the
behaviour of prepending "." to basenames in --pxe-service: in
situations where the basename contains a ".", the "." suffix is
erroneously added, and in situations where the basename doesn't contain
a ".", the "." suffix is erroneously omitted. This commit inverts
this logic and restores the expected behaviour of --pxe-service.
---
 src/rfc2131.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/rfc2131.c b/src/rfc2131.c
index a679470..1c850e5 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -836,10 +836,10 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
 	  
 	  if (strchr(service->basename, '.'))
 	snprintf((char *)mess->file, sizeof(mess->file),
-		"%s.%d", service->basename, layer);
+		"%s", service->basename);
 	  else
 	snprintf((char *)mess->file, sizeof(mess->file),
-		"%s", service->basename);
+		"%s.%d", service->basename, layer);
 	  
 	  option_put(mess, end, OPTION_MESSAGE_TYPE, 1, DHCPACK);
 	  option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ, htonl(context->local.s_addr));
-- 
2.9.0

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Dnsmasq, multiple subnets/gateways and option 82

[Chris Novakovic]

On 11/05/2017 01:40, Keith Lyons wrote:
> Currently I have  dhcp-option=3,10.192.4.1 set for the active subnet, I
> will need to add 10.192.5.1 and 10.192.6.1 for the others as they come
> online. I have seen some other posts about utilizing multiple nics, each
> assigned to one of the subnet, is this the best
> way to accomplish what I am attempting to do?

It's certainly the easiest. You'll find that the interface name can also
be used as a tag, allowing for the following setup:

interface=eth0,eth1,eth2
dhcp-range=tag:eth0,10.192.4.2,10.192.4.254,10m
dhcp-range=tag:eth1,10.192.5.2,10.192.5.254,10m
dhcp-range=tag:eth2,10.192.6.2,10.192.6.254,10m

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients

[Chris Novakovic]

On 29/03/2017 18:13, Kurt H Maier wrote:
> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote:
>> The PXE boot firmware implementation of the Raspberry Pi 3
>> has a bug causing it to fail if it receives replies
>> instantly.
>>
>> As a workaround ensure there is a minimum delay of one
>> second if the client is a Pi.
>>
>> On Linux it looks up the exact receive time of the UDP
>> packet with the SIOCGSTAMP ioctl to prevent multiple
>> delays if multiple packets come in around the same time,
>> or if there already was a delay caused by a ping check.
>
>
> Why not have a configurable dhcp-delay setting instead of putting
> device-specific quirks into the source code of dnsmasq forever?

+1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on
older RPi models (as well as the built-in wifi adapter on the RPi 3)
also use the b8:27:eb OUI, and this artificial delay oughtn't be applied
to them.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] returns REFUSED when first response comes from non-recursive server

[Chris Novakovic]

On 27/02/17 10:04, Daniel Pocock wrote:
> 
> I've observed the following problem:
> 
> - dnsmasq is sending queries to 5 servers, one of them is not recursive
> and only answers for a private domain
> 
> - if the first response dnsmasq receives comes from the non-recursive
> server (REFUSED), then dnsmasq is sending a REFUSED response to the client
> 
> - dnsmasq subsequently receives a response from one of the recursive servers

This is expected behaviour. One possibility is to configure dnsmasq to
forward requests to the non-recursive server only for the private
domain, e.g.:

--server=/private.domain/non.recursive.server.ip

and a matching --rev-server directive if appropriate.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL

[Chris Novakovic]

On 22/11/16 15:03, Martin Wetterwald wrote:
> We found what we think is a bug (at least a not wanted behaviour), but
> it seems it's actually a feature, when looking at commits 4ace25c5 and
> 51967f980 (pasted at the end of this email).

4ace25c5 is a red herring: that provides REFUSED responses with the
behaviour you're looking for. Whether the same behaviour ought to be
applied to SERVFAIL responses is for Simon to decide: the commit message
for 51967f980 isn't clear about why SERVFAIL should be considered a
"successful" upstream response, but I'm sure there was a reason, and I'm
sure he can fill us in.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Compile Error.

[Chris Novakovic]

On 24/08/16 16:31, Tony White wrote:
> inotify.c:92: error: ‘IN_NONBLOCK’ undeclared (first use in this function)
> inotify.c:92: error: (Each undeclared identifier is reported only once
> inotify.c:92: error: for each function it appears in.)
> inotify.c:92: error: ‘IN_CLOEXEC’ undeclared (first use in this function)
> make[1]: *** [inotify.o] Error 1
> 
> CentOS 5.11
> x86_64

Your version of glibc (probably 2.5, on CentOS 5.11) is too old, and
doesn't contain those flags --- the least painful route to fixing this
is likely to be to upgrade to a newer CentOS release.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] --dont-mirror-queries option

[Chris Novakovic]

On 13/02/2016 13:09, Simon Kelley wrote:
> Will try and remember to reply to your other points, but on this one,
> the way I'd do it (assuming you don't have problems with slow or
> intermittent connectivity) is to have one (primary) dnsmasq which is the
> DHCP server for all three networks. You declare all the address ranges
> in the config of the primary, and tell the secondaries to do dhcp-relay
> to the primary.
> 
> That keeps all the DHCP address information in the primary, so as long
> as the secondaries forward to the primary, all names should be resolvable.

Ideally this is what I would have done, but the three sites (which each
use their own /26 subnet inside a common /24) are geographically
distant, connected to each other via a layer-3 VPN over somewhat
unreliable links --- this means that each site really has to have an
authoritative DHCP server for its own /26 subnet, and the only thing
suitable for splitting across all three sites is DNS service (that way,
if area1 gets cut off from the rest of the /24, area1's dnsmasq can
still assign DHCP leases for its own /26, and it doesn't matter that it
can't resolve a name that's active on area2 because it wouldn't be able
to communicate with that host anyway).

Cheers,
Chris

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] --dont-mirror-queries option

[Chris Novakovic]

On 05/02/2016 22:22, Simon Kelley wrote:
> That's very ingenious!

Thanks --- Kurt (repeatedly) described it in far less flattering terms :)

> Your post begs the question "Will you merge the patch?"
> 
> I'm not sure: it's a pretty niche application, and there are lots of
> cases where it does the wrong thing. For instance when a query arrives
> from area1, there's nothing to check (and no way of checking) that the
> query comes from dnsmasq, and not a stub resolver running on the same
> machine.

Indeed: sadly, there's no way around this (unless you know there's no
stub resolver running on the other host, and since I have full control
over all three hosts I know that won't be the case).

> Is there not a conceptually simpler fix for this by splitting master
> in two, maybe listening on different ports?
> 
> area1 is configured to forward to master1, which is configured to
> forward again to area2. area2 forwards to master2, which forwards to
> area1 when it can't answer.

Before writing this patch I tried to get similar functionality by
setting up secondary DNS-only servers on each of the hosts and having
them refuse queries that couldn't be answered locally, then configuring
the primary dnsmasq servers in the way you suggested. I decided that it
wasn't an ideal solution because I'm also using the DHCP server
functionality of dnsmasq on all three hosts, and I wanted the names of
their DHCP clients to be resolved correctly too. In that scenario, the
definition of "locally" is murky: the secondary dnsmasqs technically
don't have DHCP lease databases of their own, and would have to share
the dnsmasq.leases file (or, at least, the leases contained within it)
with the primary dnsmasq. I wrote a --dhcp-script script to work around
this, but it didn't give me the results I was looking for (I'm hazy on
the details now, but I recall that the secondary dnsmasq wasn't always
notified of static /and/ dynamic DHCP lease events and the two dnsmasqs
would get out of sync, which sort of defeated the point). I tried to
solve the problem in a number of other ways that wouldn't have required
patching the code (including using --leasefile-ro and maintaining my
"own" leases database elsewhere), but again there were strange corner
cases that would lead to each dnsmasq giving a different response to the
same query.

I agree with you: the patch adds a weird option that's only useful if
you have full control over the DNS-resolving hosts on a network, but for
those who do and want this kind of behaviour, it's really the only way
to be sure that the results of a particular DNS query are correct.

Cheers,
Chris


> On 29/01/16 13:38, Chris Novakovic wrote:
>> I have a (rather odd, and perhaps ill-advised) network setup in
>> which names in a particular domain (e.g. example.com) are split
>> across three sites, and I need three dnsmasq servers to be mutually
>> dependent in the following hierarchy to resolve names for that
>> domain:
> 
>> master / \ /   \ area1   area2
> 
>> If a client sends a query for x.example.com to area1 that area1
>> can't answer, or if another client sends a query for y.example.com
>> to area2 that area2 can't answer, both servers will forward the
>> query to master, which is configured (with --server) to be the sole
>> upstream DNS server for example.com on both area1 and area2. If
>> master can't answer a query for example.com, it is configured to
>> forward the query to area1 and area2. Clearly, master shouldn't
>> forward queries that originate from area1 back to area1: this would
>> lead to an infinite forwarding loop.
> 
>> The attached patch implements a new option, --dont-mirror-queries.
>> When enabled, this option prevents dnsmasq from forwarding a
>> request to an upstream server if its IP address matches that of the
>> sender of the query. I suppose this could be considered a dynamic,
>> per-query version of the --dns-loop-detect option that is only
>> capable of detecting 1-hop loops.
> 
>> Kurt H Maier <k...@sciops.net> was the brains of this operation,
>> helping me figure out the part of forward.c that needed patching.
> 
>> Cheers, Chris
> 
> 
> 
>> ___ 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
> 

-- 
Chris Novakovic
CPAN: CHRISN (http://search.cpan.org/~chrisn)

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] --dont-mirror-queries option

[Chris Novakovic]

I have a (rather odd, and perhaps ill-advised) network setup in which
names in a particular domain (e.g. example.com) are split across three
sites, and I need three dnsmasq servers to be mutually dependent in the
following hierarchy to resolve names for that domain:

  master
   / \
  /   \
  area1   area2

If a client sends a query for x.example.com to area1 that area1 can't
answer, or if another client sends a query for y.example.com to area2
that area2 can't answer, both servers will forward the query to master,
which is configured (with --server) to be the sole upstream DNS server
for example.com on both area1 and area2. If master can't answer a query
for example.com, it is configured to forward the query to area1 and
area2. Clearly, master shouldn't forward queries that originate from
area1 back to area1: this would lead to an infinite forwarding loop.

The attached patch implements a new option, --dont-mirror-queries. When
enabled, this option prevents dnsmasq from forwarding a request to an
upstream server if its IP address matches that of the sender of the
query. I suppose this could be considered a dynamic, per-query version
of the --dns-loop-detect option that is only capable of detecting 1-hop
loops.

Kurt H Maier <k...@sciops.net> was the brains of this operation, helping
me figure out the part of forward.c that needed patching.

Cheers,
Chris
From bc963171d1a5d46566c3835e66145532b8269ac8 Mon Sep 17 00:00:00 2001
From: Chris Novakovic <ch...@chrisn.me.uk>
Date: Fri, 29 Jan 2016 13:04:02 +
Subject: Added --dont-mirror-queries option

This commit adds the --dont-mirror-queries option. When enabled, this
option prevents dnsmasq from forwarding an incoming DNS query to an
upstream server if its IP address matches the IP address from which the
query originated.
---
 man/dnsmasq.8 |  6 ++
 src/dnsmasq.h |  3 ++-
 src/forward.c | 27 ++-
 src/option.c  |  3 +++
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index b6fe6b4..d361c42 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -370,6 +370,12 @@ the upstream server through which it was sent is disabled and this event is logg
 set of upstream servers changes, the test is re-run on all of them, including ones which
 were previously disabled.
 .TP
+.B --dont-mirror-queries
+Don't forward DNS queries to upstream DNS servers whose IP address
+matches that of the original sender of the query. This option makes
+it possible for two dnsmasq DNS servers to be mutually dependent on
+each other, without the risk of inducing forwarding loops.
+.TP
 .B --stop-dns-rebind
 Reject (and log) addresses from upstream nameservers which are in the
 private IP ranges. This blocks an attack where a browser behind a
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 9d4d6b3..5487da2 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -237,7 +237,8 @@ struct event_desc {
 #define OPT_TFTP_NO_FAIL   52
 #define OPT_SCRIPT_ARP 53
 #define OPT_MAC_B6454
-#define OPT_LAST   55
+#define OPT_DONT_MIRROR55
+#define OPT_LAST   56
 
 /* extra flags for my_syslog, we use a couple of facilities since they are known 
not to occupy the same bits as priorities, no matter how syslog.h is set up. */
diff --git a/src/forward.c b/src/forward.c
index 9b464d3..a437b4c 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -440,8 +440,33 @@ static int forward_query(int udpfd, union mysockaddr *udpaddr,
 	  /* only send to servers dealing with our domain.
 	 domain may be NULL, in which case server->domain 
 	 must be NULL also. */
+  
+  /* If --dont-mirror-queries is enabled, don't forward the query to this upstream
+   * server if it has the same IP address as the sender of the original query */
+  int is_mirrored_query = 0;
+  if (option_bool(OPT_DONT_MIRROR))
+{
+  char sender_ip[ADDRSTRLEN], upstream_ip[ADDRSTRLEN];
+  
+  if (udpaddr->sa.sa_family == AF_INET)
+inet_ntop(AF_INET, >in.sin_addr, sender_ip, ADDRSTRLEN);
+#ifdef HAVE_IPV6
+  else
+inet_ntop(AF_INET6, >in6.sin6_addr, sender_ip, ADDRSTRLEN);
+#endif
+  
+  if (start->addr.sa.sa_family == AF_INET)
+inet_ntop(AF_INET, >addr.in.sin_addr, upstream_ip, ADDRSTRLEN);
+#ifdef HAVE_IPV6
+  else
+inet_ntop(AF_INET6, >addr.in6.sin6_addr, upstream_ip, ADDRSTRLEN);
+#endif
+  
+  is_mirrored_query = (strcmp(sender_ip, upstream_ip) == 0);
+}
 	  
-	  if (type == (start->flags & SERV_TYPE) &&
+	  if (is_mirrored_query == 0 &&
+  type == (start->flags & SERV_TYPE) &&
 	  (type != SERV_HAS_DOMAIN || hostname_isequal(domain, start->domain)) &&
 	  !(start->flags & (SERV_LITERAL_ADDRESS | SERV_LOOP)))
 	{
diff --git a/src/option.c b/src/opti

[Dnsmasq-discuss] [PATCH] Regression: dnsmasq replies to forwarded query too early when receiving REFUSED response from upstream server

[Chris Novakovic]

When a query is forwarded to multiple upstream servers, a REFUSED
response from an upstream server triggers an immediate REFUSED response
to the original query from dnsmasq: responses from all other servers are
silently discarded, ignoring the possibility that one of the other
upstream servers might answer the query. This appears to be the case in
both the latest stable dnsmasq version (2.75) and the head of the master
branch in git.

Commit 51967f9807665dae403f1497b827165c5fa1084b (from March 2014)
appears to contain a typo that causes this behaviour: "RCODE(header) !=
REFUSED" was removed from the conditional, instead of "RCODE(header) !=
SERVFAIL". I've attached a patch against git master that fixes the
(presumed) typo and provides the behaviour I'd expect.

Cheers,
Chris
From 42804dafeadc2a16357f5683c7a1b8111f979241 Mon Sep 17 00:00:00 2001
From: Chris Novakovic <ch...@chrisn.me.uk>
Date: Mon, 25 Jan 2016 02:22:12 +
Subject: Treat REFUSED (not SERVFAIL) as an unsuccessful upstream response

Commit 51967f9807665dae403f1497b827165c5fa1084b began treating SERVFAIL
as a successful response from an upstream server (thus ignoring future
responses to the query from other upstream servers), but a typo in that
commit means that REFUSED responses are accidentally being treated as
successful instead of SERVFAIL responses.

This commit corrects this typo and provides the behaviour intended by
commit 51967f9: SERVFAIL responses are considered successful (and will
be sent back to the requester), while REFUSED responses are considered
unsuccessful (and dnsmasq will wait for responses from other upstream
servers that haven't responded yet).
---
 src/forward.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/forward.c b/src/forward.c
index 414f988..9b464d3 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -853,7 +853,7 @@ void reply_query(int fd, int family, time_t now)
  we get a good reply from another server. Kill it when we've
  had replies from all to avoid filling the forwarding table when
  everything is broken */
-  if (forward->forwardall == 0 || --forward->forwardall == 1 || RCODE(header) 
!= SERVFAIL)
+  if (forward->forwardall == 0 || --forward->forwardall == 1 || RCODE(header) 
!= REFUSED)
 {
   int check_rebind = 0, no_cache_dnssec = 0, cache_secure = 0, bogusanswer 
= 0;
 
-- 
1.8.4

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss