Re: [Dnsmasq-discuss] dnsmasq v2.86?

[Kevin Darbyshire-Bryant]

> On 12 Aug 2021, at 10:06, Simon Kelley  wrote:
> 
> This is useful information, but the backtraces are puzzling: the code
> isn't in tight loop, certainly.
> 
> 
> I wonder if the v4only.arpa thing is not a coincidence?
> 
> Some things to try, please.
> 
> 1) When the dnsmasq process is faulted, run
> 
> strace -p 
> 
> 2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case
> that's the whole trigger.
> 
> 3) Same but straight to stubby
> 
> dig @127.0.0.1 -p 5453 ipv4only.arpa
> 
> 
> 4) Take a look in /usr/share/dnsmasq/rfc6761.conf
> 
> Is .arpa mentioned in there?

For reference, the default content is

# RFC6761 included configuration file for dnsmasq
#
# includes a list of domains that should not be forwarded to Internet name 
servers
# to reduce burden on them, asking questions that they won't know the answer to.

server=/bind/
server=/invalid/
server=/local/
server=/localhost/
server=/onion/
server=/test/

I wrote it :-)

Kevin



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq v2.86?

[Kevin Darbyshire-Bryant]

Hi Andre,

This is curious ‘cos I’ve just been running 2.88test6 for the past 28 days (I 
was away in Japan for a month and was banned from touching the openwrt router 
whilst I was away) with stubby without any problems.

My stubby config is different:

# Autogenerated configuration from uci data
resolution_type: GETDNS_RESOLUTION_STUB
round_robin_upstreams: 1
appdata_dir: "/var/etc/stubby"
trust_anchors_backoff_time: 2500
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 1
listen_addresses:
  - 127.0.0.1@5453
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
upstream_recursive_servers:
  - address_data: 2606:4700:4700::
tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com”

and my dnsmasq config is wildly different, so I’m not sure looking for 
differences in config is going to help, although I note I don’t validate dnssec 
instead trusting my upstreams to do it.

Try installing & using ’strace’ on the errant dnsmasq to get a flavour of what 
it’s doing syscall wise, hopefully that will give some clues whilst the clever 
people on this list come up with better suggestions.

An additional idea, enable ‘log-queries’, an idea of the last queries handled 
by dnsmasq before it goes AWOL might reveal a pattern.


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] feature: dictionary order import of addn-hosts dirs?

[Kevin Darbyshire-Bryant]

> On 8 Aug 2021, at 14:54, Ed W  wrote:
> 
> 
> Quoting from https://www.dictionary.com/browse/condescending
> 
> "To be condescending is to interact with others in a way that implies that 
> you’re superior to them.
> It especially refers to when this is done in an arrogant or patronizing way"
> 
> ..."Being condescending often involves not only what is said, but also how 
> it’s said. A
> condescending tone is often one that sounds like it’s directed at a child.”

> 
> 
> I notice you like to offer snippy responses quite regularly on this mailing 
> list. Can I recommend
> you read a few articles such as:
> 
> 
> https://compassionatecoding.com/blog/2016/8/25/tech-has-a-toxic-tone-problemlets-fix-it
> 
> 
> I would remind you that I have generally been happy to pay for my feature 
> requests. Please don't
> feel encouraged for you to offer development time though, I don't feel that I 
> wish to employ you.

I’m tired of Geert too and I’ve run out of patience.  I don’t care if I get 
banned from the list for this and it’s probably the reaction that he wants but 
it’s not my loss if I get kicked.

Fuck off Geert.  You’re a pain in the arse.  And yet more tricks with your 
“monthly posting”, complete with spelling errors.

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Regarding: (Dnsmasq-discuss) localise-queries on ipv6 server does not work with ipv4-only hosts

[Kevin Darbyshire-Bryant]

> On 17 Jul 2021, at 01:32, f...@gmx.de wrote:
> 
> 
> 
> Am 16.07.2021 um 13:42 schrieb Geert Stappers:
>> ...
> All your messages are not helpfull and off topic.
> 
> Please consider to use twitter or Facebook in the future

I agree.  I have long bitten my tongue on the antics of Geert from when he 
first appeared on this list in 2017 even to the extent of unsubscribing.  I 
know others have done so too.  As has been said on this list already "Can you 
go find another hobby or somewhere else to troll? I have yet to see any kind of 
usefulness to your belittling users and their questions.  And the cutesy 
changing of your name along with the witty only to you signatures are quite 
draining.”  Yes, appearing as ‘Monthly Posting’ or ‘Yes’ or ‘Feed Back’ or ‘Web 
Search’ is real cute.  The sheer number of posts and displayed attitude come 
across as “I’m the moderator of this list” when there is no such thing.  I wish 
there were, for surely this annoying turd that simply won’t flush would be long 
gone.  Whilst the intention might have been to increase the signal to noise 
ratio on this list, quite the opposite has been achieved.

Kevin

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] file not found messages from tftp

[Kevin Darbyshire-Bryant]

> On 8 Jul 2021, at 20:46, Kevin Darbyshire-Bryant 
>  wrote:
> 
> It does now!  See attached patch - unbelievably this compiled 1st time for me 
> which is unbelievable with my history on C typos - not actually run tested.
V2 with a manpage tweak at no extra charge


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-V2-add-quiet-tftp.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] file not found messages from tftp

[Kevin Darbyshire-Bryant]

> On 8 Jul 2021, at 18:30, Kevin Darbyshire-Bryant 
>  wrote:
> 
> Signed PGP part
> 
> 
>> On 8 Jul 2021, at 17:10, Aleksander Mazur  wrote:
>> 
> 
>> I'm sorry but I don't understand your point.
>> AFAIK valid DNS query requests are already completely hidden (not even under
>> DEBUG). Does it feel wrong as well?
>> 
>> Anyway, those fake TFTP errors turn my syslog into dnsmasq's verbose trace 
>> log.
>> Lowering their severity to DEBUG (since they are completely useless unless 
>> you
>> are debugging dnsmasq or PXE/TFTP client) restores usability of the syslog.
> 
> I wonder if there is a third way - At the risk of yet another dnsmasq option 
> I note that ‘—-quiet-tftp’ does not yet exist.

It does now!  See attached patch - unbelievably this compiled 1st time for me 
which is unbelievable with my history on C typos - not actually run tested.

Kevin

0001-add-quiet-tftp.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] file not found messages from tftp

[Kevin Darbyshire-Bryant]

> On 8 Jul 2021, at 17:10, Aleksander Mazur  wrote:
> 

> I'm sorry but I don't understand your point.
> AFAIK valid DNS query requests are already completely hidden (not even under
> DEBUG). Does it feel wrong as well?
> 
> Anyway, those fake TFTP errors turn my syslog into dnsmasq's verbose trace 
> log.
> Lowering their severity to DEBUG (since they are completely useless unless you
> are debugging dnsmasq or PXE/TFTP client) restores usability of the syslog.

I wonder if there is a third way - At the risk of yet another dnsmasq option I 
note that ‘—-quiet-tftp’ does not yet exist.  ‘—quiet-dhcp’ & friends exist 
with "Suppress logging of the routine operation of these protocols. Errors and 
problems will still be logged.” as the accompanying manpage text.  We can then 
argue as to whether "file not found" is an error/problem that should be 
reported and for this case “no”, but permission errors “yes"


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Change in behaviour of --server

[Kevin Darbyshire-Bryant]

Hi Simon,

An eager OpenWrt tester of current dnsmasq master has noticed the following 
change in behaviour:

Openwrt uses a conf file containing a list of RFC6761 domains that are 
considered undesirable to forward, reducing load on upstream servers etc.  This 
conf file contains lines such as "server=/onion/“.  Said user overrides this 
with a line in main config file ’server=/onion/127.0.0.1#2053’.  Unfortunately 
current dnsmasq looks through its servers and returns ’NXDOMAIN’.  dnsmasq 
v2.85 says ‘yeah fine, I’ll forward that to 127.0.0.1#2053’

The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 config 
file - 2)  Take advantage of new syntax and use ’server=/*.onion/127.0.0.1#2053’

I’m flagging this as a change in behaviour and I’m not sure how syntactically 
it can or even should be fixed, or just documented as a change in behaviour. eg.

Should there be a difference (& what should it be) between

--server=/onion/
--server=/onion/127.0.0.1#2053

(forward to 127.0.0.1#2053)

and

--server=/onion/127.0.0.1#2053
--server=/onion/

(not sure!)

or even worse

--server=/onion/127.0.0.1#2053
--server=/onion/
--server=/onion/127.0.0.1#2153

(use both #2053 & #2153?)

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Kevin Darbyshire-Bryant]

> On 5 Jul 2021, at 21:12, Simon Kelley  wrote:
> 
> On 05/07/2021 19:31, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>>> On 5 Jul 2021, at 16:53, Dominik DL6ER  wrote:
>>> 
>>> Hey Simon,
>>> 
>>> the current dnsmasq master version contains a bug rewriting all
>>> NXDOMAIN replies from upstream with NOERROR.
>>> 
>>> The error has been introduced in commit
>>> d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
>>> ultimately caused by
>> 
>> Oooh what fun! :-)
>> 
>> Attached patch fixes for me
>> 
>> 
> 
> That's not the correct fix.


Goes to show how much I really know :-D

At least I got one fix right.

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Kevin Darbyshire-Bryant]

> On 5 Jul 2021, at 16:53, Dominik DL6ER  wrote:
> 
> Hey Simon,
> 
> the current dnsmasq master version contains a bug rewriting all
> NXDOMAIN replies from upstream with NOERROR.
> 
> The error has been introduced in commit
> d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
> ultimately caused by

Oooh what fun! :-)

Attached patch fixes for me


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-fix-lookups.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Maybe there is a typo in build_server_array()

[Kevin Darbyshire-Bryant]

Hi Xingcong,

> On 1 Jul 2021, at 03:06, Xingcong Li  wrote:
> 
> Hello, Is there a typo in function build_server_array()? (in file 
> domain-match.c)

I agree with your analysis and fix.  I’ve attached a ‘git formatted’ patch that 
hopefully Simon can just apply.

You’re good at spotting these sorts of things… what else have you seen? :-)

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-exclude-looping-servers-when-building-server-array.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] blocklists, blocking servers, rebind attacks & general aaarrggh

[Kevin Darbyshire-Bryant]

As an ‘experiment’ I tried switching from my own local ‘adblocking’ solution to 
using an upstream adblocking resolver, eg. cloudflare’s 1.1.1.2 or 1.1.1.3 
service.

The local adblock solution uses (multiple!) ‘—address/naughtydomain.foo/‘ lines 
that cause dnsmasq to return ’NXDOMAIN’ - fair enough.

Cloudflare (& others I’ve tested) return ‘0.0.0.0’ or ‘::’ instead, not 
NXDOMAIN.  With rebind protection enabled (--stop-dns-rebind), even with 
--rebind-localhost-ok I get log ’spam’ warning of possible rebind attacks due 
to the ‘0.0.0.0’ address response.

I can turn ‘0.0.0.0’ into NXDOMAIN by using --bogus-nxdomain=0.0.0.0 and that 
works fine and stops the rebind warnings.  However ‘::’ still gets through if 
an  is specifically requested.  There is no equivalent bogus-nxdomain for 
ipv6.

The dnsmasq manpage (under —address) advised "Note that NULL addresses [0.0.0.0 
& ::] normally work in the same way as localhost, so beware that clients 
looking up these names are likely to end up talking to themselves.”  Ideally 
then 0.0.0.0 & :: would both be turned into NXDOMAIN.

Should ‘0.0.0.0/32’ be excluded from the rebind checks/accepted by the 
‘—rebind-localhost-ok’ option.  It’s currently being caught by a ‘0.0.0.0/8’ 
check.

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH 2/2] rfc3315: fix incorrect logical '&&' warning

[Kevin Darbyshire-Bryant]

rfc3315.c:1711:28: warning: use of logical '&&' with constant operand 
[-Wconstant-logical-operand]
if (!(addr_list->flags && ADDRLIST_DECLINED) ||
   ^  ~

It's a flag bit so should be bitwise '&' operator

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/rfc3315.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rfc3315.c b/src/rfc3315.c
index eec8776..43ed4f8 100644
--- a/src/rfc3315.c
+++ b/src/rfc3315.c
@@ -1708,7 +1708,7 @@ static int config_valid(struct dhcp_config *config, 
struct dhcp_context *context
 return 0;
 
   for (addr_list = config->addr6; addr_list; addr_list = addr_list->next)
-if (!(addr_list->flags && ADDRLIST_DECLINED) ||
+if (!(addr_list->flags & ADDRLIST_DECLINED) ||
difftime(now, addr_list->decline_time) >= (float)DECLINE_BACKOFF)
   {
addrpart = addr6part(_list->addr.addr6);
-- 
2.21.1 (Apple Git-122.3)


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

[Dnsmasq-discuss] [PATCH 1/2] suppress non linux network unused var warnings

[Kevin Darbyshire-Bryant]

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/dnsmasq.c | 4 +++-
 src/network.c | 3 +++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 10f19ea..286a1cd 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1860,7 +1860,8 @@ static void check_dns_listeners(time_t now)
if (daemon->tcp_pids[i] == 0 && daemon->tcp_pipes[i] == -1)
  {
char a;
-   
+   (void)a; /* suppress potential unused warning */
+
daemon->tcp_pids[i] = p;
daemon->tcp_pipes[i] = pipefd[0];
 #ifdef HAVE_LINUX_NETWORK
@@ -1911,6 +1912,7 @@ static void check_dns_listeners(time_t now)
  if (!option_bool(OPT_DEBUG))
{
  char a = 0;
+ (void)a; /* suppress potential unused warning */
  alarm(CHILD_LIFETIME);
  close(pipefd[0]); /* close read end in child. */
  daemon->pipe_to_parent = pipefd[1];
diff --git a/src/network.c b/src/network.c
index cb956ca..4bada37 100644
--- a/src/network.c
+++ b/src/network.c
@@ -785,6 +785,8 @@ int set_ipv6pktinfo(int fd)
 /* Find the interface on which a TCP connection arrived, if possible, or zero 
otherwise. */
 int tcp_interface(int fd, int af)
 { 
+  (void)fd; /* suppress potential unused warning */
+  (void)af; /* suppress potential unused warning */
   int if_index = 0;
 
 #ifdef HAVE_LINUX_NETWORK
@@ -1187,6 +1189,7 @@ int local_bind(int fd, union mysockaddr *addr, char 
*intname, unsigned int ifind
 #endif
 }
 
+  (void)intname; /* suppress potential unused warning */
 #if defined(SO_BINDTODEVICE)
   if (intname[0] != 0 &&
   setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, intname, IF_NAMESIZE) == -1)
-- 
2.21.1 (Apple Git-122.3)


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

[Dnsmasq-discuss] [PATCH] option.c: fix NO_DHCP6 build error

[Kevin Darbyshire-Bryant]

Errors encountered if building with 'NO_DHCP6' introduced by
commit 137286e9baecf6a3ba97722ef1b49c851b531810

option.c: In function 'dhcp_config_free':
option.c:1040:24: error: 'struct dhcp_config' has no member named 'addr6'; did 
you mean 'addr'?
for (addr = config->addr6; addr; addr = tmp)
^
addr
option.c: In function 'one_opt':
option.c:3227:7: error: 'struct dhcp_config' has no member named 'addr6'; did 
you mean 'addr'?
  new->addr6 = NULL;
   ^
   addr

Wrap new code in ifdef HAVE_DHCP6

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/option.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/option.c b/src/option.c
index 6e8bb8b..f8ba616 100644
--- a/src/option.c
+++ b/src/option.c
@@ -1036,6 +1036,7 @@ static void dhcp_config_free(struct dhcp_config *config)
   if (config->flags & CONFIG_CLID)
 free(config->clid);
 
+#ifdef HAVE_DHCP6
   if (config->flags & CONFIG_ADDR6)
{
  struct addrlist *addr, *tmp;
@@ -1046,6 +1047,7 @@ static void dhcp_config_free(struct dhcp_config *config)
  free(addr);
}
}
+#endif
 
   free(config);
 }
@@ -3227,7 +3229,9 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma
new->netid = NULL;
new->filter = NULL;
new->clid = NULL;
+#ifdef HAVE_DHCP6
new->addr6 = NULL;
+#endif
 
while (arg)
  {
-- 
2.21.1 (Apple Git-122.3)


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

Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

[Kevin Darbyshire-Bryant]

> On 27 Jul 2019, at 16:34, Art Greenberg  wrote:
> 
> I had been running dnsmasq on a machine on my network and using addn-hosts 
> for ad blocking. My router was configured with my ISP's DNS servers.
> 
> I used "net:red" to assign the router as DNS server for certain devices (Roku 
> streamers, notably) to avoid the ad blocking, because some of the apps on the 
> router would not work properly with the ad blocking in place. This told those 
> devices to go directly to the router for DNS services.
> 
> router/gateway 192.168.2.1
> dnsmasq machine 192.168.2.11
> 
> ## dnsmasq.conf fragment
> 
> domain-needed
> bogus-priv
> no-resolv
> local=/artg.tv/
> interface=eth0
> domain=artg.tv
> server=8.8.8.8,8.8.4.4
> 
> dhcp-option=option:dns-server,192.168.2.11
>  ## use dnsmasq machine for DNS
> dhcp-option=net:red,option:dns-server,192.168.2.1
> 
> dhcp-host=00:01:03:27:84:95,192.168.2.15,martha   
>  ## typical of computer assignments
> dhcp-host=d8:31:34:36:d0:18,192.168.2.135,ROKU-1-WIFI,net:red## typical 
> of ad blocking avoidance
> 
> ## end dnsmasq.conf fragment
> 
> This all worked fine.
> 
> Then I obtained a newer router and installed OpenWRT on it. This, too, worked 
> fine until I moved dnsmasq onto the router. The configuration now looks like 
> this:
> 
> router/gateway 192.168.2.1
> dnsmasq machine 192.168.2.1
> 
> ## dnsmasq.conf fragment
> 
> domain-needed
> bogus-priv
> no-resolv
> local=/artg.tv/
> interface=br-lan
> domain=artg.tv
> server=8.8.8.8,8.8.4.4
> 
> dhcp-option=option:dns-server,192.168.2.1 
>## use dnsmasq on the router for DNS
> dhcp-option=net:red,option:dns-server,8.8.8.8,8.8.4.4
> ## Google public DNS servers
> 
> dhcp-host=00:01:03:27:84:95,192.168.2.15,martha   
>  ## typical of computer assignments
> dhcp-host=d8:31:34:36:d0:18,192.168.2.135,ROKU-1-WIFI,net:red## typical 
> of ad blocking avoidance
> 
> Now the Roku streamers and some of the apps on them aren't so happy. Despite 
> the "net:red" tag, dnsmasq is intercepting all DNS requests and it is 
> returning 0.0.0.0 when the host being looked up is in one of the addn-hosts 
> files.

dnsmasq won’t be intercepting requests, it will answer requests that are sent 
to it.  It doesn’t snoop on the wire looking for requests to hijack.

That sort of behaviour can be configured with firewall rules, ie. redirect any 
packets sent to port 53 on this host to another host/port combination.  Indeed 
adblock itself has this exact option to do so, it’s called 'option 
adb_forcedns’.  It would be worth checking this is set to ‘0’.

Also it would be worth checking on the router that something else hasn’t done 
this sort of redirection.

adblock implements it with the following rules:

iptables -v -t nat -L | grep -i adblock
0 0 REDIRECT   tcp  --  anyany anywhere anywhere
 tcp dpt:domain /* !fw3: Adblock DNS, port 53 */ redir ports 53
   30  2164 REDIRECT   udp  --  anyany anywhere anywhere
 udp dpt:domain /* !fw3: Adblock DNS, port 53 */ redir ports 53
0 0 REDIRECT   tcp  --  anyany anywhere anywhere
 tcp dpt:853 /* !fw3: Adblock DNS, port 853 */ redir ports 853
0 0 REDIRECT   udp  --  anyany anywhere anywhere
 udp dpt:853 /* !fw3: Adblock DNS, port 853 */ redir ports 853
0 0 REDIRECT   tcp  --  anyany anywhere anywhere
 tcp dpt:mdns /* !fw3: Adblock DNS, port 5353 */ redir ports 5353
   32  9171 REDIRECT   udp  --  anyany anywhere anywhere
 udp dpt:mdns /* !fw3: Adblock DNS, port 5353 */ redir ports 5353



Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq compilation and dependencies: compilation macros and help

[Kevin Darbyshire-Bryant]

> On 12 Jun 2019, at 19:56, SALA MASSIMO  wrote:
> 
> Hi Geert
> 
> Ehm ... I mistyped writing the email.
> 
> I check my script:
> make COPTS="-DNO_AUTH -DNO_DHCP -DNO_INOTIFY -DNO_IPV6 -DNO_SCRIPT 
> -DNO_TFTP"
> 
> A quick glance at the source code: it seem to me the help arguments aren't 
> conditioned by the compilation macros.
> I need a confirm of this.
> It isn't documented but IMHO it should be.

Hi Massimo,

Yes it probably should be.  If it is any help, in openwrt we look (& parse) the 
output of ‘dnsmasq -v’ at run-time to determine what build-time options have 
been selected.  Maybe you also could use this approach?

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Insecure DS reply warning - false positives?

[Kevin Darbyshire-Bryant]

Hi All,

Part of the reason for submitting 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013026.html 
"[PATCH] dnssec: add hostname info to insecure DS warning” was to easily find 
out what domain was prompting the warning.

Some of my mystery ‘Insecure DS reply’ turns out to be this:

Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply received 
for 168.192.in-addr.arpa, check domain configuration and upstream DNS server 
DNSSEC support
Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply received 
for 168.192.in-addr.arpa, check domain configuration and upstream DNS server 
DNSSEC support
Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply received 
for 168.192.in-addr.arpa, check domain configuration and upstream DNS server 
DNSSEC support
Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply received 
for 168.192.in-addr.arpa, check domain configuration and upstream DNS server 
DNSSEC support
Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply received 
for 168.192.in-addr.arpa, check domain configuration and upstream DNS server 
DNSSEC support
Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply received 
for 168.192.in-addr.arpa, check domain configuration and upstream DNS server 
DNSSEC support

Is this a genuine configuration error on my/upstream’s part or is it false 
positive log spam?

(I think) The relevant bits from dnsmasq config:

dnssec
dnssec-check-unsigned

Upstream servers are Google’s 8.8.8.8 & friends.

Trust anchors:

trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address

[Kevin Darbyshire-Bryant]

> On 6 Apr 2019, at 12:01, Geert Stappers  wrote:
> 
> On Mon, Apr 01, 2019 at 01:02:20AM +0200, Pali Rohár wrote:
>> On Tuesday 12 February 2019 13:41:43 Geert Stappers wrote:
>>> On 06-02-2019 21:29, Pali Rohár wrote:
 On Friday 11 January 2019 17:52:43 Pali Rohár wrote:
> On Monday 17 December 2018 18:41:09 Pali Rohár wrote:
>> Currently IPv6 addresses are assigned to tuple (IAID, DUID). When system
>> changes IAID/DUID then old assigned IPv6 address cannot be reused, even
>> when in config file was DHCPv6 assignment based on MAC address (and not 
>> on
>> DUID).
> 
>   ...
> 
> Hello, can somebody look at this patch?
> 
> I remember that more people asked for ability to assign IPv6 address
> based on MAC address specified in config file, rather then IAID/DUID.
> 
 PING
 
>>> Another request for
>>> 
>>> Hey, could this patch get reviewed?
>>> 
>>> 
>> Hello, can somebody review this patch?
>> 
> 
> FWIW
> 
> * The (four months old) patch does get applied cleanly.
> * My compiler is happy with it
> * Executable remains running upon start ( no early crash )
> * I'm unable to test the (new) IPv6 functionality
> 
> 
> Where in the "patch pipeline" is Pali's patch?
> 
> 
> Regards
> Geert Stappers

I’ve been using this patch to tame qnap’s frustrating dhcpv6 assignment 
limitations for many months.  It’s immensely useful.


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

[Dnsmasq-discuss] [PATCH] dnssec: add hostname info to insecure DS warning

[Kevin Darbyshire-Bryant]

From: Kevin Darbyshire-Bryant 

Make the existing "insecure DS received" warning more informative by
reporting the domain name reporting the issue.

This may help identify a problem with a specific domain or server
configuration.

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/dnssec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/dnssec.c b/src/dnssec.c
index 9bf43a2..5e0686c 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -873,7 +873,7 @@ int dnssec_validate_ds(time_t now, struct dns_header 
*header, size_t plen, char
   
   if (rc == STAT_INSECURE)
 {
-  my_syslog(LOG_WARNING, _("Insecure DS reply received, do upstream DNS 
servers support DNSSEC?"));
+  my_syslog(LOG_WARNING, _("Insecure DS reply received for %s, check 
domain configuration and upstream DNS server DNSSEC support"), name);
   rc = STAT_BOGUS;
 }
   
-- 
2.20.1 (Apple Git-117)

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

Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.

[Kevin Darbyshire-Bryant]

Aha! I know this (it’s a Unix system… /)

> On 8 Feb 2019, at 09:49, John Robson  wrote:
> 
> Hi all,
> 
> I'm trying to understand the mechanism by which dnsmasq uses the resolvers 
> specified (in this case they are all specified in /etc/resolv.conf).
> Specifically I am trying to work out why dnsmasq is (erratically) sending the 
> same query to multiple servers, and not listening beyond the first response.

> Two questions:
>  - What triggers dnsmasq to forward a query to multiple upstream resolvers 
> (aside from the first query after startup, which seems reasonable)

From src/config.h
#define FORWARD_TEST 50 /* try all servers every 50 queries */
#define FORWARD_TIME 20 /* or 20 seconds */

The thread 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012226.html

>  - Why does dnsmasq not bother to listen for the second (or more) response - 
> which would surely be useful in terms of timing/aliveness information, as 
> well as less odd for the upstream server*.

Now that I cannot answer.


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

Re: [Dnsmasq-discuss] [PATCH] fix entries in /etc/hosts disabling static leases

[Kevin Darbyshire-Bryant]

> On 12 Jan 2019, at 21:55, Steven Siloti  wrote:
> 
> It is possible for a config entry to have one address family specified by a
> dhcp-host directive and the other added from /etc/hosts. This is especially
> common on OpenWrt because it uses odhcpd for DHCPv6 and IPv6 leases are
> imported into dnsmasq via a hosts file.

FYI: I’ve just backported this patch (and the missing brackets silly) to 
Openwrt master where it has apparently already solved one of our other 
developer’s dhcp lease mystery.

Good catch!  How on earth did you spot it?! :-)

Will wait a couple of days in case of unexpected fallout before updating 
openwrt-18.06.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

Re: [Dnsmasq-discuss] DHCP problem when moving from one WiFi SSID to another

[Kevin Darbyshire-Bryant]

> On 27 Dec 2018, at 08:45, Chris Green  wrote:
> 
>>> 
>>> 
>>> My laptop seems to lose its IP address whenever I move from one
>>> Draytek's WiFi to the other but only when the IP is assigned by
>>> dnsmasq.  If I connect to my guest network (192.168.6.x) then I get a
>>> IP address assigned by the 2860n and a good connection to the outside
>>> world.  If I then reconnect to the 'local' WiFi the laptop loses its
>>> IP address.  It's as if dnsmasq doesn't see the disconnection and
>>> doesn't answer the new DHCP broadcast from my laptop.  If I leave it
>>> disconnected for a minute or two and then re-connect to the WiFi it
>>> *does* get an IP.
>>> 
>>> 
>>> Can anyone explain what might be wrong and/or a fix or workaround?
>>> 
>>> 
> 
> He didn't really.  :-)   He said:-
> 
> "but I don't have any concrete suggestions on how to fix it. I think the SSID 
> change
> is a red-herring."
> 
> But, yes, it is basically the same issue, but now I'm not changing SSID.
> 
> I have now changed the dnsmasq configuration to set
> dhcp-authoritative, maybe that will do something.

One of the things that has always bothered me about these ‘linking lan switch 
ports between two wifi APs/one wifi AP/Router’ scenarios is the numerous levels 
of packet switching/bridging going on.  I dimly remember one of my own setups 
using a ‘dual AP’ that would happily roam from AP1 to AP2 but not the other 
way…until a bridge table entry timed out.  I wonder if that’s what is going on 
here?

The common scenario in terms of bridging/switching is something like (in the 
linux world):

AP1

Wifi Interface (or interfaces, think 2.4Ghz & 5Ghz radios) and LAN cpu 
interface are software bridged together.  So there’s bridge learning of which 
MAC is on which bridge port going on there.  The LAN cpu interface itself is 
often a hardware switch with built in learning of which MAC is on which 
physical switch port.  One of those ports is physically connected to AP2 which 
has:

AP2

A LAN port as part of a hardware switch with built in learning of which MAC 
address is on which port presented to the cpu as a LAN cpu port.  This is 
software bridged to a Wifi interface (or interfaces, think 2.4Ghz & 5Ghz 
radios) which has to learn which MAC appears on which port.


Roaming from one wireless radio on one AP to another wireless radio on another 
AP involves quite a lot of bridge table changes, I’m amazed it works at all.


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

Re: [Dnsmasq-discuss] [PATCH] Re: dhcp-boot & dhcp-reply-delay optional tag fixes

[Kevin Darbyshire-Bryant]

> On 14 Dec 2018, at 16:10, Petr Mensik  wrote:
> 
> Hi Kevin et al,
> 
> sure, your fix is correct one. I just found one more place where tags
> were required. Your pointer handling is not as hopeless as you are
> saying. :)

He he - It’s always good to get a second opinion though :-)  And you spotted 
another place I missed as well.

> 
> Sorry for inconvenience caused by my change. I miss some tests that
> would discover it, have to write them someday soon.
> 
> Petr

It seems the openwrt users have a very wide range of use cases and notice stuff 
;-)

Your more complete fix is in openwrt master - thank you.



Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

[Dnsmasq-discuss] dhcp-boot & dhcp-reply-delay optional tag fixes

[Kevin Darbyshire-Bryant]

Hi Simon et al,

It looks like Petr’s "Free config file values on parsing errors” commit turned 
the optional tags on dhcp-boot & dhcp-reply-delay to non-optional.

Attached is a patch that fixes it according to my testing but my ‘c’ and 
pointer handling is somewhat hopeless so could do with a proper sanity check, 
i.e. I don’t trust myself :-)

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-option-dhcp-boot-dhcp-reply-delay-tag-fixes.patch
Description: 0001-option-dhcp-boot-dhcp-reply-delay-tag-fixes.patch
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] fix ipv6 ipset bug in master

[Kevin Darbyshire-Bryant]

Hi Simon,

Another one fallen out of the openwrt tree shake :-)

ipv6 ipset addresses weren’t being set correctly.  patch attached 



Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-ipset-fix-ternary-order-swap.patch
Description: 0001-ipset-fix-ternary-order-swap.patch
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] build failure on master with NO_DHCPv6 and fix....

[Kevin Darbyshire-Bryant]

Hi Simon,

master has a build error when building without HAVE_DHCPv6

option.c: In function 'dhcp_context_free':
option.c:1042:15: error: 'struct dhcp_context' has no member named 
'template_interface'
   free(ctx->template_interface);

Sadly, need to put in a little conditional compilation ifdef'erey

Simplest patch in the world attached



Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-option-fix-non-DHCPv6-build-error.patch
Description: 0001-option-fix-non-DHCPv6-build-error.patch
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] static lease issues?

[Kevin Darbyshire-Bryant]

> On 6 Nov 2018, at 20:44, Simon Kelley  wrote:
> 
> Look at the tags on the first and second DHCPDISCOVERs. The first one is
> in "known" and the second is "known-othernet".
> 
> "known" means that the host has a dhcp-host or similar configuration
> which provides an address, and the address in in scope for the network
> it's talking from. "known-othernet" means the same, but the the address
> is NOT in scope.
> 
> That probably explains the DHCPNAK too.
> 
> The question is "what's changed". difficult to tell. Maybe the netmask
> on the interface?

Thanks Simon.  I noticed the ‘othernet’ tag but didn’t quite understand why it 
would be applied.  Have asked person affected for more clues :-)


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

[Dnsmasq-discuss] static lease issues?

[Kevin Darbyshire-Bryant]

Hi Simon, Hi List,

I’m hearing rumblings from the openwrt community that something isn’t right 
with static leases.   The behaviour manifests itself as the statically assigned 
host being unable to renew its lease.  e.g.

-this is okay
Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 available DHCP 
range: 192.168.0.100 -- 192.168.0.199
Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 client provides 
name: sylvester
Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 
DHCPDISCOVER(eth0.54) 00:11:22:33:44:55
Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 tags: lan, known, 
eth0.54
Nov  4 15:29:29 192.168.0.254 dnsmasq-dhcp[2378]: 424644159 DHCPOFFER(eth0.54) 
192.168.0.12 00:11:22:33:44:55
-but later

Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 available DHCP 
range: 192.168.0.100 -- 192.168.0.199
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 client provides 
name: sylvester
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 DHCPREQUEST(eth0.54) 
192.168.0.12 00:11:22:33:44:55
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 DHCPNAK(eth0.54) 
192.168.0.12 00:11:22:33:44:55 address not available
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 broadcast response
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 sent size:  1 
option: 53 message-type  6
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 sent size:  4 
option: 54 server-identifier  192.168.0.254
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 53015875 sent size: 21 
option: 56 message  61:64:64:72:65:73:73:20:6e:6f:74:20:61:76...
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 available DHCP 
range: 192.168.0.100 -- 192.168.0.199
Nov  4 15:52:32 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 client provides 
name: sylvester
Nov  4 15:52:36 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 
DHCPDISCOVER(eth0.54) 00:11:22:33:44:55
Nov  4 15:52:36 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 tags: lan, 
known-othernet, eth0.54
Nov  4 15:52:36 192.168.0.254 dnsmasq-dhcp[2378]: 1321333264 DHCPOFFER(eth0.54) 
192.168.0.190 00:11:22:33:44:55

I have yet to see this behaviour personally, so I’m putting this out there as 
a) anyone else b) any ideas on debugging?


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.

[Kevin Darbyshire-Bryant]

> On 25 Oct 2018, at 21:38, Kevin Darbyshire-Bryant 
>  wrote:
> 
> I think Openwrt is safe.   There will be a loud scream from me if it isn’t :-)
> 
> Cheers,
> 
> Kevin D-B
> 

In fact to prove it to myself I had a go at removing the NO_FORK compile time 
option (patch attached) and had no obvious problem with the resultant binary on 
Openwrt.

Whether Simon implements the change as I have done or takes the opportunity to 
simplify things that I don’t understand I don’t know, but NO_FORK v OPT_NO_FORK 
are different things and OPT_NO_FORK relies on NO_FORK *NOT* being defined.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-my-try-at-nofork.patch
Description: 0001-my-try-at-nofork.patch
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.

[Kevin Darbyshire-Bryant]

> On 25 Oct 2018, at 20:33, Shankar Unni  wrote:
> 
> On Oct 24, 2018, at 2:49 PM, Simon Kelley  wrote:
> 
>> […]
>> The next option in my sights is NO_FORK. This produces a
>> mostly-functional binary that never forks any new processes. It was
>> added long ago to support uclinux, the MMU-less version of Linux. As far
>> as I can tell, MMU-less linux is a dead project, and I'm minded to
>> remove NO_FORK. Opinions? Is this option vital to something I'm not
>> aware of?
> 
> From what i can see, this will kill off the ‘k’ option that’s used by many 
> process-management environments.  E.g. openwrt’s process management (the 
> procd daemon) depends on the originally-launched process to stick around (it 
> doesn’t know or care about the PID file), and does really ugly things if the 
> PID changes after launch.  It also doesn’t seem to have an option to pass in 
> an explicit PID file to read and poll.  (I just verified by removing the -k 
> option, and it keeps spawning more and more dnsmasqs..)
> 
> If you do want to do this, it’ll probably need a few months of warning and 
> preparation for various distros..

A quick glance at the code suggests you’ve misunderstood.  The compile time 
option ’NO_FORK’ is designed for systems that don’t have a fork system 
call….which is unusual to say the least.  A fair amount of code is *added* if 
NO_FORK is NOT defined… or to put in clearer English, the code to support 
‘fork’ is added in unless NO_FORK is defined.

The run-time option OPT_NO_FORK aka ‘-k’ is to prevent dnsmasq forking and as 
you say is used by some process management daemons to determine if a process 
under its control has died or not.  My reading of the code suggests that 
removing ’NO_FORK’ build option does NOT remove ‘-k’ OPT_NO_FORK run-time 
option.

I think Openwrt is safe.   There will be a loud scream from me if it isn’t :-)

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

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

Re: [Dnsmasq-discuss] CVE-2017-14495 PoC causes high CPU usage and denial of service against dnsmasq v2.79

[Kevin Darbyshire-Bryant]

> On 8 Oct 2018, at 02:58, Mouath Ibrahim  wrote:
> 
> Hello,
> 
> I ran the PoC supplied by Google research team found here: https://github.com/
> google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/
> CVE-2017-14495.py
> 
> and noticed immediately that dnsmasq process uses up 100% CPU usage and stops 
> responding to queries short after based on the original CVE the effect was 
> high memory usage but in this cause it was not.
> 
> note dnsmasq didn't have any of these options set "--add-mac, --add-cpe-id or 
> --add-subnet".
> 
> Regards,
> Mouath Ibrahim

I am unable to reproduce.  Against which version/s of dnsmasq did you try?


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


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

Re: [Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb

[Kevin Darbyshire-Bryant]

> On 19 Sep 2018, at 08:59, Kristian Evensen  wrote:
> 
> Hi Simon,
> 
> Thanks for a quick reply.
> 
> On Wed, Sep 19, 2018 at 12:23 AM Simon Kelley  wrote:
>> Thanks for the report. The obvious explanation is that whine_malloc() is
>> returning NULL, and the code should handle that. whine_malloc only
>> returns NULL if the system cannot allocate any more memory, which is
>> possible, but unlikely. Is your router very short on memory?
> 
> No, the router has plenty of memory (2GB) and I don't see the "failed
> to allocate"-message, so I guess whine_malloc() can't be the culprit.
> Since I am using OpenWRT, there could be some defines affecting the
> line numbers. I tried to read up on how ifdefs affects line numbers in
> gdb backtraces to see if the error could be somewhere else than the
> "default" line 1437, but I unfortunately couldn't find anything.
> Probably my google-foo is a bit rusty.
> 
> When looking over my notes, I see that I have made the following
> observations related to this bug:
> 
> * Crash happens quite rarely.
> * I have only seen the bug right after boot.
> * When the bug strikes, dnsmasq will enter a crash loop and never
> recover. I.e., I can restart dnsmasq as many times as I like, crash
> always happens.
> * If I start dnsmasq manually and run it in the foreground after a
> crash, I also see the error.
> 
> So there seems to be something in the system causing this error, but I
> can't figure out what.
> 
>> I think the best solution is to wrap all of
>> 
>>  *crecp = *source;
>>  crecp->flags &= ~(F_IPV4 | F_IPV6 | F_CNAME | F_DNSKEY | F_DS |
>> F_REVERSE);
>>  crecp->flags |= F_NAMEP;
>>  crecp->name.namep = name;
>> 
>>  cache_hash(crecp);
>> 
>> with
>> 
>> if (crecp)
>> {
>> }
> 
> Thanks, this is basically the same as my current fix, so I can already
> report that it is good :)
> 
> BR,
> Kristian
> 

And I backported the fix into openwrt master this morning.


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ubus FTBFS fix

[Kevin Darbyshire-Bryant]

> On 29 Jul 2018, at 22:34, Simon Kelley  wrote:
> 
> Gah, thanks. I broke the cardinal rule: never commit code you've tweaked
> and not compiled.

lol - we’ve all done it :-)

> I've modified my "dogfood" openWRT build to enable the UBUS code now, so
> I should pick this stuff up in future.

My own openwrt ‘experimental’ staging 
https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=shortlog;h=refs/heads/exp 
inevitably contains a ‘bump to next dnsmasq’ commit if there’s something newer 
than openwrt master lurking about.  You may find that useful.  Currently master 
is on dnsmasq v2.80test3 so I’ve that and all patches since in my tree……and the 
openwrt tweaks to enable building ubus and enabling in the startup script...

> Testing would be great, if you get chance.

and it works :-)

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Google's DNS and Insecure DS reply received, do upstream DNS servers support DNSSEC?

[Kevin Darbyshire-Bryant]

Greetings!

This isn’t a new problem but curiosity/frustration has now got the better of 
me.  I’ve a QNAP NAS box which registers itself under 
‘waldorfdb.myqnapcloud.com’ with both IPv4 & IPv6 addresses.

My home lan router provides DHCP & DNS service courtesy dnsmasq.  Sometimes my 
local browser is unable to resolve the above domain name and the “Insecure DS 
reply received” message is seen in the router’s syslog:

Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: 1087 
2a02:c7f:1231:2000::dc83/57269 query[A] waldorfdb.myqnapcloud.com from 
2a02:c7f:1231:2000::dc83
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: 1087 
2a02:c7f:1231:2000::dc83/57269 forwarded waldorfdb.myqnapcloud.com to 8.8.4.4
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: * 
2a02:c7f:1231:2000::dc83/57269 dnssec-query[DS] myqnapcloud.com to 8.8.4.4
Sat Jul 28 18:13:49 2018 daemon.warn dnsmasq[21675]: Insecure DS reply 
received, do upstream DNS servers support DNSSEC?
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: * 
2a02:c7f:1231:2000::dc83/57269 reply myqnapcloud.com is BOGUS DS
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: 1087 
2a02:c7f:1231:2000::dc83/57269 validation waldorfdb.myqnapcloud.com is BOGUS
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: 1087 
2a02:c7f:1231:2000::dc83/57269 reply waldorfdb.myqnapcloud.com is 151.227.238.60
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: 1088 192.168.219.142/51181 
query[A] waldorfdb.myqnapcloud.com from 192.168.219.142
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: 1088 192.168.219.142/51181 
forwarded waldorfdb.myqnapcloud.com to 8.8.4.4
Sat Jul 28 18:13:49 2018 daemon.info dnsmasq[21675]: * 192.168.219.142/51181 
dnssec-query[DS] myqnapcloud.com to 8.8.4.4
Sat Jul 28 18:13:50 2018 daemon.warn dnsmasq[21675]: Insecure DS reply 
received, do upstream DNS servers support DNSSEC?
Sat Jul 28 18:13:50 2018 daemon.info dnsmasq[21675]: * 192.168.219.142/51181 
reply myqnapcloud.com is BOGUS DS
Sat Jul 28 18:13:50 2018 daemon.info dnsmasq[21675]: 1088 192.168.219.142/51181 
validation waldorfdb.myqnapcloud.com is BOGUS
Sat Jul 28 18:13:50 2018 daemon.info dnsmasq[21675]: 1088 192.168.219.142/51181 
reply waldorfdb.myqnapcloud.com is 151.227.238.60

Curiously a few minutes later and all is well, or well enough that my client 
gets an answer:

Sat Jul 28 18:16:24 2018 daemon.info dnsmasq[21675]: 1121 
2a02:c7f:1231:2000::dc83/51183 query[A] waldorfdb.myqnapcloud.com from 
2a02:c7f:1231:2000::dc83
Sat Jul 28 18:16:24 2018 daemon.info dnsmasq[21675]: 1121 
2a02:c7f:1231:2000::dc83/51183 forwarded waldorfdb.myqnapcloud.com to 
2001:4860:4860::8844
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: * 
2a02:c7f:1231:2000::dc83/51183 dnssec-query[DS] myqnapcloud.com to 
2001:4860:4860::8844
Sat Jul 28 18:16:25 2018 daemon.warn dnsmasq[21675]: Insecure DS reply 
received, do upstream DNS servers support DNSSEC?
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: * 
2a02:c7f:1231:2000::dc83/51183 reply myqnapcloud.com is BOGUS DS
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1121 
2a02:c7f:1231:2000::dc83/51183 validation waldorfdb.myqnapcloud.com is BOGUS
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1121 
2a02:c7f:1231:2000::dc83/51183 reply waldorfdb.myqnapcloud.com is 151.227.238.60
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1122 192.168.219.142/59027 
query[A] waldorfdb.myqnapcloud.com from 192.168.219.142
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1122 192.168.219.142/59027 
forwarded waldorfdb.myqnapcloud.com to 2001:4860:4860::8844
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: * 192.168.219.142/59027 
dnssec-query[DS] myqnapcloud.com to 2001:4860:4860::8844
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: * 192.168.219.142/59027 
reply myqnapcloud.com is no DS
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1122 192.168.219.142/59027 
validation result is INSECURE
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1122 192.168.219.142/59027 
reply waldorfdb.myqnapcloud.com is 151.227.238.60
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1123 
2a02:c7f:1231:2000::dc83/59028 query[] waldorfdb.myqnapcloud.com from 
2a02:c7f:1231:2000::dc83
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1123 
2a02:c7f:1231:2000::dc83/59028 forwarded waldorfdb.myqnapcloud.com to 
2001:4860:4860::8844
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1123 
2a02:c7f:1231:2000::dc83/59028 validation result is INSECURE
Sat Jul 28 18:16:25 2018 daemon.info dnsmasq[21675]: 1123 
2a02:c7f:1231:2000::dc83/59028 reply waldorfdb.myqnapcloud.com is 
2a02:c7f:1231:2000::c


I only seem to see this behaviour if using Google's public DNS.

Anyone else seeing this sort of thing?  Help! :-)  I’m at your disposal.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing 

[Dnsmasq-discuss] ubus FTBFS fix

[Kevin Darbyshire-Bryant]

Hi Simon,

A couple of FTBFS typos in master at the moment related to ubus integration.  
Fix attached, though not actually run tested..yet.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0005-dnsmasq.c-fix-OPT_UBUS-option-usage.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

[Kevin Darbyshire-Bryant]

> On 25 May 2018, at 13:07, Oliver Freyermuth  
> wrote:
> 
> Dear dnsmasqers,
> 
> I fear the following is a design issue of DHCPv6, but I wonder if there's a 
> way to overcome it with dnsmasq...


Hi Oliver,

I’ve a similar/same problem when rebooting some QNAP NAS boxen, first 
boot/introduction to dnsmasq and they get both IPv4 & v6 addresses set to fixed 
values based on MAC address.  On reboot whilst IPv4 is fine, IPv6 is not 
reallocated to the original address but rather a new one.  By curious 
co-incidence I just started looking into this problem today though it has been 
bugging me for months :-)  Have tried various combinations of MAC address & 
DUID.

Without meaning to thread hijack!  If it’s not effectively the same issue will 
gladly start a new thread.


First boot with fresh dnsmasq
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 client MAC 
address: 24:5e:be:0c:bc:ba
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
DHCPREPLY(br-lan) 2a02:c7f:beef:2000::e 
00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba Statler
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 tags: lan, 
known, dhcpv6, br-lan
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 14 
option:  2 server-id  00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 40 
option:  3 ia-na  IAID=3132886206 T1=21600 T2=37800
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 nest size: 24 
option:  5 iaaddr  2a02:c7f:beef:2000::e PL=43200 VL=43200
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size:  9 
option: 13 status  0 success
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size:  1 
option:  7 preference  255
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 29 
option: 24 domain-search  lan.darbyshire-bryant.me.uk
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 16 
option: 23 dns-server  2a02:c7f:beef:2000::da2b:da2b
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 38 
option: 39 FQDN  Statler.lan.darbyshire-bryant.me.uk


And now a reboot of the client:
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 available 
DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000::
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 client MAC 
address: 24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
DHCPADVERTISE(br-lan) 2a02:c7f:beef:2000::9c72 
00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 tags: lan, 
known, dhcpv6, br-lan
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
14 option:  1 client-id  00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
14 option:  2 server-id  00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
40 option:  3 ia-na  IAID=3132886206 T1=21600 T2=37800
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 nest size: 
24 option:  5 iaaddr  2a02:c7f:beef:2000::9c72 PL=43200 VL=43200
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size:  
9 option: 13 status  0 success
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size:  
1 option:  7 preference  255
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
29 option: 24 domain-search  lan.darbyshire-bryant.me.uk
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
16 option: 23 dns-server  2a02:c7f:beef:2000::da2b:da2b
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size:  
9 option: 39 FQDN  Statler
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 available 
DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000::
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 client MAC 
address: 24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 
DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 
DHCPREPLY(br-lan) 2a02:c7f:beef:2000::9c72 
00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 tags: lan, 
known, dhcpv6, br-lan
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 sent size: 
14 option:  1 client-id  

Re: [Dnsmasq-discuss] upstream server selection algorithm - bug?

[Kevin Darbyshire-Bryant]

> On 15 May 2018, at 17:00, Dominik DL6ER  wrote:
> 
> Dear Kevin,
>> Obviously it has to at least try the others occasionally to check it’s made 
>> the correct choice.   But I’m seeing dnsmasq make the same request to *ALL* 
>> servers quite frequently and am curious as to why?
> 
> dnsmasq is trying all servers quite frequently, either every 50 queries or 10 
> seconds (whatever happens first) if I'm not mistaken. This fits well to your 
> observation.
> 
> I changed this locally to checking every 1000 queries (or every 10 minutes) 
> and this is working great (I compile dnsmasq from source).
> 
> Best,
> Dominik

Ahh, excellent Dominik,

Thank you - I’m looking through the source now :-)

Cheers,

Kevin


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] dnssec queries with --bogus-priv

[Kevin Darbyshire-Bryant]

Here’s another one of those innocent questions caused by looking at a logfile 
:-)

I have ‘—bogus-priv’ set so in theory I’m not going to ask upstream questions 
about RFC1918 addresses, which I don’t, except I see these….

dnssec-query[DS] 10.in-addr.arpa to 8.8.8.8
dnssec-query[DS] 168.192.in-addr.arpa to 8.8.8.8

You get the idea.

So, should I?


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] upstream server selection algorithm - bug?

[Kevin Darbyshire-Bryant]

This is one of my classic ‘look in a logfile…. h’ moments.

dnsmasq is configured with 4 upstream resolvers, google, both IPv4 & 6.  
Manpage states:

-o, --strict-order
By default, dnsmasq will send queries to any of the upstream servers it knows 
about and tries to favour servers that are known to be up. Setting this flag 
forces dnsmasq to try each query with each server strictly in the order they 
appear in /etc/resolv.conf
--all-servers
By default, when dnsmasq has more than one upstream server available, it will 
send queries to just one server. Setting this flag forces dnsmasq to send all 
queries to all available servers. The reply from the server which answers first 
will be returned to the original requester.

I have neither of these flags set, so I’d expect dnsmasq to choose one of the 
servers, hopefully the fastest and stick with that. Obviously it has to at 
least try the others occasionally to check it’s made the correct choice.   But 
I’m seeing dnsmasq make the same request to *ALL* servers quite frequently and 
am curious as to why?


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ubus and metrics

[Kevin Darbyshire-Bryant]

> On 24 Apr 2018, at 04:52, Kurt H Maier  wrote:
> 
> On Tue, Apr 24, 2018 at 12:07:09AM +0100, Simon Kelley wrote:
>> 
>> I edit using emacs, and never see a problem. A massive edit would
>> generate a huge number of spurious changes in the git repository. I use
>> "git blame" quite often and don't want to find that it tells me half the
>> lines were last changed in the great re-tab.
> 
> git blame has a flag to ignore whitespace-only changes.

h!  I didn’t know that.

‘-w’ option to save anyone else digging through the manpage :-)

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Makefile: Stop creating '-d' directory

[Kevin Darbyshire-Bryant]

install-common section was creating superfluous '-d' directory in build
location.

Split the directory creation into individual install commands to cope
with cross platform differences of interpreting subsequent '-d'
arguments.  e.g. GNU appears to be fine.  Apple creates the stray
directory.

Signed-off-by: Kevin Darbyshire-Bryant <l...@darbyshire-bryant.me.uk>
---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 98ec760..da82868 100644
--- a/Makefile
+++ b/Makefile
@@ -100,7 +100,8 @@ clean : mostly_clean
 install : all install-common
 
 install-common :
-   $(INSTALL) -d $(DESTDIR)$(BINDIR) -d $(DESTDIR)$(MANDIR)/man8
+   $(INSTALL) -d $(DESTDIR)$(BINDIR)
+   $(INSTALL) -d $(DESTDIR)$(MANDIR)/man8
$(INSTALL) -m 644 $(MAN)/dnsmasq.8 $(DESTDIR)$(MANDIR)/man8 
$(INSTALL) -m 755 $(BUILDDIR)/dnsmasq $(DESTDIR)$(BINDIR)
 
-- 
2.15.1 (Apple Git-101)


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

Re: [Dnsmasq-discuss] Move 'dnssec time check enable' from SIGHUP to SIGUSR2

[Kevin Darbyshire-Bryant]

> On 15 Jan 2018, at 23:27, Simon Kelley  wrote:
> 
> 
>> 
>> Beyond “gaaahh why didn’t I think of SIGINT”….. excellent.  Understand 
>> the reasoning, agree, running chez Kevin and backport for LEDE master 
>> submitted.
>> 
> 
> and there's still SIGQUIT available!
> 
> Out of interest, how does the LEDE plumbing deal with a restart of
> dnsmasq _after_ ntp  has established lock?

There’s an ntp hotplug script that creates a ‘time is valid’ flag file 
(/var/state/dnsmasqsec - being in /var means actually in tmp hence ram).  If 
the file doesn’t exist already on stratum change then a) it gets created and b) 
SIGINTs dnsmasq.   dnsmasq startup changes too… if the file doesn’t exist then 
it gets started with ‘—no-dnssec-timestamp’ expecting to be SIGINT’d by the 
hotplug script.  If dnsmasq gets (re)-started and ntpd hotplug has created our 
‘time valid’ file, then dnsmasq is started *without* —no-dnssec-timestamp’.  
There’s a whole raft of logic related to whether or not we’re using dnssec and 
quite what ntp client is being used.

The SIGINT support was committed to LEDE/openwrt master (rather than CC, 1701 
or whatever) around 60 minutes ago.


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Move 'dnssec time check enable' from SIGHUP to SIGUSR2

[Kevin Darbyshire-Bryant]

> On 14 Jan 2018, at 22:12, Simon Kelley  wrote:
> 
> Right, I thought about this again, and concluded that whilst sharing the
> "now use the time" function with something other than "reload loads of
> stuff" is an improvement, it doesn't really get us that much farther to
> share with something else, since conflicts could still arise.

> Given that this is a meant to be a definitive solution, I judge it's
> worth taking the one-time backward compatibility hit, and have left out
> the ability to select which signal to use.
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=3c973ad92d317df736d5a8fde67baba6b102d91e
> 
> 
> Comments?

Beyond “gaaahh why didn’t I think of SIGINT”….. excellent.  Understand the 
reasoning, agree, running chez Kevin and backport for LEDE master submitted.

Thank you muchly.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Move 'dnssec time check enable' from SIGHUP to SIGUSR2

[Kevin Darbyshire-Bryant]

> 
> 
> Am I waiting on you or are you waiting on me (to produce some laughably awful 
> code that you’ll fix up anyway) :-)

And for the purposes of a jolly good laugh…..  :-)



0001-dnsmasq-user-select-dnssec-time-valid-signal.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Move 'dnssec time check enable' from SIGHUP to SIGUSR2

[Kevin Darbyshire-Bryant]

> On 3 Jan 2018, at 12:34, Simon Kelley  wrote:
> 
> Happy new year all.
> 
> 
> "Ideally dnsmasq would have some other IPC mechanism for indicating
> 'time is valid, go check dnssec timestamps'"
> 
> 
> I suspect I know that answer to this, but dnsmasq _does_ have another
> IPC mechanism, DBus. Could this be solved by providing a DBus method?

I don’t know the implications of dbus on lede - a dbus method sounds like a 
useful idea though if nothing else to avoid the overloading of SIGHUP… but not 
a priority for lede.
> 
> 
> Failing that, what's the problem with using the timestamp file
> mechanism? I would have thought that was ideal for LEDE, which has a
> writable persistent filesystem available.

Ahh, oh boy, long story. Openwrt/LEDE did use that mechanism a while back but 
there were several niggles: writing to flash, handling conditional copying of 
the timestamo file across system updates, lede being too clever and updating 
clock to ‘latest timestamp in /etc’ temporarily before using ntp to set to real 
time.  In the end a mechanism whereby ‘ntpd’ pokes ‘dnsmasq’ when it has set 
time was easier, simpler, more reliable….in most circumstances, but 
openwrt/lede it appears is getting more persistent in using SIGHUP for other 
things and conflicting with dnssec timestamps.
> 
> If we move to SIGUSR2, the backwards compatibility objection could
> addressed by making the signal to be used an argument to
> --dnssec-no-timecheck
> 
> --dnssec-no-timecheck=sigusr2

Now that I like :-)

Cheers,

Kevin


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Move 'dnssec time check enable' from SIGHUP to SIGUSR2

[Kevin Darbyshire-Bryant]

Hi Simon,

Happy New Year!

I suspect this patch is going to get quite a push back in the name of backwards 
compatibility, however the problem is real and getting worse on some platforms 
- from the patch submitted to the LEDE/Openwrt platform:

"Move 'check dnssec timestamp enable' from SIGHUP handler to SIGUSR2.

Dnsmasq uses SIGHUP to do too many things: 1) set dnssec time validation
enabled, 2) bump SOA zone serial, 3) clear dns cache, 4) reload hosts
files, 5) reload resolvers/servers files.  SIGUSR2 is used to
re-open/re-start the logfile.  Default LEDE does not use logfile
functionality.

Many subsystems within LEDE can send SIGHUP to dnsmasq: 1) ntpd hotplug
(to indicate time is valid for dnssec) 2) odhcpd (to indicate a
new/removed host - typically DHCPv6 leases) 3) procd on interface state
changes 4) procd on system config state changes, 5) service reload.

If dnssec time validation is enabled before the system clock has been
set to a sensible time, name resolution will fail.  Because name
resolution fails, ntpd is unable to resolve time server names to
addresses, so is unable to set time.  Classic chicken/egg.

Since commits 23bba9cb330cd298739a16e350b0029ed9429eef (service reload) &
4f02285d8b4a66359a8fa46f22a3efde391b5419 (system config)  make it more
likely a SIGHUP will be sent for events other than 'ntpd has set time'
it is more likely that an errant 'name resolution is failing for
everything' situation will be encountered.

Ideally dnsmasq would have some other IPC mechanism for indicating 'time
is valid, go check dnssec timestamps', but until that time
(implementation is left as an exercise for the interested/competent
reader/bikeshedder) the next best thing is to move functionality from
the overloaded SIGHUP signal to the under-utilised SIGUSR2.”

I do think that SIGHUP is overloaded, doing something sensible about it is 
challenging.  Thoughts?



0001-dnsmasq-use-SIGUSR2-for-dnssec-time-valid.patch
Description: Binary data



Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Remove NULL check for intname.

[Kevin Darbyshire-Bryant]

On 05/10/17 06:20, ros...@gmail.com wrote:

On Wed, 2017-10-04 at 20:43 -0700, Kurt H Maier wrote:

On Wed, Oct 04, 2017 at 07:23:22PM -0700, Rosen Penev wrote:
  
-  if (intname && strlen(intname) != 0)

+  if (!strlen(intname))
  ifindex = if_nametoindex(intname); /* index == 0 when not
binding to an interface */


How much testing have you done of these patches?



Compile time. Looks fine to me. To add to my commit message,
strlen(NULL) causes a segmentation fault, meaning intname cannot be
NULL.


Which is precisely why the 'intname' guard is there.  C evaluation order 
is left to right, if 'intname' is NULL then evaluation stops there 
strlen is never called with a NULL intname.


Kevin

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

Re: [Dnsmasq-discuss] pick authoritative server

[Kevin Darbyshire-Bryant]

On 25/09/17 00:24, Vic wrote:
> Hi, Can I select a domain filter or such:
> 
> I send all requests to 8.8.8.8 except for
> 
> mydomain1.org and mydomain2.org -- that goes to my local name servers.
> 
> Yes? How?

Yes.  Something like:

server=/mydomain1.org/ip.address.of.mydomain1.auth.server

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

[Dnsmasq-discuss] Thanks - Recent fixes

[Kevin Darbyshire-Bryant]

Hi Simon,

Thanks for the recent fixes for the SIGSEGV CVE 2017-13704 and followup

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=63437ffbb58837b214b4b92cb1c54bc5f3279928

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a3303e196e5d304ec955c4d63afb923ade66c6e8

I backported to LEDE and the screaming appears to have stopped, even 
with the provocation of dnseval and naugthy edns0 length settings - 
sensible replies all round :-)


Thank you Sir,


Kevin




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

Re: [Dnsmasq-discuss] reproducible segmentation fault - bisected!

[Kevin Darbyshire-Bryant]

On 28/08/17 17:27, Christian Kujau wrote:

On Mon, 28 Aug 2017, Christian Kujau wrote:

On Mon, 28 Aug 2017, Kevin Darbyshire-Bryant wrote:

My workaround is to only call memset if the difference between buffer begin
and buffer limit is bigger than the query length, thus it retains Simon's
intent of clearing memory most of the time but avoids the SIGSEGV trampling.


Thanks, with your patch dnsmasq doesn't crash anymore when receiving odd
EDNS packets from dnseval.


Here is a fix rather than my sticking plaster workaround.  My workaround 
patch would actually allow dnsmasq to generate invalid replies, this 
actually *fixes* the problem!


Cheers,

Kevin
>From 38af9b1ac3242a4128e88069c495024caa565f0e Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
Date: Tue, 29 Aug 2017 12:35:40 +0100
Subject: [PATCH] forward.c: fix CVE-2017-13704

Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset()
is called with header & limit pointing at the same address and thus
tries to clear memory from before the buffer begins.

answer_request() is called with an invalid edns packet size provided by
the client.  Ensure the udp_size provided by the client is bounded by
512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512
MUST be treated as equal to 512"

The client that exposed the problem provided a payload udp size of 0.

Signed-off-by: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
---
 src/forward.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/forward.c b/src/forward.c
index f22556a..62c5a5a 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -1408,6 +1408,8 @@ void receive_query(struct listener *listen, time_t now)
 	 defaults to 512 */
   if (udp_size > daemon->edns_pktsz)
 	udp_size = daemon->edns_pktsz;
+  if (udp_size < 512)
+	udp_size = 512; /* RFC 6891 6.2.3 */
 }
 
 #ifdef HAVE_AUTH
-- 
2.7.4

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

Re: [Dnsmasq-discuss] reproducible segmentation fault - bisected!

[Kevin Darbyshire-Bryant]

I've a *much* better fix for this.  Will submit once I've collected 
someone from the station!


Mad busy life,

Kevin

On 28/08/17 17:27, Christian Kujau wrote:

On Mon, 28 Aug 2017, Christian Kujau wrote:

On Mon, 28 Aug 2017, Kevin Darbyshire-Bryant wrote:

My workaround is to only call memset if the difference between buffer begin
and buffer limit is bigger than the query length, thus it retains Simon's
intent of clearing memory most of the time but avoids the SIGSEGV trampling.


Thanks, with your patch dnsmasq doesn't crash anymore when receiving odd
EDNS packets from dnseval.

And thanks for requesting the CVE - I thought about this too, as the bug
constitutes some kind of DoS issue, but since nobody else complained, I
suspected it to be some variation of PEBKAC on my part :)


Oh, I believe it was Juan Manuel requesting the CVE - thanks!

C.



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

Re: [Dnsmasq-discuss] reproducible segmentation fault - bisected!

[Kevin Darbyshire-Bryant]

On 27/08/17 08:18, Christian Kujau wrote:

OK, so I should have done this in the first place and used git bisect to
find out which commit in Dnsmasq introduced this behaviour:

  fa78573778cb23337f67f5d0c9de723169919047 is the first bad commit
  commit fa78573778cb23337f67f5d0c9de723169919047
  Author: Simon Kelley <si...@thekelleys.org.uk>
  Date:   Fri Jul 22 20:56:01 2016 +0100

 Zero packet buffers before building output, to reduce risk
 of information leakage.



Hi Christian,

Thanks for all your investigation and info so far.  I too can now crash 
dnsmasq at will :-)   So putting my novice C and even more novice gdb to 
work I've come up with what I feel is a slightly less invasive 
mitigation to the problemwhich in essence is 'we've been sent a 
query but not yet allocated any buffer to it/updated the header limit 
offset but we pass a non zero query length.  The result is we try to 
clear the memory before our buffer.


My workaround is to only call memset if the difference between buffer 
begin and buffer limit is bigger than the query length, thus it retains 
Simon's intent of clearing memory most of the time but avoids the 
SIGSEGV trampling.


This is to be regarded as a sticking plaster rather than real fix but 
that needs far greater minds than I to understand the code & intent :-)


Hope this helps someone.

Kevin


>From 340a26f915d8c3bb54c44f58d432cc7240631a74 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
Date: Mon, 28 Aug 2017 14:52:10 +0100
Subject: [PATCH] dnsmasq: rfc1035: mitigate CVE-2017-13704

Work around a problem where answer_request() attempts to clear from the
end of a request to end of request buffer but the end of the buffer is
at the same place as the start.

Originally this meant that memset() tried to clear data before the
buffer leading to segmentation violation.  Instead only clear to end of
buffer it is bigger than the request length.

Signed-off-by: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
---
 src/rfc1035.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/rfc1035.c b/src/rfc1035.c
index 26f5301..91a9641 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -1225,7 +1225,8 @@ size_t answer_request(struct dns_header *header, char *limit, size_t qlen,
 
   /* Clear buffer beyond request to avoid risk of
  information disclosure. */
-  memset(((char *)header) + qlen, 0, 
+  if ( (limit - ((char *)header)) > qlen )
+  memset(((char *)header) + qlen, 0,
 	 (limit - ((char *)header)) - qlen);
   
   if (ntohs(header->ancount) != 0 ||
-- 
2.7.4

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

Re: [Dnsmasq-discuss] reproducible segmentation fault

[Kevin Darbyshire-Bryant]

On 28/08/17 09:27, Juan Manuel Fernandez wrote:

Hi,

Last weeks we were fuzzing dnsmasq and found this crash 
(https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg11597.html 
) . 
We tried to reach Simon on Friday but we have not had any response from 
him. We asked mitre for a CVE id and were assigned CVE-2017-13704.


Be aware that it's a bank holiday Monday here in the UK which means it's 
popular time to go away for a week or so with family/friends.  This may 
explain the lack of response so far.


Good that a CVE is assigned.  Even better you've got some example 
packets that induce the issue  :-)


In our original mail to Simon we attached two packets as examples: one 
that crash the application, and another where the memset is set to a 
lenght of 0 (making it useless).


Regards,
Juan Manuel Fernandez
Tarlogic


Cheers,

Kevin

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

Re: [Dnsmasq-discuss] IPv6: Router with RA + static DHCPv6 from dnsmasq on separate host

[Kevin Darbyshire-Bryant]

On 18/08/17 19:54, David Kerr wrote:

Maddes,
   This looks very similar to a question I asked a few days ago... 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q3/011677.html 



dnsmasq DHCPv6 server only seems to be issuing leases on the ULA prefix 
and not on the GUA prefix when both types of addresses are configured on 
an interface.  If I remove the ULA from the network interface then 
leases are issued from the GUA range.


I am awaiting a reply to my question.


It might be worth adding 'log-dhcp' to your dnsmasq config files and get 
a bit more info as to what options dnsmasq is replying with on dhcpv6 
requests...if it's replying!


Also, a packet capture on the client machine/s provides the ultimate 
source of info on what is actually received.  Many times I've used 
'wireshark' and gone 'oh! - ooops!"


Cheers,

Kevin

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

Re: [Dnsmasq-discuss] [RFC] dns: add option to ban domains

[Kevin Darbyshire-Bryant]

On 08/08/17 09:23, wkitt...@gmail.com wrote:

On 08/08/2017 04:06 AM, Matteo Croce wrote:

2017-08-08 4:26 GMT+02:00  :

On 08/07/2017 06:02 PM, Matteo Croce wrote:


I propose adding an option to allow banning some domains.

add `--ban-hosts' which accepts a file name which contains a list of
domains to block, one per line.
Domains are blocked by simply returning NXDOMAIN.


is the following in dnsmasq.conf broken???

# block these domains with NXDOMAIN
server=/example.com/
server=/facebook.com/
server=/fbcdn.net/
server=/fbcdn.com/
server=/facebook.net/


Nope, but it's unpractical when the ban list is huge


impractical?


# wc -l /etc/banhosts
13090 /etc/banhosts

also, having it in a separate file will allow updating it without
messing with the configuration file



well, you asked for comments so i did... as for separate files, can't it 
be done in another file that is included in the main one? i can't 
remember if dnsmasq allows one to include additional files or not...


LEDE/Openwrt does exactly that.  The startup script conditionally 
includes a config file with a list of RFC6761 related domains to never 
forward  "--conf-file=$RFC6761FILE"  - The referenced file contains 
"server=/exclude/" type references.


So the functionality is already there, though not quite with perfect 
syntax in the sense that 'server=/ /' is repeated each line.


How is the 'ban-hosts' file updated?  Does it need a SIGHUP to dnsmasq 
(please not another thing hanging off SIGHUP)  Does it need a complete 
restart?


If 'ban-hosts' can be dynamically updated then I can see some value in 
it, until then it looks like it's a syntax nicety.  Perhaps there's some 
other feature we're all missing... is it faster for example?


Kevin





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

Re: [Dnsmasq-discuss] dnsmasqd crash

[Kevin Darbyshire-Bryant]

Probably best to reply to the list as well where there are much better 
experts than me.


On 19/06/17 22:39, Justin Jose wrote:

Hi Kevin,

Thank you for the response. Here are my answers for your questions.

Q. What version of dnsmasq?

[Ans] The dnsmasq version I am using is 2.55.


2.55 is some 7 years old, 2.77 being released 2 weeks or so ago and 2.78 
fixing a couple of oversights in that release due 'soon'.




Q. hostname_isequal is used in quite a few places and should never be
passed a null pointer, so in my opinion the fix is a sticking plaster
over the issue and has the potential result of leaving null pointers
hanging around for other functions to fall over anyway.  The root cause
should be found and squished.  Any idea which particular call to
hostname_isequal was involved?

[Ans:] When the crash happened, the call to hostname_isequal is occured from 
forward_query at round line number 500.
I am not sure the reason for the NULL arguments here.


The first step here has to be to update to a much more recent version of 
dnsmasq and see if the problem still occurs.  Is the error repeatable? 
If so, that would make testing a lot easier.


Cheers,

Kevin

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

Re: [Dnsmasq-discuss] dnsmasqd crash

[Kevin Darbyshire-Bryant]

On 19/06/17 01:02, Justin Jose wrote:

​​​Hi,


I got a couple of dnsmasqd crash and on investigating I found the crash 
is due to accessing a NULL pointer.


What version of dnsmasq?



I have a fix for this problem and attached with this mail.


Would you have any suggestion for this fix?


hostname_isequal is used in quite a few places and should never be 
passed a null pointer, so in my opinion the fix is a sticking plaster 
over the issue and has the potential result of leaving null pointers 
hanging around for other functions to fall over anyway.  The root cause 
should be found and squished.  Any idea which particular call to 
hostname_isequal was involved?


Cheers,

Kevin

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

Re: [Dnsmasq-discuss] [PATCH] fix dns failover when dns server returns REFUSED

[Kevin Darbyshire-Bryant]

This seems like an important fix to get in the next 'patch' release or 
whatever it's to be called, a bit like the pxe filename whoops :-)


Remarkably simple fix too...hopefully not too simple.

Cheers,

Kevin

On 14/06/17 14:46, Hans Dedecker wrote:

If a DNS server replies REFUSED for a given DNS query in strict order mode
no failover to the next DNS server is triggered as the logic in reply_query
excluded strict order mode by mistake.

Also checking for not strict order mode makes the failover logic related
to REFUSED death code as it also checks for forwardall being 0 which can
only be the case for strict order mode.

Fix this by checking for strict order mode now so the failover logic in
case REFUSED is replied is triggered in case forwardall is 0 for a given
forward record. In case all servers mode is configured the fail over logic
won't be triggered just as before.

Signed-off-by: Hans Dedecker 
Signed-off-by: Mi Feng 
---

Fixes dns failover issue reported in LEDE 
(https://bugs.lede-project.org/index.php?do=details_id=841)

  src/forward.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/forward.c b/src/forward.c
index 83f392d..0ce3612 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -790,7 +790,7 @@ void reply_query(int fd, int family, time_t now)
/* Note: if we send extra options in the EDNS0 header, we can't recreate
   the query from the reply. */
if (RCODE(header) == REFUSED &&
-  !option_bool(OPT_ORDER) &&
+  option_bool(OPT_ORDER) &&
forward->forwardall == 0 &&
!(forward->flags & FREC_HAS_EXTRADATA))
  /* for broken servers, attempt to send to another one. */



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

Re: [Dnsmasq-discuss] problem with loopback and 2.77test5

[Kevin Darbyshire-Bryant]

On 15/05/17 11:06, Bastian Bittorf wrote:

* Simon Kelley  [12.05.2017 08:33]:

Oops. "It compiles - ship it" bites back.

2.77rc3 fixes this, and we're currently eating the dog-food chez Kelley.


just to mention it, the loopback-thingy is working fine now on my side with rc3.
Thanks a lot!


Cheers Bastian,

To confirm, no obvious screaming in LEDEland with rc3, in fact the 'DS 
queries' fix has solved at least 2 reports of SIGSEGV.  That's good news 
I think.


Kevin

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

Re: [Dnsmasq-discuss] problem with loopback and 2.77test5

[Kevin Darbyshire-Bryant]

On 11/05/17 21:09, Simon Kelley wrote:

Oops. "It compiles - ship it" bites back.

2.77rc3 fixes this, and we're currently eating the dog-food chez Kelley.


Woof!


Currently building a LEDE release, assuming no obvious issue pops up, a 
pull request into LEDE master will follow...and then...the world :-)


Kevin

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

Re: [Dnsmasq-discuss] problem with loopback and 2.77test5

[Kevin Darbyshire-Bryant]

On 10/05/17 22:31, Simon Kelley wrote:

Just committed a patch which should make this work again without needing
--no-ping.

I've tagged it as 2.77rc2, so please could a LEDE package be built, and
this behaviour tested.


I tried rc2 and think there's a problem with DHCPv4 leasesie. It 
doesn't give them out any more.


It was a *very* quick test before I had to dash out of the door so not 
exactly thorough.


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

Re: [Dnsmasq-discuss] Intermittent SIGSEGV crash of dnsmasq-full

[Kevin Darbyshire-Bryant]

On 09/05/17 22:42, Simon Kelley wrote:

Never trust a git commit which happened in the early hours :)

Thanks for a second excellent bug report. This was much easier to find.


Sorry for keeping you up till the wee small hours with your bug hunting 
outfit on :-)


Guido does all the hard work with gdb, I just wave a flag, jump about 
and say 'lookie here!' :-)




I've committed the fix to git.

I'll deal with Petr's patch tomorrow and then tag 2.77rc2


Good stuff.  An rc2 I can get into LEDE for more bug hunting :-)



Cheers,

Simon.


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

Re: [Dnsmasq-discuss] Intermittent SIGSEGV crash of dnsmasq-full

[Kevin Darbyshire-Bryant]

On 09/05/17 01:39, Simon Kelley wrote:

That was a horrible one.

Fix committed, and an optimistic 2.77rc1 tag added.


Sadly a tad optimistic.  From the original reporter, and I can confirm 
'domain-needed' is the crash enabling option:


Sorry!

Looking forward to the final release following the rc2 :-)

Cheers,

Kevin




I saw the update from Simon Kelley (thank you!) on the Dnsmasq-discuss mailing 
list and built an updated LEDE dnsmasq-2.77rc1 package to test. (see required 
patch attached)


The prior minimal test-case passed, but the original production config 
file now creates a horrible SIGSEGV crash-loop (log attached):
Mon May  8 22:59:46 2017 kern.info kernel: [1738736.539480] 
do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from 

Mon May  8 22:59:46 2017 kern.info kernel: [1738736.548375] epc = 
0040e79b in dnsmasq[40+2d000]
Mon May  8 22:59:46 2017 kern.info kernel: [1738736.553564] ra  = 
0040e773 in dnsmasq[40+2d000]



Stack trace indicates something to do with logging:
(gdb) core-file dnsmasq.18906.11.1494309586.core
[New LWP 18906]
...
Core was generated by `dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c 
--no-daemon'.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0040e79b in search_servers (now=now@entry=1494309586,
addrpp=addrpp@entry=0x0, qtype=qtype@entry=32768, qdomain=,
type=type@entry=0x7fd02c74, domain=domain@entry=0x7fd02c78,
norebind=norebind@entry=0x0) at forward.c:222
222   log_query(logflags | flags | F_CONFIG | F_FORWARD, 
qdomain, *addrpp, NULL);

(gdb) bt
#0  0x0040e79b in search_servers (now=now@entry=1494309586,
addrpp=addrpp@entry=0x0, qtype=qtype@entry=32768, qdomain=,
type=type@entry=0x7fd02c74, domain=domain@entry=0x7fd02c78,
norebind=norebind@entry=0x0) at forward.c:222
#1  0x00410759 in reply_query (fd=, family=,
now=now@entry=1494309586) at forward.c:938
#2  0x004127dd in check_dns_listeners (now=now@entry=1494309586)
at dnsmasq.c:1560
#3  0x004047db in main (argc=, argv=)
at dnsmasq.c:1044
(gdb) print logflags
$1 = 32800
(gdb) print flags
$2 =
(gdb) print *qdomain
value has been optimized out
(gdb) print addrpp
$3 = (struct all_addr **) 0x0
(gdb)

This turns out to be easy to reproduce. Simply add domain-needed to the 
prior standalone config file.

Then trigger the crash from a client with:
$ nslookup -port=3 google.com 192.168.1.1
;; connection timed out; no servers could be reached

I attached all the relevant logs, configs and patches.


--

One or more files have been attached.

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details_id=766#comment2589

I really hope to get out a 2.77 release soon.


Cheers,

Simon.











On 08/05/17 13:30, Kevin Darbyshire-Bryant wrote:

Hi Simon,

Got a report in LEDE land about a SIGSEGV issue,  I'm able to replicate
easily as described.

Thoughts?

Cheers,

Kevin


 Forwarded Message 
Subject: [FS#766] Intermittent SIGSEGV crash of dnsmasq-full
Date: Mon, 08 May 2017 05:57:18 +
From: LEDE Bugs <lede-b...@lists.infradead.org>
Reply-To: lede-b...@lists.infradead.org
To: lede-b...@lists.infradead.org

The following task has a new comment added:

FS#766 - Intermittent SIGSEGV crash of dnsmasq-full User who did this -
guidosarducci (guidosarducci)

--
After a little more investigation, this is definitely a bug that also
exists in the latest lede/master which uses dnsmasq-2.77test5. It is
easily triggered via a common mozilla DNS query, and appears related to
using split DNS and DNSSEC.

A minimal, standalone dnsmasq.conf that is vulnerable:
listen-address=192.168.1.1
port=3
bind-interfaces
no-daemon
no-hosts
no-resolv
log-queries=extra
server=8.8.8.8
server=/cloudfront.net/50.22.147.234
dnssec
dnssec-check-unsigned
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D



Removing either of these config lines results in no SIGSEGV:
server=/cloudfront.net/50.22.147.234
dnssec-check-unsigned

The bug can be triggered from a DNS client simply (e.g.a blank Firefox
page!):
ubuntu$ nslookup -port=3 tiles-cloudfront.cdn.mozilla.net 192.168.1.1
;; Question section mismatch: got cloudfront.net/DS/IN
;; connection timed out; no servers could be reached


I also captured a dnsmasq core file from my router and ran it through gdb:
ubuntu$
./staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/bin/mips-openwrt-linux-gdb
-d
./build_dir/target-mips_24kc_musl-1.1.16/dnsmasq-full/dnsmasq-2.77test5/src/
-n
./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq
dnsmasq.757.11.1494218146.core
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later ...
Reading symbols from
./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq.

[Dnsmasq-discuss] Intermittent SIGSEGV crash of dnsmasq-full

[Kevin Darbyshire-Bryant]

Hi Simon,

Got a report in LEDE land about a SIGSEGV issue,  I'm able to replicate 
easily as described.


Thoughts?

Cheers,

Kevin


 Forwarded Message 
Subject: [FS#766] Intermittent SIGSEGV crash of dnsmasq-full
Date: Mon, 08 May 2017 05:57:18 +
From: LEDE Bugs 
Reply-To: lede-b...@lists.infradead.org
To: lede-b...@lists.infradead.org

The following task has a new comment added:

FS#766 - Intermittent SIGSEGV crash of dnsmasq-full User who did this - 
guidosarducci (guidosarducci)


--
After a little more investigation, this is definitely a bug that also 
exists in the latest lede/master which uses dnsmasq-2.77test5. It is 
easily triggered via a common mozilla DNS query, and appears related to 
using split DNS and DNSSEC.


A minimal, standalone dnsmasq.conf that is vulnerable:
listen-address=192.168.1.1
port=3
bind-interfaces
no-daemon
no-hosts
no-resolv
log-queries=extra
server=8.8.8.8
server=/cloudfront.net/50.22.147.234
dnssec
dnssec-check-unsigned
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D


Removing either of these config lines results in no SIGSEGV:
server=/cloudfront.net/50.22.147.234
dnssec-check-unsigned

The bug can be triggered from a DNS client simply (e.g.a blank Firefox 
page!):

ubuntu$ nslookup -port=3 tiles-cloudfront.cdn.mozilla.net 192.168.1.1
;; Question section mismatch: got cloudfront.net/DS/IN
;; connection timed out; no servers could be reached


I also captured a dnsmasq core file from my router and ran it through gdb:
ubuntu$ 
./staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/bin/mips-openwrt-linux-gdb 
-d 
./build_dir/target-mips_24kc_musl-1.1.16/dnsmasq-full/dnsmasq-2.77test5/src/ 
-n 
./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq 
dnsmasq.757.11.1494218146.core

GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later ...
Reading symbols from 
./staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/dnsmasq...done.

[New LWP 757]
...
Core was generated by `dnsmasq -C crash-dnsmasq.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  forward_query (udpfd=, udpaddr=udpaddr@entry=0x7fc1d930,
dst_addr=, dst_iface=dst_iface@entry=0,
header=header@entry=0x7c8010, plen=43, plen@entry=50,
now=now@entry=1494218146, forward=0x77cabd90, ad_reqd=ad_reqd@entry=0,
do_bit=do_bit@entry=0) at forward.c:281
281   if (forward->sentto->addr.sa.sa_family == AF_INET)
(gdb) bt
#0  forward_query (udpfd=, udpaddr=udpaddr@entry=0x7fc1d930,
dst_addr=, dst_iface=dst_iface@entry=0,
header=header@entry=0x7c8010, plen=43, plen@entry=50,
now=now@entry=1494218146, forward=0x77cabd90, ad_reqd=ad_reqd@entry=0,
do_bit=do_bit@entry=0) at forward.c:281
#1  0x00410275 in receive_query (listen=listen@entry=0x77cbffe0,
now=now@entry=1494218146) at forward.c:1443
#2  0x00412825 in check_dns_listeners (now=now@entry=1494218146)
at dnsmasq.c:1565
#3  0x004047db in main (argc=, argv=)
at dnsmasq.c:1044
(gdb)


The dnsmasq config file, log file, and client log are attached. I'm not 
sure I can go any further, so would appreciate the dnsmasq package 
maintainer taking a look and advising.


Thanks!
--


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

Re: [Dnsmasq-discuss] [PATCH] Nack requests for unknown leases.

[Kevin Darbyshire-Bryant]

On 28/04/17 22:20, Simon Kelley wrote:


That's the bug here, I think. I was worried that a client sending a
DHCPDISCOVER when it thinks it knows that address, might respond to ICMP
pings, but at least for ISC dhclient on Linux, that's not the case.

Patch is here, and was much more trouble than it should have been: the
code really didn't consider this case.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=5ce3e76fbf89e942e8c54ef3e3389facf0d9067a

It's still the case that addresses used by statically configured host on
a network should not be in the dhcp-range configured into that network's
DHCP server.


I've just subtly renumbered my own home network to make sure the above 
condition is true...those hosts manually statically configured are now 
out of the 'statically allocated' dhcp and true dynamic DHCP ranges :-) 
Not that I got bitten by this feature 'cos everyone seems to use 
192.168.0/1... and I don't :-)


Simon, is there any chance of a 'test5' bundling all the latest tweaks 
into a tarball?  It's much easier to get the LEDE guys to accept a test 
release tarball than it is loads of patchesand it means the code 
would get tested by a wider community.



Thanks,

Kevin

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

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

[Kevin Darbyshire-Bryant]

On 07/04/17 23:00, Simon Kelley wrote:

On 06/04/17 14:01, Pedro MG Palmeiro wrote:

Dnsmasq trunk replies are being ignored by some devices, in my case, two
epson printers (AL-M200).
Dnsmasq 2.76 works fine.

This could be related with
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;
=88a77a78ad27adc3ed87b7ee603643d26cb896ee


Has the 'could' been confirmed?  Otherwise the wrong problem is being fixed.



Please refer to
https://bugs.lede-project.org/index.php?do=details_id=673
for tcpdumps.



But RFC 6842 assures us that no clients are broken by this change :)

The options here, as I see it are

1) revert the change and don't support 6842
2) provide a way to disable the client-id reply for broken clients.
3) provide a flag to disable the client-id for all clients.
4) make the new behaviour optional, and provide a flag to enable it.
5) declare it No Our Problem and get the broken clients fixed.


For me: Option 2 - client specific fix for client specific bug.

Cheers,

Kevin

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

Re: [Dnsmasq-discuss] [PATCH] decrease the amount of individual sites listed in log

[Kevin Darbyshire-Bryant]

Oooh that's a useful tidy'upper!

Like it.

Kevin

On 07/02/17 18:03, Hannu Nyman wrote:

By default 30 first servers are listed individually to system log, and
then a count of the remaining items. With e.g. a NXDOMAIN based adblock
service, dnsmasq lists 30 unnecessary ad sites every time when dnsmasq
evaluates the list. But the actual nameservers in use are evaluated last
and are not displayed as they get included in the "remaining items" total.

Handle the "local addresses only" separately and list only a few of them.
Remove the "local addresses only" from the general count.

Signed-off-by: Hannu Nyman 


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

Re: [Dnsmasq-discuss] interface-name records vs localise-queries

[Kevin Darbyshire-Bryant]

Thank you Simon!

Much appreciated.

And your 2.77test1 tar along with the localise fix has just gone into 
LEDE master, things should get a bit more testing there :-)


Cheers,

Kevin

On 02/02/17 16:57, Simon Kelley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=d42d4706bbcce3
b5a40ad778a5a356a997db6b34


Have fun.


Cheers,

Simon.



On 01/02/17 13:41, Kevin Darbyshire-Bryant wrote:



On 17/01/17 04:05, Eric Luehrsen wrote:

Hi Kevin,

Reading the man page, I would expect the primary address is
returned (localized) and  it acts just like any /etc/hosts entry.
This would imply that this is a bug or oversight.

quote: -interface-name=,[/4|/6] Return a DNS
record associating the name with the __ primary address __ on the
given interface. This flag specifies an A or  record for the
given name in the __ same way as an /etc/hosts line __, except
that the address is not constant, but taken from the given
interface


(I don't use router DNS that specifically, so I failed to test
this detail before submitting to LEDE. )

Eric


Hi Eric,

Sorry for the the late reply - I've been distracted by many other
things.  Your recent lede/dnsmasq.init changes are absolutely
wonderful and really useful.  If it weren't for this 'featurette'
of localised queries not working, it would be perfect.

I wonder if Simon could be persuaded to look into this ready for
2.77?

:-)

Kevin





Kevin Darbyshire-Bryant Wed, 11 Jan 2017 10:24:34 -0800 Hello
All, Recently LEDE changed the way it allocates names to
interfaces, now using '-interface-name' rather than putting
names in /etc/hosts or similar. Unfortunately this new method
appears incompatible with 'localise-queries' in that all
interfaces/aliases are included in the reply to 'nslookup
hostname' and not in a 'preferred local interface' order. Is
this an oversight/feature/bug? Cheers, Kevin

___ 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


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYk2TiAAoJEBXN2mrhkTWierAQAJUTwrSa6uRmCWp2cNvxlxWO
lnkehQhnqq43TVH5kg4waao71nigM7K77PnBIDuujs1gpYE1cgXDNIHbIjaBe28L
zEYdhp/AKoEb9RAFdBApQFjPz6Io5PEKivtLDTDf/EKpN878GTy0LfumQGL7yvc/
TrvUX6XFGZVaqI3sih9p5tHchg64jrs9fsSv/wmUZCSeJmAUgM22Ovb38rQkJrmW
wWKsMfNFSxPuDmvkCzrKp6F+G+sXXoPpwEC41BhLRn60mrY5O6G0ytp8qVsCC6Ax
5a/7G/8hBX3bGvDHyHx3yRdXNqdDuyqSvjP1BIeunr+emwVoReNkrEowfY3EE9+b
7/dQtfbwJx3auL1oRW5IhwqcWFgQ2GtupZapkpJ9hN4uE5KtI0FGx2JWuh1GRWrR
OQ8mmvyWr00BVJI3TjPbmmkTwPjNGKydSwWNHXwkdUh1K9ZALyN6ezvxuJx4Ptit
2ZMtBqc6+PqHO3FL25fTjMETza4ubP/OwU+9LXdnlNc1/Lk0UDTEN5YwU/yx2bDc
RV2Hwu2d826EvatiW6SmTikLt2vL9ow+4yFdUJZPWg3X8A9pJe/aroymW09NUP1w
jlE3fwmdVPNoex3TgNwpwRUfJF/qKkZ68ETo+hT8+sRyLIJ04fs8VUvYOxGcPgK5
HFI7upWmBSHUdZTlpoOe
=lPRg
-END PGP SIGNATURE-

___
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] interface-name records vs localise-queries

[Kevin Darbyshire-Bryant]

On 17/01/17 04:05, Eric Luehrsen wrote:

Hi Kevin,

Reading the man page, I would expect the primary address is returned 
(localized) and  it acts just like any /etc/hosts entry. This would imply that 
this is a bug or oversight.

quote:
-interface-name=,[/4|/6]
Return a DNS record associating the name with the __ primary address __ on 
the given interface. This flag specifies an A or  record for the given name 
in the __ same way as an /etc/hosts line __, except that the address is not 
constant, but taken from the given interface


(I don't use router DNS that specifically, so I failed to test this detail 
before submitting to LEDE. )

Eric


Hi Eric,

Sorry for the the late reply - I've been distracted by many other 
things.  Your recent lede/dnsmasq.init changes are absolutely wonderful 
and really useful.  If it weren't for this 'featurette' of localised 
queries not working, it would be perfect.


I wonder if Simon could be persuaded to look into this ready for 2.77?

:-)

Kevin





Kevin Darbyshire-Bryant Wed, 11 Jan 2017 10:24:34 -0800
Hello All,
Recently LEDE changed the way it allocates names to interfaces,
now using '-interface-name' rather than putting names in /etc/hosts or similar.
Unfortunately this new method appears incompatible with 'localise-queries' in
that all interfaces/aliases are included in the reply to 'nslookup hostname' and
not in a 'preferred local interface' order.
Is this an oversight/feature/bug?
Cheers,
Kevin

___
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] IDN (internationalized domain name) support

[Kevin Darbyshire-Bryant]

On 31/01/17 16:57, Simon Kelley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's included in the Debian, (and therefore Ubuntu) packaging.

Of course the only difference it makes is to the interpretation of
domain names in /etc/hosts and friends and config files. - IDNs get
cached and forwarded by dnsmasq fine without the support being included.

OK, it also affects logging, I think. göögle.com  appears in the logs
göögle.com and not as xn--ggle-5qaa.com


Cheers,

Simon.



Knowing that LEDE's lack of compiling IDN support for dnsmasq prompted 
this question I started investigating how easy it would be to do.


It highlighted an issue with LEDE/Openwrt libidn package install script 
- fix PR here https://github.com/openwrt/packages/pull/3925


Another build option for LEDE's dnsmasq package is currently lurking in 
my LEDE repo - I've not done a PR on that yet as I'm unsure how 
LEDE/openwrt handles building a base package (dnsmasq) which references 
libs outside the base build (openwrt/packages) 
https://github.com/kdarbyshirebryant/lede-source/tree/dnsmasqidn


Kevin

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

[Dnsmasq-discuss] interface-name records vs localise-queries

[Kevin Darbyshire-Bryant]

Hello All,

Recently LEDE changed the way it allocates names to interfaces, now 
using '-interface-name' rather than putting names in /etc/hosts or similar.


Unfortunately this new method appears incompatible with 
'localise-queries' in that all interfaces/aliases are included in the 
reply to 'nslookup hostname' and not in a 'preferred local interface' order.


Is this an oversight/feature/bug?

Cheers,

Kevin

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

Re: [Dnsmasq-discuss] DHCPv6 ULA & Global address allocation & Apple devices

[Kevin Darbyshire-Bryant]

On 21/11/16 15:52, Kevin Darbyshire-Bryant wrote:



PS: As a total hack, I got dnsmasq to ignore any requested addresses.
Dnsmasq replies with both ULA & Global addresses in the reply...and my
iPad is happy...it takes the global address.




Nope, the above worked temporarily by luck rather than judgement.

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

Re: [Dnsmasq-discuss] DHCPv6 ULA & Global address allocation & Apple devices

[Kevin Darbyshire-Bryant]

I've got some packet captures now that have helped answer some of the 
questions.


1) The DHCPADVERTISE in the log are included in just one packet.

2) The solicits from my ipad and the advertises are identical except 
dnsmasq presents the ULA address first whereas odhcpd presents the 
global address first.  Both ULA & global are included, just the order 
gets swapped.


3) The ipad requests the IPv6 address presented first in the solicit. 
So for odhcpd it requests global, whereas for dnsmasq it requests ULA.


4) dnsmasq replies with and only with the requested address (ULA) in 
this case.   odhcpd replies with both global and ULA addresses.



A few questions result:

1) Should dnsmasq reply with all available dhcpv6 ranges even if one 
specific address only is requested, like odhcpd?


2) Should dnsmasq re-order its replies in the solicits to present global 
first?


3) Is Apple wrong?


Help! :-)


Kevin


PS: As a total hack, I got dnsmasq to ignore any requested addresses. 
Dnsmasq replies with both ULA & Global addresses in the reply...and my 
iPad is happy...it takes the global address.





--- a/src/rfc3315.c
+++ b/src/rfc3315.c
@@ -867,13 +867,10 @@ static int dhcp6_no_relay(struct state *
 if (!check_ia(state, opt, _end, _option))
   continue;

-if (!ia_option)
-  {
 /* If we get a request with a IA_*A without addresses, 
treat it exactly like

a SOLICT with rapid commit set. */
 save_counter(start);
 goto request_no_address;
-  }

o = build_ia(state, );




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

[Dnsmasq-discuss] DHCPv6 ULA & Global address allocation & Apple devices

[Kevin Darbyshire-Bryant]

Hi All,

This problem has been around a while (forever?) but it's only just 
annoyed me sufficiently to investigate.


The box in question is running a recent version LEDE and in my case 
dnsmasq git head bleeding edge.  LEDE normally uses its homegrown odhcpd 
to hand out DHCPv6 addresses, whereas I choose to disable this and use 
dnsmasq.  I use DHCPv6 stateful to hand out addresses, no SLAAC.


The problem is that some devices (Apple) only obtain a ULA based address 
allocation when using dnsmasq.  Using odhcpd they obtain both a ULA and 
global address.


I've previously worked around this simply by removing the ULA prefix 
from the LAN interface but the question remainswhy does this and 
should this happen?  Who is wrong?  dnsmasq or odhcpd?


dnsmasq:

Mon Nov 21 10:25:49 2016 daemon.info dnsmasq-dhcp[27664]: 
DHCPSOLICIT(br-lan) 00:01:00:01:18:c6:20:23:ac:3c:0b:0c:e7:fd
Mon Nov 21 10:25:49 2016 daemon.info dnsmasq-dhcp[27664]: 
DHCPADVERTISE(br-lan) fdb5:c64a:3cd0:2b::4ff0:198e 
00:01:00:01:18:c6:20:23:ac:3c:0b:0c:e7:fd
Mon Nov 21 10:25:49 2016 daemon.info dnsmasq-dhcp[27664]: 
DHCPADVERTISE(br-lan) 2a02:c7f:1220:bf2b::4ff0:198e 
00:01:00:01:18:c6:20:23:ac:3c:0b:0c:e7:fd
Mon Nov 21 10:25:49 2016 daemon.info dnsmasq-dhcp[27664]: 
DHCPREQUEST(br-lan) 00:01:00:01:18:c6:20:23:ac:3c:0b:0c:e7:fd
Mon Nov 21 10:25:49 2016 daemon.info dnsmasq-dhcp[27664]: 
DHCPREPLY(br-lan) fdb5:c64a:3cd0:2b::4ff0:198e 
00:01:00:01:18:c6:20:23:ac:3c:0b:0c:e7:fd



Curiously, the solicit gets responded to by two advertises, one ULA, one 
global.  The follow up dhcprequest only gets the single (ULA) response.



odhcpd:

Mon Nov 21 10:27:48 2016 daemon.warn odhcpd[1426]: DHCPV6 SOLICIT IA_NA 
from 0001000118c62023ac3c0b0ce7fd on br-lan: ok 
2a02:c7f:1220:bf2b::85e/128 fdb5:c64a:3cd0:2b::85e/128


Clearly the logging is very different and ideally I should grab a packet 
dump (being worked on!) to see how this is handled at the packet level 
(e.g. does dnsmasq send two reply packets vs odhcpd sends one but with 
two answers as hinted by the logs)


Insight and assistance appreciated :-)

Kevin

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

Re: [Dnsmasq-discuss] DNSSEC check unsigned vs sharepoint.com

[Kevin Darbyshire-Bryant]

Thank you one & all for that.

I've tried to explain it to Microsoftandgiven up.

I just won't use 'Onedrive for Business' or 'sharepoint'.


On 09/09/2016 21:09, Simon Kelley wrote:
> On 09/09/16 19:35, /dev/rob0 wrote:
>> On Fri, Sep 09, 2016 at 03:24:34PM +0100, Kevin Darbyshire-Bryant wrote:
>>> Having some issues with my 'onedrive for business' application 
>>> which in turn uses 'sharepoint.com'.  Short version: dnsmasq 2.76 
>>> thinks sharepoint.com is bogus.  Directly querying upstream servers 
>>> is okay:
>>>
>>> # drill -D @8.8.8.8 sharepoint.com
>>> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45014
>>> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
>>> ;; QUESTION SECTION:
>>> ;; sharepoint.com.  IN  A
>>>
>>> ;; ANSWER SECTION:
>>> sharepoint.com. 20224   IN  CNAME   sharepoint.microsoft.com.
>>
>> This is broken.
>>
>>> sharepoint.microsoft.com.   3346IN  A   64.4.6.100
>>> sharepoint.microsoft.com.   3346IN  A   65.55.39.10
>> snip
>>
>>> If I disable 'check unsigned' on the router's dnsmasq instance 
>>> things work ok.
>>>
>>> Why does dnsmasq think bogus, but google think ok?
>>
>> $ dig sharepoint.com. any @f.gtld-servers.net. +norec +dnssec
>>
>> ; <<>> DiG 9.10.3 <<>> sharepoint.com. any @f.gtld-servers.net. +norec 
>> +dnssec
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23615
>> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ;; QUESTION SECTION:
>> ;sharepoint.com.IN  ANY
>>
>> ;; AUTHORITY SECTION:
>> sharepoint.com. 172800  IN  NS  ns1.bdm.microsoftonline.com.
>> sharepoint.com. 172800  IN  NS  ns2.bdm.microsoftonline.com.
>> sharepoint.com. 172800  IN  NS  ns3.bdm.microsoftonline.com.
>> sharepoint.com. 172800  IN  NS  ns4.bdm.microsoftonline.com.
>> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - 
>> CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
>> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 
>> 20160915044336 2016090806 27452 com. 
>> xNERKmnAlkb3XiEf76OahP52D10WKZLu7GcWpYhVT4be0SBbmq9Kn+XV 
>> AnaMG/Ywu1/4VPyMfDxnw+XJLMXLn3NJN7TbNLA9Z0TqcpbRZcnTq1Na 
>> cO9/iuAx32Oaf5pbJIwuSS7HAhfDY4tahpYuSYDz8xOQzyf5W6wnjWAL sAc=
>> 3HGLO8KLU2RJ9G8IIOE1U9FPP77E8J3F.com. 86400 IN NSEC3 1 1 0 - 
>> 3HGMM5Q6EQANHO53VDJUCIMH8GVFL0BU NS DS RRSIG
>> 3HGLO8KLU2RJ9G8IIOE1U9FPP77E8J3F.com. 86400 IN RRSIG NSEC3 8 2 86400 
>> 20160915042007 20160908031007 27452 com. 
>> sVonxyL0/UgM+9KOG56hO1KezbbM8nzXaEDQYkfJISKVXy+P4m3vF1CX 
>> pO54bvTDo+msHBjNfNnjZ/4W7NnCutFTs0MNGXYZHOmXJE0B58KXW3Ui 
>> xsS8lzMlvGKvRuqwe3sHVi1K7TVz2BS96oxljuQ2LXpB+m0MX3eyMt5l zO8=
>> ...
>>
>> Microsoft has a broken implementation here.  They have put a CNAME 
>> where NS already exists.  Some resolvers are fooled and will go along 
>> with it, but apparently dnsmasq can't do that while checking DNSSEC.
>>
>> If you are paying them, complain.
>>
> 
> Agreed.
> 
> What actually trips dnsmasq is this.
> 
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @8.8.8.8 +dnssec ds sharepoint.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26376
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;sharepoint.com.  IN  DS
> 
> ;; ANSWER SECTION:
> sharepoint.com.   7513IN  CNAME   
> sharepoint.microsoft.com.
> 
> ;; AUTHORITY SECTION:
> microsoft.com.547 IN  SOA ns1.msft.net. 
> msnhst.microsoft.com.
> 2016090906 7200 600 2419200 3600
> 
> ;; Query time: 60 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Fri Sep 09 20:59:46 BST 2016
> ;; MSG SIZE  rcvd: 133
> 
> The CNAME record overwrites the proof of non-existence of the DS record
> of sharepoint.com, so there's no way to prove that lack of signature of
> the A-record is OK. This is a direct result of the CNAME at the root of
> the sharepoint.com domain.
> 
> The google recursive servers can sort this out, because th

Re: [Dnsmasq-discuss] Hiding/obscuring version.bind

[Kevin Darbyshire-Bryant]

Hmm.  Ideally then with 'NO_ID' we shouldn't forward Chaosnet queries 
for *.bind.
Can we just get away with the equivalent of 'local=/bind/' or is that 
too broad a brush to apply by default in the code?


I can see me digging into how the code for 'local' works in my near 
future :-)


On 09/09/16 20:56, Simon Kelley wrote:

Applied.

Something to think about: with this in effect, queries to *.bind get
treated like all others, ie they get forwarded upstream, so the
requestor may get an answer from an upstream nameserver. I've added a
comment to this effect to the definition of NO_ID.

Cheers,

Simon.





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

[Dnsmasq-discuss] DNSSEC check unsigned vs sharepoint.com

[Kevin Darbyshire-Bryant]

Hi All,

Having some issues with my 'onedrive for business' application which in
turn uses 'sharepoint.com'.  Short version: dnsmasq 2.76 thinks
sharepoint.com is bogus.  Directly querying upstream servers is okay:

# drill -D @8.8.8.8 sharepoint.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45014
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; sharepoint.com.  IN  A

;; ANSWER SECTION:
sharepoint.com. 20224   IN  CNAME   sharepoint.microsoft.com.
sharepoint.microsoft.com.   3346IN  A   64.4.6.100
sharepoint.microsoft.com.   3346IN  A   65.55.39.10

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 17 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 8.8.8.8
;; WHEN: Fri Sep  9 15:14:12 2016
;; MSG SIZE  rcvd: 110

If I disable 'check unsigned' on the router's dnsmasq instance things
work ok.

Why does dnsmasq think bogus, but google think ok?

Kevin

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

Re: [Dnsmasq-discuss] Hiding/obscuring version.bind

[Kevin Darbyshire-Bryant]

Attached (in case the git send-email didn't work)

Kevin :-)

On 06/09/16 21:23, Simon Kelley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

a) I tend to agree that it's pointless.
b) Not a run-time option, there are too many of those already.
c) Maybe the simplest solution is something like a NO_ID compile time
option that suppresses the whole .bind domain thing?

Certainly happy to take the patch.


Cheers,

Simon.


On 06/09/16 16:14, Kevin Darbyshire-Bryant wrote:

Hi Simon & all,

There has been a bit of activity on the security front in LEDE and
a recent change proposed removing version numbers from software to
avoid it leaking to 'the bad guys'.  I'll say upfront that I'm not
a fan of this approach feeling that it's more of the 'security
through obscurity' route but minds cleverer than mine have thought
about this so from a LEDE point of view 'we're stuck with it'.

LEDE's approach is to simply change the VERSION file to 'UNKNOWN'
at build time.  I dislike this because it also removes any info
from the startup logs or even 'dnsmasq --version' and on the basis
that 'version number' is a somewhat basic requirement when
providing advice/support here.  A suggestion has been made to
introduce a compile time option that replaces 'version.bind' with
"dnsmasq-UNKNOWN', leaving all the usual version strings intact.
The suggestion was also made rather than having a LEDE specific
patch that 'upstream' dnsmasq might like this feature.

I'm willing to do what should be a simple patch for that behaviour
but is it a) a good idea?  b) should it be a run-time option
instead?  c) should we consider obscuring other info as well?

Cheers,

Kevin


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


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJXzyXYAAoJEBXN2mrhkTWiE90P/1KewRyDq9rcbrddiKQhP2WT
V364psZy9rWQPZbzJLXQ3QvD1CwQChynIzqzUywh2dT7dPSe/XSdTRXab+Fxy0gr
0aITJPNyxIv6i8402YP1JDT6eoAk4JQAdJChQi+UpBDHy6WXe7q4sJKWMIZYDV9/
9meqSZ6OAGtX8kYGA+gpFqPlI/1Y/LAucxInvtvB1ZMXSRk5nNeyEpy7OEsCTqr9
PBK6LRtnQU6Iq7emIWKz0FQZpNZ6xNubZD96OGHrWnfdpT3ONgDO1k0S8/v8S6gw
m1Rwexe0skVnNcGxL9lv5h8lC3w20iUi2OiuT5ebV+IuUkGXMcrW9yW/MKspsxcu
19Bo5VfvYCuNYlW0OCypON455iRf7cXBwzHOqgaVOYc/zBIdDAuBm+n2JAsw7suz
n7pRB8m3G8WPLs5ZKNIgZgasum81uIRD6XaKjOE9cGgO6XVD3u/2mcIQqbg/9QTf
FVlAttRw9T0N2ebKOgJuMX+/Z2OiK7NYP6kebmcdFNhp/xih3xLvpoS4OK9Wyr1q
7LCN5ebjmC/1tSNhhLSK+L/YUtkqFwGu5CL1IJRy6AQS98LxIOL3hRj2A5MRsgXb
fjYlNXqStlX1czPU7eK1zfSCGy6gUNThSvv8peJPtmdVC9IoVyUxCm4nGKzW7syO
vDAjvBAkXGbnbUkcVcfg
=MIfU
-END PGP SIGNATURE-

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


>From f6bea86c78ba9efbd01da3dd2fb18764ec806290 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
Date: Wed, 7 Sep 2016 09:35:07 +0100
Subject: [PATCH] dnsmasq: compile time option NO_ID

Some consider it good practice to obscure software version numbers to
clients.  Compiling with -DNO_ID removes the *.bind info structure.
This includes: version, author, copyright, cachesize, cache insertions,
evictions, misses & hits, auth & servers.

Signed-off-by: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
---
 src/cache.c   | 2 ++
 src/config.h  | 5 +
 src/dnsmasq.h | 4 
 src/option.c  | 8 ++--
 src/rfc1035.c | 3 ++-
 5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index 4ecd535..eca56c8 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1290,6 +1290,7 @@ void cache_add_dhcp_entry(char *host_name, int prot,
 }
 #endif
 
+#ifndef NO_ID
 int cache_make_stat(struct txt_record *t)
 { 
   static char *buff = NULL;
@@ -1385,6 +1386,7 @@ int cache_make_stat(struct txt_record *t)
   *buff = len;
   return 1;
 }
+#endif
 
 /* There can be names in the cache containing control chars, don't 
mess up logging or open security holes. */
diff --git a/src/config.h b/src/config.h
index 80a50e1..7ca7d7f 100644
--- a/src/config.h
+++ b/src/config.h
@@ -120,6 +120,8 @@ HAVE_LOOP
 HAVE_INOTIFY
use the Linux inotify facility to efficiently re-read configuration files.
 
+NO_ID
+   Don't report *.bind CHAOS info to clients.
 NO_IPV6
 NO_TFTP
 NO_DHCP
@@ -434,6 +436,9 @@ static char *compile_opts =
 "no-"
 #endif
 "DNSSEC "
+#ifdef NO_ID
+"no-ID "
+#endif
 #ifndef HAVE_LOOP
 "no-"
 #endif
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index f239ce5..4b55bb5 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -286,6 +286,7 @@ struct naptr {
   struct naptr *next;
 };
 
+#ifndef NO_ID
 #define TXT_STAT_CACHESIZE 1
 #define TXT_STAT_INSERTS   2
 #define TXT_STAT_EVICTIONS 3
@@ -293,6 +294,7 @@ struct naptr {
 #define TXT_STAT_HITS   

[Dnsmasq-discuss] [PATCH] dnsmasq: compile time option NO_ID

[Kevin Darbyshire-Bryant]

Some consider it good practice to obscure software version numbers to
clients.  Compiling with -DNO_ID removes the *.bind info structure.
This includes: version, author, copyright, cachesize, cache insertions,
evictions, misses & hits, auth & servers.

Signed-off-by: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
---
 src/cache.c   | 2 ++
 src/config.h  | 5 +
 src/dnsmasq.h | 4 
 src/option.c  | 8 ++--
 src/rfc1035.c | 3 ++-
 5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index 4ecd535..eca56c8 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1290,6 +1290,7 @@ void cache_add_dhcp_entry(char *host_name, int prot,
 }
 #endif
 
+#ifndef NO_ID
 int cache_make_stat(struct txt_record *t)
 { 
   static char *buff = NULL;
@@ -1385,6 +1386,7 @@ int cache_make_stat(struct txt_record *t)
   *buff = len;
   return 1;
 }
+#endif
 
 /* There can be names in the cache containing control chars, don't 
mess up logging or open security holes. */
diff --git a/src/config.h b/src/config.h
index 80a50e1..7ca7d7f 100644
--- a/src/config.h
+++ b/src/config.h
@@ -120,6 +120,8 @@ HAVE_LOOP
 HAVE_INOTIFY
use the Linux inotify facility to efficiently re-read configuration files.
 
+NO_ID
+   Don't report *.bind CHAOS info to clients.
 NO_IPV6
 NO_TFTP
 NO_DHCP
@@ -434,6 +436,9 @@ static char *compile_opts =
 "no-"
 #endif
 "DNSSEC "
+#ifdef NO_ID
+"no-ID "
+#endif
 #ifndef HAVE_LOOP
 "no-"
 #endif
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index f239ce5..4b55bb5 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -286,6 +286,7 @@ struct naptr {
   struct naptr *next;
 };
 
+#ifndef NO_ID
 #define TXT_STAT_CACHESIZE 1
 #define TXT_STAT_INSERTS   2
 #define TXT_STAT_EVICTIONS 3
@@ -293,6 +294,7 @@ struct naptr {
 #define TXT_STAT_HITS  5
 #define TXT_STAT_AUTH  6
 #define TXT_STAT_SERVERS   7
+#endif
 
 struct txt_record {
   char *name;
@@ -1081,7 +1083,9 @@ void cache_add_dhcp_entry(char *host_name, int prot, 
struct all_addr *host_addre
 struct in_addr a_record_from_hosts(char *name, time_t now);
 void cache_unhash_dhcp(void);
 void dump_cache(time_t now);
+#ifndef NO_ID
 int cache_make_stat(struct txt_record *t);
+#endif
 char *cache_get_name(struct crec *crecp);
 char *cache_get_cname_target(struct crec *crecp);
 struct crec *cache_enumerate(int init);
diff --git a/src/option.c b/src/option.c
index d811ed3..d0d9509 100644
--- a/src/option.c
+++ b/src/option.c
@@ -657,7 +657,8 @@ static int atoi_check8(char *a, int *res)
   return 1;
 }
 #endif
-   
+
+#ifndef NO_ID
 static void add_txt(char *name, char *txt, int stat)
 {
   struct txt_record *r = opt_malloc(sizeof(struct txt_record));
@@ -670,13 +671,14 @@ static void add_txt(char *name, char *txt, int stat)
   *(r->txt) = len;
   memcpy((r->txt)+1, txt, len);
 }
-  
+
   r->stat = stat;
   r->name = opt_string_alloc(name);
   r->next = daemon->txt;
   daemon->txt = r;
   r->class = C_CHAOS;
 }
+#endif
 
 static void do_usage(void)
 {
@@ -4532,6 +4534,7 @@ void read_opts(int argc, char **argv, char *compile_opts)
   daemon->soa_expiry = SOA_EXPIRY;
   daemon->max_port = MAX_PORT;
 
+#ifndef NO_ID
   add_txt("version.bind", "dnsmasq-" VERSION, 0 );
   add_txt("authors.bind", "Simon Kelley", 0);
   add_txt("copyright.bind", COPYRIGHT, 0);
@@ -4544,6 +4547,7 @@ void read_opts(int argc, char **argv, char *compile_opts)
   add_txt("auth.bind", NULL, TXT_STAT_AUTH);
 #endif
   add_txt("servers.bind", NULL, TXT_STAT_SERVERS);
+#endif
 
   while (1) 
 {
diff --git a/src/rfc1035.c b/src/rfc1035.c
index 9e730a9..fbcb564 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -1269,6 +1269,7 @@ size_t answer_request(struct dns_header *header, char 
*limit, size_t qlen,
  unsigned long ttl = daemon->local_ttl;
  int ok = 1;
  log_query(F_CONFIG | F_RRNAME, name, NULL, "");
+#ifndef NO_ID
  /* Dynamically generate stat record */
  if (t->stat != 0)
{
@@ -1276,7 +1277,7 @@ size_t answer_request(struct dns_header *header, char 
*limit, size_t qlen,
  if (!cache_make_stat(t))
ok = 0;
}
- 
+#endif
  if (ok && add_resource_record(header, limit, , 
nameoffset, , 
ttl, NULL,
T_TXT, t->class, "t", 
t->len, t->txt))
-- 
2.7.4


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

[Dnsmasq-discuss] Hiding/obscuring version.bind

[Kevin Darbyshire-Bryant]

Hi Simon & all,

There has been a bit of activity on the security front in LEDE and a 
recent change proposed removing version numbers from software to avoid 
it leaking to 'the bad guys'.  I'll say upfront that I'm not a fan of 
this approach feeling that it's more of the 'security through obscurity' 
route but minds cleverer than mine have thought about this so from a 
LEDE point of view 'we're stuck with it'.


LEDE's approach is to simply change the VERSION file to 'UNKNOWN' at 
build time.  I dislike this because it also removes any info from the 
startup logs or even 'dnsmasq --version' and on the basis that 'version 
number' is a somewhat basic requirement when providing advice/support 
here.  A suggestion has been made to introduce a compile time option 
that replaces 'version.bind' with "dnsmasq-UNKNOWN', leaving all the 
usual version strings intact. The suggestion was also made rather than 
having a LEDE specific patch that 'upstream' dnsmasq might like this 
feature.


I'm willing to do what should be a simple patch for that behaviour but 
is it a) a good idea?  b) should it be a run-time option instead?  c) 
should we consider obscuring other info as well?


Cheers,

Kevin


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

Re: [Dnsmasq-discuss] Dnsmasq doesn't reply to queries made over (link-local) IPv6

[Kevin Darbyshire-Bryant]

On 04/09/16 12:14, Toke Høiland-Jørgensen wrote:

Simon Kelley  writes:


OK, naive attempts to reproduce this have failed entirely, it just works
for me :-)


I see something similar:

recvmsg(10, {msg_name={sa_family=AF_INET6, sin6_port=htons(50214), inet_pton(AF_INET6, 
"fe80::c23f:d5ff:fe62:22ac", _addr), sin6_flowinfo=htonl(0), 
sin6_scope_id=if_nametoindex("eth1.1")}, msg_namelen=28, 
msg_iov=[{iov_base="\243\307\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", iov_len=4096}], msg_iovlen=1, 
msg_control=[{cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=0x32}], msg_controllen=32, msg_flags=0}, 0) = 28
dnsmasq: query[A] google.com from fe80::c23f:d5ff:fe62:22ac



So I've LEDE r1504 (+8 special sauce local tweaks) + bleeding edge 
dnsmasq commit 16800ea072dd0cdf14d951c4bb8d2808b3dfe53d on an Archer C7 
router.  Using linux mint 18 client: kevin@Animal ~/git/github/lede 
(exp) $ dig -6 @fe80::62e3:27ff:feaf:9e50%wlan0 google.com 


; <<>> DiG 9.10.3-P4-Ubuntu <<>> -6 @fe80::62e3:27ff:feaf:9e50%wlan0 
google.com 

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54808
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.IN

;; ANSWER SECTION:
google.com.33IN 2a00:1450:4009:80a::200e

;; Query time: 10 msec
;; SERVER: fe80::62e3:27ff:feaf:9e50%3#53(fe80::62e3:27ff:feaf:9e50%3)
;; WHEN: Sun Sep 04 16:01:01 BST 2016
;; MSG SIZE  rcvd: 67


strace running on the router:

clock_gettime(CLOCK_REALTIME, {1473001369, 678036759}) = 0
recvmsg(10, {msg_name={sa_family=AF_INET6, sin6_port=htons(43191), 
inet_pton(AF_INET6, "fe80::2677:3ff:fe47:8fec", _addr), 
sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("br-lan")}, 
msg_namelen=28, msg_iov=[{iov_base="\356;\1 
\0\1\0\0\0\0\0\1\6google\3com\0\0\34\0\1\0\0)\20"..., iov_len=4096}], 
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_IPV6, 
cmsg_type=0x32}], msg_controllen=32, msg_flags=0}, 0) = 39

ioctl(10, SIOCGIFNAME, {ifr_index=17, ifr_name="br-lan"}) = 0
sendmsg(10, {msg_name={sa_family=AF_INET6, sin6_port=htons(43191), 
inet_pton(AF_INET6, "fe80::2677:3ff:fe47:8fec", _addr), 
sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("br-lan")}, 
msg_namelen=28, 
msg_iov=[{iov_base="\356;\201\200\0\1\0\1\0\0\0\1\6google\3com\0\0\34\0\1\300\f\0\34"..., 
iov_len=67}], msg_iovlen=1, msg_control=[{cmsg_len=32, 
cmsg_level=SOL_IPV6, cmsg_type=0x32}], msg_controllen=32, msg_flags=0}, 
0) = 67
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, 
events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, 
events=POLLIN}, {fd=13, events=POLLIN}], 10, -1


I can confirm client box has linklocal inet6 addr: 
fe80::2677:3ff:fe47:8fec/64 Scope:Link.  I think it 'just works' for me too.


However I'm sure recently I saw some discussion on ipv6 link local 
'unresponsive' type issues in the lede chat room.   Maybe worth asking 
in there.


Kevin


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

Re: [Dnsmasq-discuss] dnsmasq does crash

[Kevin Darbyshire-Bryant]

On 30/08/16 23:08, Simon Kelley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sorry about this. Putative fix pushed to git.


Cheers,

Simon.



Looks good.  It doesn't go bang anymore on my system :-)

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

Re: [Dnsmasq-discuss] dnsmasq does crash

[Kevin Darbyshire-Bryant]

On 29/08/16 20:30, e9hack wrote:

Hi,

I've trouble with this commit, independently that it looks simple:

Suppress useless warning about DHCP packets of interfaces without addresses.

Starting with this commit, dnsmasq does crash shortly after start:

Mon Aug 29 21:18:40 2016 kern.info kernel: [17587.489903]
Mon Aug 29 21:18:40 2016 kern.info kernel: [17587.489903] do_page_fault(): 
sending SIGSEGV
to dnsmasq for invalid write access to 0038
Mon Aug 29 21:18:40 2016 kern.info kernel: [17587.498607] epc = 00411eff in
dnsmasq[40+2d000]
Mon Aug 29 21:18:40 2016 kern.info kernel: [17587.503589] ra  = 00411ec7 in
dnsmasq[40+2d000]
Mon Aug 29 21:18:40 2016 kern.info kernel: [17587.508587]

Regards,
Hartmut
Get an identical error, didn't get as far as narrowing it to a specific 
commit.  Openwrt/LEDE has 'long' carried a (more complicated) patch to 
suppress the message, attached for reference.


Kevin

--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -147,7 +147,7 @@ void dhcp_packet(time_t now, int pxe_fd)
   ssize_t sz; 
   int iface_index = 0, unicast_dest = 0, is_inform = 0;
   int rcvd_iface_index;
-  struct in_addr iface_addr;
+  struct in_addr iface_addr, *addrp = NULL;
   struct iface_param parm;
 #ifdef HAVE_LINUX_NETWORK
   struct arpreq arp_req;
@@ -277,11 +277,9 @@ void dhcp_packet(time_t now, int pxe_fd)
 {
   ifr.ifr_addr.sa_family = AF_INET;
   if (ioctl(daemon->dhcpfd, SIOCGIFADDR, ) != -1 )
-	iface_addr = ((struct sockaddr_in *) _addr)->sin_addr;
-  else
 	{
-	  my_syslog(MS_DHCP | LOG_WARNING, _("DHCP packet received on %s which has no address"), ifr.ifr_name);
-	  return;
+	  addrp = _addr;
+	  iface_addr = ((struct sockaddr_in *) _addr)->sin_addr;
 	}
   
   for (tmp = daemon->dhcp_except; tmp; tmp = tmp->next)
@@ -300,7 +298,7 @@ void dhcp_packet(time_t now, int pxe_fd)
   parm.relay_local.s_addr = 0;
   parm.ind = iface_index;
   
-  if (!iface_check(AF_INET, (struct all_addr *)_addr, ifr.ifr_name, NULL))
+  if (!iface_check(AF_INET, (struct all_addr *)addrp, ifr.ifr_name, NULL))
 	{
 	  /* If we failed to match the primary address of the interface, see if we've got a --listen-address
 	 for a secondary */
@@ -320,6 +318,12 @@ void dhcp_packet(time_t now, int pxe_fd)
 	  complete_context(match.addr, iface_index, NULL, match.netmask, match.broadcast, );
 	}
   
+  if (!addrp)
+{
+  my_syslog(MS_DHCP | LOG_WARNING, _("DHCP packet received on %s which has no address"), ifr.ifr_name);
+  return;
+}
+
   if (!iface_enumerate(AF_INET, , complete_context))
 	return;
 
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Compile Error.

[Kevin Darbyshire-Bryant]

Or use 'make COPTS=-DNO_INOTIFY' to compile without the inotify 
handling, since early kernels (as used by many router manufacturers) 
don't have inotify support.



On 24/08/16 17:14, Chris Novakovic wrote:

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



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

Re: [Dnsmasq-discuss] Clarify/Improve DNSSEC related SIGHUP handling

[Kevin Darbyshire-Bryant]

On 11/07/16 21:05, Simon Kelley wrote:

Ah yes, I see the problem. Patch applied. Sorry it took so long :-(

Cheers,

Simon.


No problem.  Glad to have helped solve it :-)

Cheers,

Kevin

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

[Dnsmasq-discuss] Clarify/Improve DNSSEC related SIGHUP handling

[Kevin Darbyshire-Bryant]

Hi Simon,

Please could you consider the attached patch.  It solves a problem that
using dnssec-timestamp also effectively enabled dnssec-no-timecheck.
The result of which is that an unfortunately timed SIGHUP could
accidentally enable dnssec timestamp checking.  In combination with
dnssec-check-unsigned that could prove 'challenging' :-)

The patch matches the behaviour as is documented in the manpage.

kind regards,

Kevin



>From f94c6d70aaaea0511ef3c7667093b4b54952804e Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
Date: Fri, 27 May 2016 10:23:47 +0100
Subject: [PATCH] Improve dnssec SIGHUP behaviour

Signed-off-by: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
---
 src/dnsmasq.c | 7 ---
 src/dnsmasq.h | 1 +
 src/dnssec.c  | 5 +++--
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 045ec53..a47273f 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -750,7 +750,8 @@ int main (int argc, char **argv)
   
   my_syslog(LOG_INFO, _("DNSSEC validation enabled"));
   
-  if (option_bool(OPT_DNSSEC_TIME))
+  daemon->dnssec_no_time_check = option_bool(OPT_DNSSEC_TIME);
+  if (option_bool(OPT_DNSSEC_TIME) && !daemon->back_to_the_future)
my_syslog(LOG_INFO, _("DNSSEC signature timestamps not checked until 
first cache reload"));
   
   if (rc == 1)
@@ -1226,10 +1227,10 @@ static void async_event(int pipe, time_t now)
   {
   case EVENT_RELOAD:
 #ifdef HAVE_DNSSEC
-   if (option_bool(OPT_DNSSEC_VALID) && option_bool(OPT_DNSSEC_TIME))
+   if (daemon->dnssec_no_time_check && option_bool(OPT_DNSSEC_VALID) && 
option_bool(OPT_DNSSEC_TIME))
  {
my_syslog(LOG_INFO, _("now checking DNSSEC signature timestamps"));
-   reset_option_bool(OPT_DNSSEC_TIME);
+   daemon->dnssec_no_time_check = 0;
  } 
 #endif
/* fall through */
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 1896a64..be27ae0 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -992,6 +992,7 @@ extern struct daemon {
 #endif
 #ifdef HAVE_DNSSEC
   struct ds_config *ds;
+  int dnssec_no_time_check;
   int back_to_the_future;
   char *timestamp_file;
 #endif
diff --git a/src/dnssec.c b/src/dnssec.c
index 3c77c7d..64358fa 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -522,15 +522,16 @@ static int check_date_range(u32 date_start, u32 date_end)
  if (utime(daemon->timestamp_file, NULL) != 0)
my_syslog(LOG_ERR, _("failed to update mtime on %s: %s"), 
daemon->timestamp_file, strerror(errno));
  
+ my_syslog(LOG_INFO, _("system time considered valid, now checking 
DNSSEC signature timestamps."));
  daemon->back_to_the_future = 1;
- set_option_bool(OPT_DNSSEC_TIME);
+ daemon->dnssec_no_time_check = 0;
  queue_event(EVENT_RELOAD); /* purge cache */
} 
 
   if (daemon->back_to_the_future == 0)
return 1;
 }
-  else if (option_bool(OPT_DNSSEC_TIME))
+  else if (daemon->dnssec_no_time_check)
 return 1;
   
   /* We must explicitly check against wanted values, because of SERIAL_UNDEF */
-- 
1.9.1

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

Re: [Dnsmasq-discuss] Clarify/Improve DNSSEC related SIGHUP handling

[Kevin Darbyshire-Bryant]

On 27/05/16 13:37, Kevin Darbyshire-Bryant wrote:

Hi Simon,

Please could you consider the attached patch.  It solves a problem that
using dnssec-timestamp also effectively enabled dnssec-no-timecheck.



Any thoughts?

Kevin


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

[Dnsmasq-discuss] Clarify/Improve DNSSEC related SIGHUP handling

[Kevin Darbyshire-Bryant]

Hi Simon,

Please could you consider the attached patch.  It solves a problem that 
using dnssec-timestamp also effectively enabled dnssec-no-timecheck. 
The result of which is that an unfortunately timed SIGHUP could 
accidentally enable dnssec timestamp checking.  In combination with 
dnssec-check-unsigned that could prove 'challenging' :-)


The patch matches the behaviour is as documented in the manpage.

kind regards,

Kevin
>From f94c6d70aaaea0511ef3c7667093b4b54952804e Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
Date: Fri, 27 May 2016 10:23:47 +0100
Subject: [PATCH] Improve dnssec SIGHUP behaviour

Signed-off-by: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk>
---
 src/dnsmasq.c | 7 ---
 src/dnsmasq.h | 1 +
 src/dnssec.c  | 5 +++--
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 045ec53..a47273f 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -750,7 +750,8 @@ int main (int argc, char **argv)
   
   my_syslog(LOG_INFO, _("DNSSEC validation enabled"));
   
-  if (option_bool(OPT_DNSSEC_TIME))
+  daemon->dnssec_no_time_check = option_bool(OPT_DNSSEC_TIME);
+  if (option_bool(OPT_DNSSEC_TIME) && !daemon->back_to_the_future)
 	my_syslog(LOG_INFO, _("DNSSEC signature timestamps not checked until first cache reload"));
   
   if (rc == 1)
@@ -1226,10 +1227,10 @@ static void async_event(int pipe, time_t now)
   {
   case EVENT_RELOAD:
 #ifdef HAVE_DNSSEC
-	if (option_bool(OPT_DNSSEC_VALID) && option_bool(OPT_DNSSEC_TIME))
+	if (daemon->dnssec_no_time_check && option_bool(OPT_DNSSEC_VALID) && option_bool(OPT_DNSSEC_TIME))
 	  {
 	my_syslog(LOG_INFO, _("now checking DNSSEC signature timestamps"));
-	reset_option_bool(OPT_DNSSEC_TIME);
+	daemon->dnssec_no_time_check = 0;
 	  } 
 #endif
 	/* fall through */
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 1896a64..be27ae0 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -992,6 +992,7 @@ extern struct daemon {
 #endif
 #ifdef HAVE_DNSSEC
   struct ds_config *ds;
+  int dnssec_no_time_check;
   int back_to_the_future;
   char *timestamp_file;
 #endif
diff --git a/src/dnssec.c b/src/dnssec.c
index 3c77c7d..64358fa 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -522,15 +522,16 @@ static int check_date_range(u32 date_start, u32 date_end)
 	  if (utime(daemon->timestamp_file, NULL) != 0)
 	my_syslog(LOG_ERR, _("failed to update mtime on %s: %s"), daemon->timestamp_file, strerror(errno));
 	  
+	  my_syslog(LOG_INFO, _("system time considered valid, now checking DNSSEC signature timestamps."));
 	  daemon->back_to_the_future = 1;
-	  set_option_bool(OPT_DNSSEC_TIME);
+	  daemon->dnssec_no_time_check = 0;
 	  queue_event(EVENT_RELOAD); /* purge cache */
 	} 
 
   if (daemon->back_to_the_future == 0)
 	return 1;
 }
-  else if (option_bool(OPT_DNSSEC_TIME))
+  else if (daemon->dnssec_no_time_check)
 return 1;
   
   /* We must explicitly check against wanted values, because of SERIAL_UNDEF */
-- 
1.9.1

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

Re: [Dnsmasq-discuss] HELP: gives BOGUS for valid RR with no DNNSEC

[Kevin Darbyshire-Bryant]

On 25/05/16 19:07, Johnny Appleseed wrote:

Im using the -DNSSEC option and it keeps giving me BOGUS for sites like
wikipedia.org or others.  If i stop /restart sometimes it clear up, or i
remove the check no-sign flag, but then Im not checking unsigned
websites for RR.


Is the system clock set correctly?

What other dnssec related options are you using?

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

Re: [Dnsmasq-discuss] IPv6 dhcp strangeness

[Kevin Darbyshire-Bryant]

The mystery is at least partially solved.  It looks like I'd somehow
enabled Remote Routing and Access services within Windows Home Server
for VPN access.  It looks like it tries to grab a few addresses for
potential VPN clients from a DHCP server, that's why I was seeing
'RRAS.Micrsoft'  as a user class for the extra requests.  With RRAS
disabled no extra DHCPv4 requests are received which at least removed
some of the lease duplication/abandonment.

It also appears to have solved the DHCPv6 behaviour too, with the server
now getting the DHCPv6 address assigned by the dhcp-hosts configuration
line.  Why that should be is also a mystery to me.  Oh well, posted here
just in case someone else falls into a similar trap :-)


Kevin



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

Re: [Dnsmasq-discuss] IPv6 dhcp strangeness

[Kevin Darbyshire-Bryant]

And then a little later:

Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
available DHCP range: 192.168.219.2 -- 192.168.219.253
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
vendor class: MSFT 5.0
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 user
class: RRAS.Microsoft
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
client provides name: Kermit.darbyshire-bryant.me.uk
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
DHCPREQUEST(br-lan) 192.168.219.4 e0:3f:49:a1:d4:aa
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: abandoning
lease to e0:3f:49:a1:d4:aa of 192.168.219.4
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
tags: lan, known, br-lan
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
DHCPACK(br-lan) 192.168.219.4 e0:3f:49:a1:d4:aa kermit
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
requested options: 1:netmask, 15:domain-name, 3:router, 6:dns-server,
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
requested options: 44:netbios-ns, 46:netbios-nodetype, 47:netbios-scope,
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
requested options: 31:router-discovery, 33:static-route,
121:classless-static-route,
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
requested options: 249, 43:vendor-encap
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 next
server: 192.168.219.1
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820
broadcast response
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  1 option: 53 message-type  5
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option: 54 server-identifier  192.168.219.1
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option: 51 lease-time  12h
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option: 58 T1  6h
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option: 59 T2  10h30m
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option:  1 netmask  255.255.255.0
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option: 28 broadcast  192.168.219.255
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option:  3 router  192.168.219.1
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option:  6 dns-server  192.168.219.1
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size: 23 option: 15 domain-name  darbyshire-bryant.me.uk
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size: 33 option: 81 FQDN  03:ff:ff:6b:65:72:6d:69:74:2e:64:61:72:62...
Tue May  3 18:43:58 2016 daemon.info dnsmasq-dhcp[2862]: 3895499820 sent
size:  4 option: 44 netbios-ns  192.168.219.1

What the hell is this box doing?! :-/


Kevin


On 02/05/2016 17:24, Simon Kelley wrote:
> On 30/04/16 11:32, Kevin Darbyshire-Bryant wrote:
>> Further clues maybe:  So initially when kermit comes up it grabs an IPv4
>> address and I see this entry in dnsmasq's lease database:
>> 1462055024 e0:3f:49:a1:d4:aa 192.168.219.4 Kermit 01:e0:3f:49:a1:d4:aa
>>
>> Which looks pretty normal to me.  Then a little while later, presumably
>> after a dhcpv6 request it gets changed to
>> 1462055060 e0:3f:49:a1:d4:aa 192.168.219.4 Kermit
>> 01:52:41:53:20:e0:3f:49:a1:d4:aa:00:00:09:00:00:00
>>
>> There are also syslog messages of "abandoning lease to e0:3f:49:a1:d4:aa
>> of 192.168.219.4" which I don't get at all.
>>
>>
> Are you dual-booting Kermit, or netbooting it, or doing anything else
> which may cause it to run more than one DHCP client? From the
> information given it looks like the host with MAC address
> e0:3f:49:a1:d4:aa is presenting two different client-ids at different
> times. Since client-id trumps MAC address as a unique host identifier,
> that could explain what's going on. (the client-id is the last field in
> the leases database).
>
> Setting log-dhcp and posting the logs showing this sort of thing
> happening would be useful.
>
> Cheers,
>
> Simon.
>
>
>>
>> On 29/04/16 12:27, Kevin Darbyshire-Bryant wrote:
>>> Hi All,
>>>
>>>
>>> I've just noticed some strange/different behaviour with regard to
>>> dhcpv6 address allocation.  I've a couple of 'internal' machines that
>>> I'd like to have fixed ip addresses.  To that end, and it used to work
>>> I've got lines similar to: 
>>> dhcp-host=E0:3F:49:A1:D4:AA,192.168.219.4,[::0:4],Kermit   - In theory
>>> kermit gets 192.168.219.4 and the ipv6 addre

Re: [Dnsmasq-discuss] IPv6 dhcp strangeness

[Kevin Darbyshire-Bryant]

Hi Simon,

Thanks for getting back to me.  Kermit is a Windows Home Server box and
is definitely not net or dual booted.  Here's the relevant 'log dhcp'
extract from a clean boot of it. 

dhcp-host=id:00:01:00:01:1b:75:4c:36:e0:3f:49:a1:d4:aa,[::4],Kermit
dhcp-host=E0:3F:49:A1:D4:AA,192.168.219.4,kermit

Before booting:

nslookup kermit
nslookup: can't resolve '(null)': Name does not resolve

Name:  kermit
Address 1: 2001:470:183f:da2b::4 kermit.darbyshire-bryant.me.uk
Address 2: 192.168.219.4 kermit.darbyshire-bryant.me.uk

No entries in dhcp.leases.

Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
available DHCP range: 192.168.219.2 -- 192.168.219.253
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
vendor class: MSFT 5.0
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
client provides name: Kermit
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
DHCPREQUEST(br-lan) 192.168.219.4 e0:3f:49:a1:d4:aa
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
tags: lan, known, br-lan
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
DHCPACK(br-lan) 192.168.219.4 e0:3f:49:a1:d4:aa kermit
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
requested options: 1:netmask, 15:domain-name, 3:router, 6:dns-server,
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
requested options: 44:netbios-ns, 46:netbios-nodetype, 47:netbios-scope,
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
requested options: 31:router-discovery, 33:static-route,
121:classless-static-route,
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
requested options: 249, 43:vendor-encap
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 next
server: 192.168.219.1
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837
broadcast response
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  1 option: 53 message-type  5
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option: 54 server-identifier  192.168.219.1
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option: 51 lease-time  12h
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option: 58 T1  6h
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option: 59 T2  10h30m
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option:  1 netmask  255.255.255.0
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option: 28 broadcast  192.168.219.255
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option:  3 router  192.168.219.1
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option:  6 dns-server  192.168.219.1
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size: 23 option: 15 domain-name  darbyshire-bryant.me.uk
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size: 33 option: 81 FQDN  03:ff:ff:6b:65:72:6d:69:74:2e:64:61:72:62...
Tue May  3 18:40:57 2016 daemon.info dnsmasq-dhcp[2862]: 1035611837 sent
size:  4 option: 44 netbios-ns  192.168.219.1
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055
available DHCP range: 2001:470:183f:da2b::2 -- 2001:470:183f:da2b:::
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055 vendor
class: 311
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055
DHCPCONFIRM(br-lan) 00:01:00:01:1b:75:4c:36:e0:3f:49:a1:d4:aa
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055
DHCPREPLY(br-lan) 2001:470:183f:da2b::9f93:7b6a
00:01:00:01:1b:75:4c:36:e0:3f:49:a1:d4:aa Kermit
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055 tags:
known, dhcpv6, br-lan
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055 sent
size: 14 option:  1 client-id  00:01:00:01:1b:75:4c:36:e0:3f:49:a1:d4:aa
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055 sent
size: 14 option:  2 server-id  00:01:00:01:1e:b7:72:d8:14:cc:20:be:89:33
Tue May  3 18:40:58 2016 daemon.info dnsmasq-dhcp[2862]: 9972055 sent
size: 29 option: 13 status  0 all addresses still on link

Only Entry in dhcp.leases related to kermit

1462340457 e0:3f:49:a1:d4:aa 192.168.219.4 kermit 01:e0:3f:49:a1:d4:aa

Kermit thinks it has 2001:470:183f:da2b::9f93:7b6a as per the dhcp
reply, which is fair enough but I don't understand why the UID was
ignored.  Also, nslookup replies from dnsmasq still only return the
configured addresses for kermit and no sign of the dhcpv6 allocated one.

Ideas?


Kevin






On 02/05/2016 17:24, Simon Kelley wrote:
> On 30/04/16 11:32, Kevin Darbyshire-Bryant wrote:
>> Further clues maybe:  So initially when kermit comes up it grabs an IPv4
>> address and I see this entry in 

Re: [Dnsmasq-discuss] IPv6 dhcp strangeness

[Kevin Darbyshire-Bryant]

Further clues maybe:  So initially when kermit comes up it grabs an IPv4
address and I see this entry in dnsmasq's lease database:
1462055024 e0:3f:49:a1:d4:aa 192.168.219.4 Kermit 01:e0:3f:49:a1:d4:aa

Which looks pretty normal to me.  Then a little while later, presumably
after a dhcpv6 request it gets changed to
1462055060 e0:3f:49:a1:d4:aa 192.168.219.4 Kermit
01:52:41:53:20:e0:3f:49:a1:d4:aa:00:00:09:00:00:00

There are also syslog messages of "abandoning lease to e0:3f:49:a1:d4:aa
of 192.168.219.4" which I don't get at all.




On 29/04/16 12:27, Kevin Darbyshire-Bryant wrote:
>
> Hi All,
>
>
> I've just noticed some strange/different behaviour with regard to
> dhcpv6 address allocation.  I've a couple of 'internal' machines that
> I'd like to have fixed ip addresses.  To that end, and it used to work
> I've got lines similar to: 
> dhcp-host=E0:3F:49:A1:D4:AA,192.168.219.4,[::0:4],Kermit   - In theory
> kermit gets 192.168.219.4 and the ipv6 address 'constructed prefix::0:4'
>
>
> Instead, these lines appear to be partially ignored with the host
> getting the usual pseudo random address constructed from the ipv6
> prefix/range.  An nslookup pointing to dnsmasq does return the '0:4'
> address, unfortunately that's not the address handed out by dhcp.  
> I'm also seeing ' abandoning lease to e0:3f:49:a1:d4:aa of
> 192.168.219.4' type warnings which is odd.  Also the entry in the
> leases database looks odd to me: 1461971298 e0:3f:49:a1:d4:aa
> 192.168.219.4 Kermit
> 01:52:41:53:20:e0:3f:49:a1:d4:aa:00:00:09:00:00:00 - that almost looks
> like an ipv6 type entry.
>
>
> Confused!
>
>
> Kevin
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss




smime.p7s
Description: S/MIME Cryptographic Signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] IPv6 dhcp strangeness

[Kevin Darbyshire-Bryant]

Hi All,


I've just noticed some strange/different behaviour with regard to dhcpv6
address allocation.  I've a couple of 'internal' machines that I'd like
to have fixed ip addresses.  To that end, and it used to work I've got
lines similar to: 
dhcp-host=E0:3F:49:A1:D4:AA,192.168.219.4,[::0:4],Kermit   - In theory
kermit gets 192.168.219.4 and the ipv6 address 'constructed prefix::0:4'


Instead, these lines appear to be partially ignored with the host
getting the usual pseudo random address constructed from the ipv6
prefix/range.  An nslookup pointing to dnsmasq does return the '0:4'
address, unfortunately that's not the address handed out by dhcp.   I'm
also seeing ' abandoning lease to e0:3f:49:a1:d4:aa of 192.168.219.4'
type warnings which is odd.  Also the entry in the leases database looks
odd to me: 1461971298 e0:3f:49:a1:d4:aa 192.168.219.4 Kermit
01:52:41:53:20:e0:3f:49:a1:d4:aa:00:00:09:00:00:00 - that almost looks
like an ipv6 type entry.


Confused!


Kevin

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

Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC

[Kevin Darbyshire-Bryant]

On 04/01/2016 16:05, Uwe Schindler wrote:
> Hi,
>
> Was there a change in dnsmasq related to this? Would be good to get some 
> feedback. I'll try this version now. Currently I am running 2.75 (Debian 
> testing pkg 2.75-1)
Yes.  BIG changes.  See the git log:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary

In fact I see I am far behind the times - test3 out 12 minutes ago :-)
> Do you have dnssec enabled?
Yes.

Kevin

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

Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC

[Kevin Darbyshire-Bryant]

On 04/01/16 14:48, Uwe Schindler wrote:
> Hi,
>
> I found out that resolving of DNSSEC signed wildcard domains does not work 
> correctly with dnsmasq. I think the problem is that it looks for a signature 
> of the requested domain name and not the wildcard.
>
>
>
> ;; Query time: 0 msec
> ;; SERVER: 85.25.128.10#53(85.25.128.10)
> ;; WHEN: Mon Jan  4 14:42:43 2016
> ;; MSG SIZE  rcvd: 471
>
> How should this be solved? This is another one where dnssec fails, so clearly 
> a bug.
>
> There is a test page about exactly that case, which fails for me when 
> resolving through dnsmasq: http://0skar.cz/dns/en/
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
I just tried that page using dnsmasq276test2 and got 'green' for all tests.

Kevin




smime.p7s
Description: S/MIME Cryptographic Signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CPU spin in master

[Kevin Darbyshire-Bryant]

Router survived the night. No obvious problems noted :-)

--
Cheers,

Kevin
Sent from my phone, apologies for brevity, spelling & top posting

> On 2 Jan 2016, at 17:20, Kevin Darbyshire-Bryant 
> <ke...@darbyshire-bryant.me.uk> wrote:
> 
> 
> 
>> On 01/01/16 20:27, Simon Kelley wrote:
>>> On 01/01/16 11:28, Kevin Darbyshire-Bryant wrote:
>>> Hi Simon,
>>> 
>>> So this is a pretty vague report of something lurking in very recent code.#
>> It's pretty good really. I stared at the ARP-caching code and found a
>> fault in the linked list code that could introduce a cycle and create
>> exactly the symptoms you're seeing.
>> 
>> 
>> Git HEAD or 2.76test2 should do it. Please could you try it?
> It's compiling as I type - will report back :-)
>> 
>> 
>> And many thanks for testing my new code!
> Well if we all played it safe and avoided the bleeding edge stuff
> nothing would get spotted & fixed would it :-)  Someone has to try and
> I'd hardly regard my home router as life critical (although my niece
> would have a different opinion on that if she were visiting)
> 
> Thanks,
> 
> Kevin
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


smime.p7s
Description: S/MIME cryptographic signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CPU spin in master

[Kevin Darbyshire-Bryant]

On 01/01/16 20:27, Simon Kelley wrote:
> On 01/01/16 11:28, Kevin Darbyshire-Bryant wrote:
>> Hi Simon,
>>
>> So this is a pretty vague report of something lurking in very recent code.#
> It's pretty good really. I stared at the ARP-caching code and found a
> fault in the linked list code that could introduce a cycle and create
> exactly the symptoms you're seeing.
>
>
> Git HEAD or 2.76test2 should do it. Please could you try it?
It's compiling as I type - will report back :-)
>
>
> And many thanks for testing my new code!
Well if we all played it safe and avoided the bleeding edge stuff
nothing would get spotted & fixed would it :-)  Someone has to try and
I'd hardly regard my home router as life critical (although my niece
would have a different opinion on that if she were visiting)

Thanks,

Kevin
 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] CPU spin in master

[Kevin Darbyshire-Bryant]

Hi Simon,

First off, Happy New Year!

I compiled master ec0628c4b2a06e1fc21216091bb040d61a43b271 on OpenWrt
(mips Archer C7 v2 platform  Linux 4.1) a few hours ago and have
experienced dnsmasq going into a tight cpu loop.  Running strace showed
no syscalls, so is spinning in dnsmasq somewhere.  Kill -9 seemed to be
the only way out, and the behaviour would return an indeterminate time
after restart. Unfortunately I didn't have gdb installed on the router,
dnsmasq compiled with debug, nor any experience with gdb for that
matter, so it's a very limited amount of info I can offer.

I tried turning off dnssec usage in case that avoided the problem, which
it didn't.  I'm not really sure what provokes the behaviour.  However
I'd been running efef497b890231ba9232d02e7bfaf8273f044622 for a week
without incident, and have now backed out to
d3a8b39c7df2f0debf3b5f274a1c37a9e261f94e as of a few hours ago (avoiding
the arp caching) so far also without incident.

So this is a pretty vague report of something lurking in very recent code.

Cheers,

Kevin

 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss