[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

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

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

[Kevin Darbyshire-Bryant]

> I looked at the code that determines private addresses for --bogus-priv
> and rebind: It's a bit unruly for IPv6, so I've rationalised things and
> included :: and 0.0.0.0 in the --rebind-localhost-ok coverage, which at
> least avoids the log spam.
> 
> 
> I wonder if bogus-nxdomain should be extended to IPv6, or we could add
> another option which is the equivalent of
> 
> bogus-nxdomain=0.0.0.0,::
> 
> Or both.

Thanks Simon, definitely looks more rational, will give it a try.

Incidentally, is there a typo in a92c6d77dcd475579c39bdff141f5eb128e2a048 ? - I 
think you mean to de-ref the pointer, not compare the pointer.


diff --git a/src/domain-match.c b/src/domain-match.c
index f82bbdb..97ae9c5 100644
--- a/src/domain-match.c
+++ b/src/domain-match.c
@@ -591,7 +591,7 @@ int add_update_server(int flags,
   else if (*domain == '*')
 {
   domain++;
-  if (domain != 0)
+  if (*domain)
flags |= SERV_WILDCARD;
 }


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] [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

[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] 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

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 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] 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] 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] 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] 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

[Dnsmasq-discuss] Change in dnsmasq.leases behaviour?

[Kevin Darbyshire-Bryant]

Hi All,

Slightly long story and I'm *very* new to all this so please go easy :-)

I'm a 'Tomato' firmware router user and recently been getting into IPv6
- discovered a known bug whereby dnsmasq wasn't setting the 'on-link'
bit in the IPv6 RAs.  Having not played with linux much before I then
set about creating a firmware build environment so I could roll my own
firmware until the Tomato developer/s upgrading dnsmasq from 2.61 to
something recent (2.65 or even current)  The learning curve of late has
been huge what with 'git' & makefiles 'n' stuff.  Anyway, I've upgraded
to 2.65 and while this has fixed the RA on-link issue the behaviour of
dnsmasq.leases file appears to have changed:

A 2.61 file looks like

43200 cc:7e:e7:7d:5f:63 192.168.235.6 Viera-TV 01:cc:7e:e7:7d:5f:63
42974 24:77:03:47:8f:ec 192.168.235.235 Animal 01:24:77:03:47:8f:ec
duid 00:03:00:01:20:4e:7f:b7:4a:c0

a 2.65 file looks like

43200 24:77:03:47:8f:ec 192.168.235.235 Animal 01:24:77:03:47:8f:ec
43200 18:87:96:59:a3:58 192.168.235.131 Kevins-Sensation-XE *
43200 00:10:83:77:af:bd 192.168.235.126 Laser *
duid 00:03:00:01:20:4e:7f:b7:4a:c0
43200 301991503 2001:470:1f09:1ac::9e25 *
00:01:00:01:18:7d:49:a8:00:22:15:d8:78:25
43200 371488515 2001:470:1f09:1ac::1d88 Animal
00:01:00:01:16:a2:0a:60:f0:de:f1:be:f5:48

Note that all the lease 'expiry' times appear to be the same despite
being obtained at different times.

I this causes problems for the Tomato router device status page which is
supposed to show currently 'known' devices including lease time expiry
which it now gets wrong/missing.

As a workaround to all this I've patched 2.61 to include the RA on-link
flag fix, but it'd be really great to have the latest version working. 
Any ideas what's wrong?

compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP
DHCPv6 no-Lua TFTP no-conntrack

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] Change in dnsmasq.leases behaviour?

[Kevin Darbyshire-Bryant]

On 10/02/2013 15:49, Vladislav Grishenko wrote:
> Hi, Kevin
> probably it's because while dnsmasq upgrading, tomato-specific patches
> were rollbacked/missed, one of them includes custom lease expiration
> time. if you're interested, take a look at dnsmasq changes in recent
> asuswrt fws. thay have what you want.
> another solution will be drop patching and disable have_broken_rtc
> define - different issues, different story.
>
> Best regards, Vladislav Grishenko
>
Ah!  The light dawns, thanks Vladislav.

I've just done a diff between tomato dnsmasq 2.61 & tarball dnsmasq 2.61
and indeed they're not the same.

Oh boy, for a non linux & non c programmer how deep this rabbit hole
goes!  H.



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] Enable HAVE_IPSET by default

[Kevin Darbyshire-Bryant]

On 21/03/2013 10:08, Simon Kelley wrote:
> 
>
> Finally, if it's going to be on by default, and given the limited size
> delta/lack of library definitions, there's an argument for not making
> it compile-time selectable at all. Every compile-time switch
> contributes to the combinatorial explosion of possible binaries, and
> lots of bugs come from unanticipated interactions in untested
> compile-flag combinations.
>
>
> Opinions, anyone?
>
>
>
> Simon.

Hi Simon,

I'll express an opinion, based purely on my *very* limited experience of
integrating 2.66test16 into a recent version of Tomato to fix some IPv6
problems.  I keen an eye on latest git pushes and integrate those into
my own personal version for testing.  I'm very much waiting for 2.66
release to come out so that I can push that to the proper Tomato
maintainers.

Size is a very important consideration for Tomato as some versions are
expected to run on a 2.4 kernel and squeeze into 3.8MB of flash rom
space - bytes matter.  Having said that, the Tomato developers don't
have to upgrade to the latest dnsmasq (have been running 2.61 for some
time) and the continuing support of what must be regarded as legacy
hardware has to come to an end sometime.

Based very much on your 'compile time switches lead to untested
combinations of binaries' argument, I'd say remove it as an option and
make it a standard feature.

Well it's an opinion, but what do I know :-)

Kevin

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

[Dnsmasq-discuss] Config file behaviour - change/bug/feature - comments

[Kevin Darbyshire-Bryant]

Hi Simon,

As previously mentioned I got 2.66test16 into a recent version of Tomato
router firmware which means it's now out in the wild and being used.  An
obscure corner case change in behaviour has been observed, relating to
disabling and then re-enabling dhcp service on an interface, and
specifically which lines in a config file stick.  Example config:

interface=br0
no-dhcp-interface=br0

then later in the file:

interface=br0
dhcp-range=br0,192.168.235.21,192.168.235.254,255.255.255.0,720m
dhcp-option=br0,3,192.168.235.1
dhcp-option=br0,44,0.0.0.0

Now in v2.61 (!) dnsmasq would take the last interface line and say 'oh
you do want dns AND dhcp service' and everything would procede as
expected.  In 2.66, once no-dhcp-interface is set it's set and dhcp
service is disabled forever.  Now there's a very valid argument that the
above example is a stupid config file.  Unfortunately the example config
file is representative of the conflicts between the automatically
generated part of Tomato's dnsmasq config, and the manual 'advanced
config options' that get appended to the file via the router's GUI.

Now I personally think the router's gui should be fixed (though I've no
idea how at this point) but is there perhaps an argument that an
'interface=intfn' command later in the file should also reset the
'no-dhcp-flag'?

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] Config file behaviour - change/bug/feature - comments

[Kevin Darbyshire-Bryant]

On 27/03/2013 17:40, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
>


Right, now that I've had the problem further clarified to me, here's the
real issue.

In essence, dnsmasq when parsing options uses the values from the first
instance of a parameter and not (as before) the last.

Bug?  Feature?  Config file stupidity? 

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] Config file behaviour - change/bug/feature - comments

[Kevin Darbyshire-Bryant]

>> Ahh, but there's the rub, the first instance of dhcp-option=br0,...
>> is generated automatically by the router software and cannot be changed,
>> it's why we need to be able to override it.
>
> Ok. will have to think harder about this, in that case.
>
Sorry!
>> But I'm now concerned about your previous email where I think interfaces
>> have been removed.  Is it no longer possible to define dhcp range &
>> options on an interface by interface basis?
>
> No. The interface: thing in dhcp-range is/was something
> else. If you were not using that specific syntax, then there's no
> problem.
>
> Cheers,
>
> Simon.

Looking at what Tomato produces in its dnsmasq.conf files for dhcp-range
I'm not convinced it's ever been correct.  Following truncated example
of what it used to produce for just a single interface:

interface=br0 
dhcp-range=br0,192.168.235.21,192.168.235.254,255.255.255.0,720m 
dhcp-option=br0,3,192.168.235.1 
dhcp-option=br0,44,192.168.235.1 
dhcp-host=00:A0:DE:88:51:B0,192.168.235.7 

dhcp-lease-max=255 
dhcp-authoritative 
interface=ppp4,ppp5,ppp6,ppp7,ppp8,ppp9 
no-dhcp-interface=ppp4,ppp5,ppp6,ppp7,ppp8,ppp9 


Now if I understand it correctly, the intention was to provide the
dhcp-range for a specific interface, but the syntax is wrong AND the
int: option no longer exists since 2.63.   So I think the following is
more correct (and is what my presently tweaked test version of Tomato is
producing)

interface=br0 
dhcp-range=set:br0,192.168.235.21,192.168.235.254,255.255.255.0,720m 
dhcp-option=br0,3,192.168.235.1 
dhcp-option=br0,44,192.168.235.1 
dhcp-host=00:A0:DE:88:51:B0,192.168.235.7 

dhcp-lease-max=255 
dhcp-authoritative 
interface=ppp4,ppp5,ppp6,ppp7,ppp8,ppp9 
no-dhcp-interface=ppp4,ppp5,ppp6,ppp7,ppp8,ppp9 


This at least sets a tag per interface/dhcp-range which can then be
applied to later attributes (eg dhcp-options) on a per
interface/dhcp-range basis.

Have I understood things correctly?

Many thanks for your time and support on this.

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] Apple iOS beating hell out of DHCP

[Kevin Darbyshire-Bryant]

Does anyone else see Apple iDevices making lots of repeated DHCP renewal
requests in their dnsmasq log files?

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] IPv6 constructor option - confused!

[Kevin Darbyshire-Bryant]

Hi Simon,

I find myself confused by the use of the constructor option for building
DHCPv6 address ranges.

edited dnsmasq.conf file:

enable-ra
dhcp-range=tag:br0,::1, ::, constructor:br0, ra-names, 12h

Now on my Tomato based router this picks up then (tunnelled) ipv6 LAN
address on the BR0 interface, which happens to be ISP_PREFIX::1  It
builds a range ISP_PREFIX::1 -> ISP_PREFIX:: and all is well.

However, others do not have a nice neat '::1' they have (presumably
because it's been delegated to them by their ISP) something like
ISP_PREFIX::DEAD:BEEF:F00D.   Now there are two problems as I see it
with this:

1) I now need to specify my starting IP address range as DEAD:BEEF:F00D
otherwise dnsmasq doesn't find the prefix and doesn't serve an IPv6
addresses at all.  In which case why am I even bothering to tell it the
interface in the constructor?

2) The range parameter (:) implies I can define a range from
DEAD:BEEF:F00D to DEAD:BEEF: only with nothing lower than F00D.

I'm sure I'm being stupid here, please educate me again :-)


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] IPv6 constructor option - confused!

[Kevin Darbyshire-Bryant]

On 02/05/2013 09:36, Simon Kelley wrote:
> On 01/05/13 16:26, Kevin Darbyshire-Bryant wrote:
>> Hi Simon,
>>
>> I find myself confused by the use of the constructor option for building
>> DHCPv6 address ranges.
>>
>> edited dnsmasq.conf file:
>>
>> enable-ra
>> dhcp-range=tag:br0,::1, ::, constructor:br0, ra-names, 12h
>>
>> Now on my Tomato based router this picks up then (tunnelled) ipv6 LAN
>> address on the BR0 interface, which happens to be ISP_PREFIX::1  It
>> builds a range ISP_PREFIX::1 ->  ISP_PREFIX:: and all is well.
>>
>> However, others do not have a nice neat '::1' they have (presumably
>> because it's been delegated to them by their ISP) something like
>> ISP_PREFIX::DEAD:BEEF:F00D.   Now there are two problems as I see it
>> with this:
>>
>> 1) I now need to specify my starting IP address range as DEAD:BEEF:F00D
>> otherwise dnsmasq doesn't find the prefix and doesn't serve an IPv6
>> addresses at all.  In which case why am I even bothering to tell it the
>> interface in the constructor?
>>
>> 2) The range parameter (:) implies I can define a range from
>> DEAD:BEEF:F00D to DEAD:BEEF: only with nothing lower than F00D.
>>
>> I'm sure I'm being stupid here, please educate me again :-)
>>
>
> I think the root confusion is between a DHCP address lease, and a
> prefix delegation. DHCP leases as we all know them are for an IP
> address, so could indeed be ISP_PREFIX::DEAD:BEEF:F00D. But
> constructed ranges are intended for use with prefix delegation. Here,
> the ISP leases you not an address but a whole prefix: ISP_PREFIX::/64
>
> The prefix size doesn't have to be a /64, but it usually is, and
> that's the only size dnsmasq supports so let's simplify and assume it is.
>
> A prefix delegation of ISP_PREFIX::/64 gives you the use of the whole
> range, ISP_PREFIX::0 to ISP_PREFIX:::::. You want to
> use this range on a network, so you need to configure the interface in
> the router with an address on the range, but all the addresses are
> available: it's a local choice which one(s) to use, nothing to do with
> the ISP which delegated the prefix.
>

Okay, I get all the above however my router is behaving not quite as I
expect.  Some examples:

Non-working:

root@Router:/tmp/home/root# ifconfig br0
br0Link encap:Ethernet  HWaddr 20:4E:7F:B7:4A:C0
   inet addr:192.168.235.1  Bcast:192.168.235.255 
Mask:255.255.255.0
   inet6 addr: fe80::224e:7fff:feb7:4ac0/64 Scope:Link
   inet6 addr: 2001:470:1f09:100::100/64 Scope:Global
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:1998 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1565 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:461488 (450.6 KiB)  TX bytes:998389 (974.9 KiB)

dnsmasq.conf (extract)

enable-ra
dhcp-range=tag:br0,::1, :::::, constructor:br0,
ra-names, 12h
dhcp-option=option6:24,"internal"
dhcp-option=252,"\n"
#log-dhcp


syslog:

May  2 12:40:14 Router daemon.info dnsmasq[12845]: started, version
2.67test2tomato cachesize 1500
May  2 12:40:14 Router daemon.info dnsmasq[12845]: compile time options:
IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP
no-conntrack ipset Tomato-helper auth
May  2 12:40:14 Router daemon.warn dnsmasq[12845]: warning: interface
ppp9 does not currently exist
May  2 12:40:14 Router daemon.warn dnsmasq[12845]: warning: interface
ppp8 does not currently exist
May  2 12:40:14 Router daemon.warn dnsmasq[12845]: warning: interface
ppp7 does not currently exist
May  2 12:40:14 Router daemon.warn dnsmasq[12845]: warning: interface
ppp6 does not currently exist
May  2 12:40:14 Router daemon.warn dnsmasq[12845]: warning: interface
ppp5 does not currently exist
May  2 12:40:14 Router daemon.warn dnsmasq[12845]: warning: interface
ppp4 does not currently exist
May  2 12:40:14 Router daemon.info dnsmasq[12845]: asynchronous logging
enabled, queue limit is 5 messages
May  2 12:40:14 Router daemon.info dnsmasq-dhcp[12845]: DHCP, IP range
192.168.235.21 -- 192.168.235.254, lease time 12h
May  2 12:40:14 Router daemon.info dnsmasq-dhcp[12845]: DHCPv6, IP range
::1 -- :::::, lease time 12h, template for br0
May  2 12:40:14 Router daemon.info dnsmasq-dhcp[12845]: DHCPv4-derived
IPv6 names on ::1, template for br0
May  2 12:40:14 Router daemon.info dnsmasq-dhcp[12845]: router
advertisement on ::1, template for br0
May  2 12:40:14 Router daemon.info dnsmasq-dhcp[12845]: IPv6 router
advertisement enabled
May  2 12:40:14 Router daemon.info dnsmasq[12845]: using local addresses
only for domain internal
May  2 12:40:14 Route

Re: [Dnsmasq-discuss] IPv6 constructor option - confused!

[Kevin Darbyshire-Bryant]

On 02/05/2013 13:02, Kevin Darbyshire-Bryant wrote:
> Specifying the router's LAN IPv6 address as the start of the range was
> not how I anticipated this option to work. And I don't think you do
> either based upon your above description. So is this an oversight or
> some tomato based wierdness...either way, how can I help to sort it
> out? Kevin
>
>

Ahhh!  Right, a clue:  Changing

enable-ra
dhcp-range=tag:br0,::100, :::::, constructor:br0,
ra-names, 12h

to

enable-ra
dhcp-range=::100, :::::, constructor:br0, ra-names, 12h

makes it work as expected.

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] IPv6 constructor option - confused!

[Kevin Darbyshire-Bryant]

On 02/05/2013 13:09, Kevin Darbyshire-Bryant wrote:
>
> Ahhh!  Right, a clue:  Changing
>
> enable-ra
> dhcp-range=tag:br0,::100, :::::, constructor:br0,
> ra-names, 12h
>
> to
>
> enable-ra
> dhcp-range=::100, :::::, constructor:br0, ra-names, 12h
>
> makes it work as expected.

Oooops, ignore that.  No it doesn't.  Forgotten I'd changed the LAN IP
address to ::100 to test something else. Doh!

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] IPv6 constructor option - confused!

[Kevin Darbyshire-Bryant]

On 02/05/2013 17:00, Simon Kelley wrote:
>
> It is how I expected it to work, exactly.
>
> DHCP-PD client gets prefix, and assigns ::1 to LAN interface.
>
> dnsmasq gives addresses between
>
> ::2 and ::
>
> to clients on the LAN.
>

Which (contrived case) isn't ideal if for some reason the DHCP-PD client
assigns prefix:::: to the lan interface,
'cos the constructor has nowhere to go.  The constructor will go up from
the lowest address, it doesn't appear to work down,
though it does sort the addresses in syslog from lowest to highest.  But
this is VERY contrived :-)

>>
>> So is this an oversight or some tomato based wierdness...either way, how
>> can I help to sort it out?
>
> Suggest an alternative, given that constructing a DHCP range based on
> any address in a prefix is not desirable.
>
H, what about seeing if the interface in question has an address
inside the DHCP constructed range and if it does then use the prefix? 
Or is that excluded by your above statement?

Perhaps if I explain what I'm trying to do it may help.  I'm trying to
remove the requirement for RADVD in the tomato router
environment.  There are a number of potential benefits, not least having
an equivalent local DNS service to the IPv4 dhcp/dns service (privacy
extensions not helping but)  My thought was that the 'constructor'
option was ideal, in that I could assign a constructor range of ::0
-::::: and it would pick up the prefix and start serving
addresses through RA & DHCPv6.  Unfortunately it looks like what I would
like isn't quite what 'constructor' actually gives me.



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] IPv6 constructor option - confused!

[Kevin Darbyshire-Bryant]

On 02/05/2013 17:54, Kevin Darbyshire-Bryant wrote:
>> Suggest an alternative, given that constructing a DHCP range based on
>> any address in a prefix is not desirable.
>>
> H, what about seeing if the interface in question has an address
> inside the DHCP constructed range and if it does then use the prefix? 
> Or is that excluded by your above statement?
>

I take it that the above idea is daft.

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] replace dnsmaq by radvd

[Kevin Darbyshire-Bryant]

Sorry top posted I know. However constructor options requires interface to have 
host address match the start point of your constructor option before it will 
pick up the prefix. 

So BR-private must have address "prefix"::1 so it matches the constructor 
range. 

Hope that helps

Kevin

--
Cheers,

On 15 May 2013, at 17:38, "Moritz Warning"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> I try to replace radvd by dnsmasq but have trouble to configure dnsmasq.
> 
> This line in /etc/dnsmasq.conf works as expected:
> dhcp-range=fdef:17a0:ffb1:1::,slaac
> 
> But actually I like dnsmasq to get the ipv6 prefix from the interface
> it should advertise on (br-private).
> 
> This line doesn't seem to work:
> dhcp-range=::1,constructor:br-private,slaac
> 
> I have read the manpage but couldn't see anything wrong.
> Could someone point out what is wrong?
> 
> regards,
> mwarning
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJRk7a5AAoJECHrh56PP4wpa5oIAKoOpJTVlcBIukWppwpDHZMO
> s70TBZPyFHGXTDSA1DtwXmAIhzMVeag4tIzN9Vs8yRmeoiokN0wghz/Qv8BHIgXF
> KRNKhQKzvSf4b2rTnx70DGvgfI3/3jJgIR9pgFjpeL8cHpRdGdar3qLpAw5Tar0A
> 2PQ9n2rmKK7NXeWCQk4LqzDUtkQoY8/4s1pj1rQG2ZyMs8vLr1oVLCXbkGNBtv//
> I8j61j190Ou8zXyolB9NdGbC/p1pvSx8of08DeAZo/TzDfHTWPU8nX8b6/R8Q7CL
> P/lbSgeF4mvzMHucsmo6jiFma2NGSqpezNvTd3iE9zfrjWqAKugzYNlhGVTnyB8=
> =OZwN
> -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] replace dnsmaq by radvd

[Kevin Darbyshire-Bryant]

On 22/05/2013 22:43, Moritz Warning wrote:
> Sorry for the delay - life is busy. :)
>
> Actually the ip address of br-private is of type "prefix"::1
>
> root@OpenWrt:~# ip -6 address show dev br-private
> 8: br-private:  mtu 1500
> inet6 fdef:17a0:ffb1:1::1/64 scope global
>valid_lft forever preferred_lft forever
> inet6 fe80::f887:99ff:fea9:34af/64 scope link
>valid_lft forever preferred_lft forever
>
> Here is the content of my dnsmasq.conf:
> enable-ra
> dhcp-range=fdef:17a0:ffb1:1::1,constructor:br-private,slaac,64,infinite
> dhcp-authoritative
> domain-needed
> localise-queries
> read-ethers
> bogus-priv
> expand-hosts
> dhcp-leasefile=/tmp/dhcp.leases
> resolv-file=/tmp/resolv.conf.auto
>
>
> dhcp-range=private,192.168.133.100,192.168.133.249,255.255.255.0,12h
> dhcp-option=private,3,192.168.133.1
> dhcp-range=public,10.29.0.1,10.29.254.254,255.255.0.0,2h
> dhcp-option=public,3,10.29.131.187
> no-dhcp-interface=eth0.2
>
>
> The problem is that my computer (attached to br-private) does only
> get an ipv4 address and ipv6 link local (fe80::..).
>
> Any ideas where I should look for errors?
> dnsmasq is version 2.62 (IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP
> no-DHCPv6 no-Lua TFTP no-conntrack).
>
> regards,
> mwarning

Constructor option is 2.66 & later.




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] Clarification of prefix length field in dhcp-range

[Kevin Darbyshire-Bryant]

Hi All,

dnsmasq2.67rc3 - possibly odd behaviour, probably I misunderstand :-)

I have an interface that has a /64 on it.  dnsmasq.conf has amongst
other things
"
dhcp-range=::100, ::F::, constructor:br0, ra-names, 64, 12h
enable-ra
"

This picks up the /64 prefix, allocates a DHCPv6 range and basically
works as I would expect.  In theory the ', 64' in the line is redundant.

Now, if I change said interface to be a /48 (restarting dnsmasq), the
logfile says it's built a constructed range as before, but it no longer
does RA and in fact DHCPv6 requests get rebuffed with a 'no valid
range'.  Shouldn't the ', 64' force this to behave as a /64 for the
constructed range?  And shouldn't it do RA?

Many thanks,

Kevin


Non working logfile extract (so with a /48 on br0 interface)

Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: started, version
2.67rc3-38-gfbc150d cachesize 1500
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: compile time options:
IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP
no-conntrack ipset Tomato-helper auth
Oct  4 19:41:26 Router daemon.warn dnsmasq[4518]: warning: interface
ppp9 does not currently exist
Oct  4 19:41:26 Router daemon.warn dnsmasq[4518]: warning: interface
ppp8 does not currently exist
Oct  4 19:41:26 Router daemon.warn dnsmasq[4518]: warning: interface
ppp7 does not currently exist
Oct  4 19:41:26 Router daemon.warn dnsmasq[4518]: warning: interface
ppp6 does not currently exist
Oct  4 19:41:26 Router daemon.warn dnsmasq[4518]: warning: interface
ppp5 does not currently exist
Oct  4 19:41:26 Router daemon.warn dnsmasq[4518]: warning: interface
ppp4 does not currently exist
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: asynchronous logging
enabled, queue limit is 5 messages
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCP, IP range
192.168.235.21 -- 192.168.235.254, lease time 12h
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv6, IP range
::100 -- ::f::, lease time 12h, template for br0
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv4-derived
IPv6 names on br0
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: router
advertisement on br0
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv6, IP range
2001:470:6b99::100 -- 2001:470:6b99::f::, lease time 12h,
constructed for br0
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv4-derived
IPv6 names on 2001:470:6b99::, constructed for br0
Oct  4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: router
advertisement on 2001:470:6b99::, constructed for br0
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: using local addresses
only for domain internal
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: reading
/etc/resolv.dnsmasq
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: using nameserver
90.207.238.99#53
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: using nameserver
90.207.238.97#53
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: using nameserver
2001:470:20::2#53
Oct  4 19:41:26 Router daemon.info dnsmasq[4518]: using local addresses
only for domain internal
Oct  4 19:41:27 Router daemon.info dnsmasq[4518]: read /etc/hosts - 4
addresses
Oct  4 19:41:27 Router daemon.info dnsmasq[4518]: read
/etc/dnsmasq/hosts/hosts - 30 addresses
Oct  4 19:41:27 Router daemon.info dnsmasq-dhcp[4518]: read
/etc/dnsmasq/dhcp/dhcp-hosts
Oct  4 19:41:28 Router daemon.info dnsmasq-dhcp[4518]: DHCPREQUEST(br0)
192.168.235.130 ac:3c:0b:0c:e7:fd
Oct  4 19:41:28 Router daemon.info dnsmasq-dhcp[4518]: DHCPACK(br0)
192.168.235.130 ac:3c:0b:0c:e7:fd Kevins-iPad
Oct  4 19:41:28 Router daemon.info dnsmasq-dhcp[4518]: DHCPREQUEST(br0)
192.168.235.139 a0:ed:cd:ca:69:c6
Oct  4 19:41:28 Router daemon.info dnsmasq-dhcp[4518]: DHCPACK(br0)
192.168.235.139 a0:ed:cd:ca:69:c6 Kevins-iPhone-5
Oct  4 19:41:31 Router daemon.info dnsmasq-dhcp[4518]: RTR-SOLICIT(br0)
ac:3c:0b:0c:e7:fd
Oct  4 19:41:32 Router daemon.info dnsmasq-dhcp[4518]: RTR-SOLICIT(br0)
a0:ed:cd:ca:69:c6
Oct  4 19:41:33 Router daemon.warn dnsmasq-dhcp[4518]: no address range
available for DHCPv6 request via br0
Oct  4 19:41:35 Router daemon.info dnsmasq-dhcp[4518]: DHCPREQUEST(br0)
192.168.235.235 24:77:03:47:8f:ec
Oct  4 19:41:35 Router daemon.info dnsmasq-dhcp[4518]: DHCPACK(br0)
192.168.235.235 24:77:03:47:8f:ec Animal
Oct  4 19:41:35 Router daemon.warn dnsmasq-dhcp[4518]: no address range
available for DHCPv6 request via br0
Oct  4 19:41:36 Router daemon.info dnsmasq-dhcp[4518]: RTR-SOLICIT(br0)
ac:3c:0b:0c:e7:fd
Oct  4 19:41:36 Router daemon.info dnsmasq-dhcp[4518]: RTR-SOLICIT(br0)
24:77:03:47:8f:ec
Oct  4 19:41:39 Router daemon.warn dnsmasq-dhcp[4518]: no address range
available for DHCPv6 request via br0
Oct  4 19:41:40 Router daemon.info dnsmasq-dhcp[4518]: RTR-SOLICIT(br0)
24:77:03:47:8f:ec
Oct  4 19:41:47 Router daemon.warn dnsmasq-dhcp[4518]: no address range
available for DHCPv6 request via br0

Working (with /64)

Oct  5 14:06:10 Router daemon.info dnsmasq[17194]: star

Re: [Dnsmasq-discuss] Clarification of prefix length field in dhcp-range

[Kevin Darbyshire-Bryant]

On 05/10/2013 22:43, Quintus wrote:
> Am Sat, 5 Oct 2013 14:21:26 +0100
> schrieb Kevin Darbyshire-Bryant :
>
>> Hi All,
> Hi Kevin,
>
>> dnsmasq2.67rc3 - possibly odd behaviour, probably I misunderstand :-)
>>
>> I have an interface that has a /64 on it.  dnsmasq.conf has amongst
>> other things
>> "
>> dhcp-range=::100, ::F::, constructor:br0, ra-names, 64, 12h
>> enable-ra
>> "
> ra-names is useless in a DHCPv6 context as it tells clients to use
> SLAAC (IPv6 stateless autoconfiguration) and *not* DHCPv6. You probably
> want to remove it (enable-ra does the router advertisements for you).

Not all clients support DHCPv6 and do SLAAC instead, so in that case AND
assuming they're dual stack and use DHCPv4 to obtain an IPv4 address,
I'd quite like dnsmasq to see if they're using a non-privacy obscured
SLAAC IPv6 address and make a note of it in DNS if they are. So I'll
keep my 'ra-names' if that's ok with you :-)

>
>> Now, if I change said interface to be a /48 (restarting dnsmasq), the
>> logfile says it's built a constructed range as before, but it no
>> longer does RA and in fact DHCPv6 requests get rebuffed with a 'no
>> valid range'.  Shouldn't the ', 64' force this to behave as a /64 for
>> the constructed range?  And shouldn't it do RA?
> If you want dnsmasq to serve IPs from a /48 net, your *interface* needs
> to have a /48 address assigned. You can’t have your network interface
> have a /64 address and have dnsmasq delivering addresses with a
> different prefix.
I've not been clear. Provider has given me a /48 prefix. If I
artificially subnet that /48 to a /64 on the interface, and the 'subnet'
uses all zeros, then :::::/64 is functionally equivalent
to ::::/48 that the ISP gave me, from their perspective at
least. Dnsmasq works fine when the interface is set to /64. Where it
doesn't work fine is if I keep the /48 prefix length on the interface.
The man page implies I can tell dnsmasq to use a different prefix length
for the leases, and in fact the logfile entries suggest dnsmasq is happy
with the syntax, has found a suitable prefix, says it's going to do
RA's, says it's going to do DHCPv6 but actually does none of those things.

So to clarify, I don't want to advertise a /48 from a /64, rather I want
to advertise a /64 from a /48 (ie in IPv4 terms a subnet)


With a /64 assigned to the interface (so logically 2001:470:6b99:::)
Works
Oct 4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv6, IP range
2001:470:6b99::100 -- 2001:470:6b99::f::, lease time
12h,constructed for br0
Oct 4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv4-derived
IPv6 names on 2001:470:6b99::, constructed for br0
Oct 4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: router
advertisement on 2001:470:6b99::, constructed for br0

With a /48 assigned to the interface: Doesn't work (2000:470:6b99::)
Oct 6 09:18:12 Router daemon.info dnsmasq-dhcp[25953]: DHCPv6, IP range
2001:470:6b99::100 -- 2001:470:6b99::f::, lease time 12h,
constructed for br0
Oct 6 09:18:12 Router daemon.info dnsmasq-dhcp[25953]: DHCPv4-derived
IPv6 names on 2001:470:6b99::, constructed for br0
Oct 6 09:18:12 Router daemon.info dnsmasq-dhcp[25953]: router
advertisement on 2001:470:6b99::, constructed for br0

Spot the difference 'cos I can't :-) Hopefully that's explained it better.

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

Re: [Dnsmasq-discuss] Clarification of prefix length field in dhcp-range

[Kevin Darbyshire-Bryant]

On 08/10/2013 11:42, Simon Kelley wrote:
>
> This is definitely a bug.
Sorry Simon!
>
> Historically, the prefix-length in the dhcp-range has had to match the
> prefix length configured into the interface. This was carried over
> from DHCPv4. If, as an experiment, you stop using constructed ranges
> and just configure the whole address in the dhcp-range, you'll find
> the same effect. If the  prefix length in the range is 64 (it can't be
> smaller) and the prefix length in the interface is 48 then things
> will break in the same way: no DHCPv6 and no RA.
I tried exactly that and found exactly the same behaviour but then got
diverted into my paid work before I could update you.
>
> To add insult to injury, the code which "contructs" DHCP ranges
> doesn't check the prefix length. It will happy construct a DHCP range
> based on an address configured into an interface, even if the
> prefix-length of that address is smaller. The constructed dhcp-range
> has its prefix length copied from the template, so it's useless for
> actually doing DHCPv6 or RA.
>
> To make things consistent, the constructor code should not contruct
> dhcp-ranges unless the prefix lengths match.
>
> It's also at least arguable that the RA and DHCP code should not
> insist on the prefix lengths being the same: as you say, a
> prefix-length on the interface less-then or equal to the one in the
> dhcp-range would make some sense. One has to be careful though: which
> of the two prefix ranges should actually be advertised in the Router
> Advertisements?
>
Well speaking from a purely selfish point of view, and wanting to do the
least amount of work in terms of integration with 'Tomato', I'd like it
to construct, RA & DHCPv6 the /64 and ignore the fact that the interface
is configured with a /48.  ie. take note of the ',64' parameter in the
dhcp-range.

You have a much, much better idea of how this IPv6 stuff is supposed to
work than me so my idea is probably pants!

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] gatway

[Kevin Darbyshire-Bryant]

On 08/10/2013 12:09, Vladislav Grishenko wrote:


> Since RA can be very frequent, is it ever worth to log with LOG_INFO
> level every unsolicited RTR-ADVERT? It just floods syslog and has no
> other meaning in my opinion. Best Regards, Vladislav Grishenko
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 

That's exactly why in the 'Tomato' version of dnsmasq I added 3 extra
options, 'quiet-ra, quiet-dhcp, quiet-dhcp6' to suppress logging. 
Though I have to say whatever recent changes have been made, either to
dnsmasq or apple ios 7, dhcp6 activity appears much reduced which is
great news!

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] Bug in dhcpv4 quiet-dhcp option

[Kevin Darbyshire-Bryant]

Hi Simon,



I think there's a bug in the quiet-dhcp option.  In essence no dhcpv4 logging 
is performed unless the log option is also enabled.  I think the code should be:



diff --git a/src/rfc2131.c b/src/rfc2131.c
index 0ee7c90..dd67509 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -1543,7 +1543,7 @@ static void log_packet(char *type, void *addr, unsigned ch
   struct in_addr a;


-  if (!err && (!option_bool(OPT_LOG_OPTS) || option_bool(OPT_QUIET_DHCP)))
+  if (!err && !option_bool(OPT_LOG_OPTS) && option_bool(OPT_QUIET_DHCP))
 return;

   /* addr may be misaligned */
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks

[Kevin Darbyshire-Bryant]

On 24/10/2013 17:03, Brian Rak wrote:
> We've recently undertaken a project to clean up our network, and lock
> down all the open DNS resolvers.  As you may know, these are very
> frequently used for DDOS attacks: http://openresolverproject.org/ ,
> http://www.team-cymru.org/Services/Resolvers/ .
>
> I haven't been able to find any sort of configuration option that
> would prevent DNSMasq from being abused like this, and I've had to
> resort to iptables rules instead.  Is there a configuration option
> that that would disable responding to DNS queries from certain
> interfaces?  The other option that seems handy would be one to only
> reply to DNS queries from hosts that have a configured DHCP lease.
>
> Are there any features of DNSMasq that would prevent it from being
> abused to conduct attacks?
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

I instantly thought of the '-interface' & '-except-interface' options. 
I'm probably missing something.

-- 
Cheers,

ke...@darbyshire-bryant.me.uk {TB}
M: +44 7947 355344 H: +44 1256 478597




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] dnsmasq 2.62-3 as DHCPv6-Server and RA-Server: Bug sending router's link-local instead of global address as gateway and DNS-server?

[Kevin Darbyshire-Bryant]

On 21/01/2014 10:40, Martin Babutzka wrote:
> Hello,
>  
> We are using this great piece of software so far as DNS cacher but
> want to implement it also as IPv6 server by now. DHCPv4 is handled by
> another software at the moment (isc-dhcp-server) but we think the
> dnsmasq 2.62-3 is quite suitable for our need of an DHCPv6- and
> RA-server.
>  
> I activated the features in dnsmasq.conf which I think should set-up a
> working DHCPv6/RA-Server (see compressed config file below). From then
> on the server distributed ipv6-addresses from the correct range.
> Unfortunately some error occured: As wanted it also distributed
> Gateway and DNS-server but it used the LINK-LOCAL v6 address of the
> corresponding interface instead of the Global configured address
> (2010:7d0:904:1202::1). Is this a bug or misconfiguration?
>  
> Another independent question: With this configuration dnsmasq starts
> to be pretty noisy in the syslog. Is there any option to reduce the
> verbosity once the system works?
>  
v2.68 includes 'quiet-dhcp, quiet-dhcp6 & quiet-ra' options which
significantly help the syslog noise.

I think it's correct behaviour to advertise the link-local address.

Hope that helps.

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] Interface based DNS names

[Kevin Darbyshire-Bryant]

Localise-queries option as well I think. 

--
Cheers,

ke...@darbyshire-bryant.me.uk {PH}
Sent from my phone, apologies for brevity & spelling.

> On 21 Feb 2014, at 05:30, "Mike O'Connor"  wrote:
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi klondike
>> On 21/02/2014 3:29 pm, klondike wrote:
>> 
>> In an ideal world, it would be possible to tune the reply depending on
>> the network the request came from to avoid unnecessary routing accross
>> VLANs, for example if a request is sent for router.lan from the
>> 10.10.0.0/16 network the reply would be 10.10.0.1 but if it is sent from
>> 10.60.0.0/16 the reply would be 10.60.0.1 this would provide the
>> possibility of having the servers listening on trunk lines with tagged
>> VLANs on the switch so routing would be unnecessary to access them.
> If you use 802.1q vlan and bring the these directly to the router
> (running dnsmasq) and assign the two different networks to the
> interfaces, dnsmasq will just do this correctly.
> 
> 
> dhcp-range=10.10.0.1,10.10.255.254,4h
> dhcp-range=10.60.0.1,10.60.255.254,4h
> 
> These lines will just find the correct interface and supply the correct
> DHCP records.
> 
> Mike
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlMG5AEACgkQfgQf7OYYFPWnlACgsl08zXLGtFZq4g/zxbJA6n4o
> 57IAniMZbV1Lea8527OxMQcpyu0LwNn0
> =AWom
> -END PGP SIGNATURE-
> 
> 
> ___
> 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] dnsmasq using 100% cpu on router

[Kevin Darbyshire-Bryant]

On 24/04/2014 20:49, Simon Kelley wrote:
> On 24/04/14 20:41, David Joslin wrote:
>> Thanks for the reply, Simon.
>>
>> DNSSEC isn't enabled.
>>
>> I wonder if the pattern of the problem gives any clues...
>>
>> As I said, on a normal day with around 40-50 clients on the network there
>> is no problem at all with dnsmasq managing to use barely 0 - 2% of the CPU.
>> When the problem occurred there were a little over 100 clients. Running top
>> showed dnsmasq using 100% cpu so I restarted dnsmasq and kept an eye on
>> top. For maybe 5 or 10 minutes there was no problem, with dnsmasq using
>> very little cpu. Then dnsmasq would start to peak at maybe 20-30% for a
>> couple of seconds before dropping back. Then it would start peaking at
>> higher and higher levels before dropping back. Eventually, after running
>> for maybe half an hour it would start peaking at over 90% and staying there
>> for longer before dropping back. At this point dns requests would become
>> very slow (and maybe time out). And then dnsmasq would hit 100% cpu and
>> would stay there. Dns requests would time out and only restarting dnsmasq
>> would fix the problem. The pattern would then start over again.
>>
>> I may be wrong but it doesn't seem that dnsmasq is hitting a bug that
>> suddenly causes it to loop and hog the cpu until it's killed. It seems to
>> gradually show more and more of the problem before it eventually hogs 100%
>> cpu and has to be killed.
>>
>> If the problem was caused by dnsmasq being overloaded with requests, is it
>> likely or possible that 50 clients could put very little load on it but 100
>> clients could swamp it? Also, would the problem not show itself as soon as
>> dnsmasq was restarted rather than showing the gradual increase in peak
>> usage until it hits 100%?
>
> Logs would help. The pattern doesn't look familiar, but if I had to
> guess, I'd say that the problem is DHCP, not DNS. Every change to the
> DHCP lease database causes the file storing it to be re-written, and I
> suspect that's what's eating CPU, in disk wait.
>
> Version of dnsmasq in use would be useful, and a copy of your config (to
> me privately, if you prefer.)
>
> When dnsmasq is running at 100%, try running
>
> strace -p 
>
> that will run forever, printing what syscalls are being made, you can
> ctrl-c it after a show while, which will stop strace, but not dnsmasq.
>
>
> Cheers,
>
>
> Simon
>
>

Chaps,

Please be aware that the dnsmasq included in tomato is not a clean
'pull' out of Simon's release but includes some tweaks, mainly to the
lease writing code (where it outputs 'remaining leasetime' rather than
expiry time)  There's also a 'helper' function that upon receipt of
SIGUSR1 (or it may be 2 I can't remember) dumps the leasefile in a
tomato specific format so that it may be read & parsed into the 'dhcp
status' page.

Those changes were 'formalised' by me into IFDEF conditional compilation
flags when I first investigated updating dnsmasq from v2.61 to something
slightly newer which fixed the IPv6 RA flags.  The original changes by
Jon Zarate were identified and re-inserted after a few false starts.  I
am no 'C' coder!

My suggestion for a start are to upgrade to dnsmasq 2.70 rather than a
test release of 2.69.  Also try changing the location of the leasefile
to somewhere else e.g. a USB stick if your router supports it.

I've not encountered anything like this but then I don't have 100 clients.

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] dnsmasq using 100% cpu on router

[Kevin Darbyshire-Bryant]

On 25/04/2014 09:37, David Joslin wrote:
> Hi Kevin and thanks for the help.
>
Apologies for delay in reply.
> Is it possible to upgrade the dnsmasq version on the router without
> waiting for the author of the tomato firmware to include a later
> version in a release of his firmware (and you mentioned that dnsmasq
> in tomato isn't a clean pull of Simon's release)?
Probably, but as you'd have to cross compile it to MIPS and 'Tomato'
environment you might as well try to rebuild the entire firmware.  I
loosely 'maintain' a shadow of Simon's git repo of dnsmasq with the
Tomato/Asuswrt tweaks here
https://github.com/kdarbyshirebryant/dnsmasq   - No guarantees etc etc,
but I personally try to keep up to date with both 'Merlin's
Asuswrt/rmerlin and put current dnsmasq in there too.
>
> Why would changing the location of the leasefile to a usb stick make a
> difference? If the issue, as Simon suggests, is caused by the constant
> rewriting of the lease database, then wouldn't its current location
> (which on a router would be RAM) be a faster/better option than a usb
> stick? Or is there another possible issue here that I've missed?
Agree, RAM should be faster but there is a finite amount of it and it's
volatile...I quite like to store the database on something that survives
reboots.  Also, as tomato is compiled with 'no rtc', the code tries to
minimise the number of writes to the leasefile on the basis it thinks it
likely that flash memory is involved, so better to reduce the wear.
>
> The only recent change I've made to the router was the addition of a
> usb stick as the location for the writing of system logs and bandwidth
> and IP traffic usage logs (so that they weren't lost on a reboot). I
> had wondered if the cause of the problem was related to the speed of
> writing this stuff (which obviously includes dnsmasq logging) to the
> usb stick rather than RAM. That's why I turned off dnsmasq logging at
> one point but it didn't seem to make any difference.
>
> Thanks again for your help and I'll wait for your comments on the above.
I'm not sure I've helped really.

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] Inotify code & older linux

[Kevin Darbyshire-Bryant]

Hi Simon

I'm wondering if you'd consider putting the new 'inotify' related code
as a compile time option please.  Unfortunately there are a few router
based projects that rely on old kernels without inotify support.  I've
included a patch that I've hopefully generated & coded correctly that
wraps the inotify related code into 'HAVE_INOTIFY' blocks.  It probably
requires some sanity checking on my behalf.  Thanks for your time.

Kevin

diff --git a/src/config.h b/src/config.h
index aa0c21f..831c537 100644
--- a/src/config.h
+++ b/src/config.h
@@ -119,6 +119,8 @@ HAVE_DNSSEC
 HAVE_LOOP
include functionality to probe for and remove DNS forwarding loops.
 
+HAVE_INOTIFY
+   use inotify instead of polling on linux
 
 NO_IPV6
 NO_TFTP
@@ -161,6 +163,7 @@ RESOLVFILE
 #define HAVE_AUTH
 #define HAVE_IPSET
 #define HAVE_LOOP
+#define HAVE_INOTIFY
 
 /* Build options which require external libraries.
   
@@ -363,6 +366,10 @@ HAVE_SOCKADDR_SA_LEN
 #define HAVE_LEASEFILE_EXPIRE
 #endif
 
+#if defined(NO_INOTIFY) || !defined(HAVE_LINUX_NETWORK)
+#undef HAVE_INOTIFY
+#endif
+
 /* Define a string indicating which options are in use.
DNSMASQP_COMPILE_OPTS is only defined in dnsmasq.c */
 
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 127ef8d..73e3139 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -359,7 +359,7 @@ int main (int argc, char **argv)
 #endif
 }
 
-#ifdef HAVE_LINUX_NETWORK
+#ifdef HAVE_INOTIFY
   if ((!option_bool(OPT_NO_POLL) && daemon->port != 0) ||
   daemon->dhcp || daemon->doing_dhcp6)
 inotify_dnsmasq_init();
@@ -909,11 +909,13 @@ int main (int argc, char **argv)
 #if defined(HAVE_LINUX_NETWORK)
   FD_SET(daemon->netlinkfd, &rset);
   bump_maxfd(daemon->netlinkfd, &maxfd);
+#ifdef HAVE_INOTIFY
   if (daemon->inotifyfd != -1)
 {
   FD_SET(daemon->inotifyfd, &rset);
   bump_maxfd(daemon->inotifyfd, &maxfd);
 }
+#endif
 #elif defined(HAVE_BSD_NETWORK)
   FD_SET(daemon->routefd, &rset);
   bump_maxfd(daemon->routefd, &maxfd);
@@ -981,8 +983,8 @@ int main (int argc, char **argv)
 route_sock();
 #endif
 
-#ifdef HAVE_LINUX_NETWORK
-  if  (daemon->inotifyfd != -1 && FD_ISSET(daemon->inotifyfd,
&rset) && inotify_check(now))
+#ifdef HAVE_INOTIFY
+  if  (daemon->inotifyfd != -1 && FD_ISSET(daemon->inotifyfd, &rset) &&
inotify_check(now))
 {
   if (daemon->port != 0 && !option_bool(OPT_NO_POLL))
 poll_resolv(1, 1, now);
@@ -1003,6 +1005,7 @@ int main (int argc, char **argv)
  
   if (FD_ISSET(piperead, &rset))
 async_event(piperead, now);
+#endif
  
 #ifdef HAVE_DBUS
   /* if we didn't create a DBus connection, retry now. */
@@ -1446,7 +1449,7 @@ void clear_cache_and_reload(time_t now)
   if (option_bool(OPT_ETHERS))
 dhcp_read_ethers();
   reread_dhcp();
-#ifdef HAVE_LINUX_NETWORK
+#ifdef HAVE_INOTIFY
   set_dhcp_inotify();
 #endif
   dhcp_update_configs(daemon->dhcp_conf);
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index bbda8ff..2755fc5 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -554,7 +554,7 @@ struct hostsfile {
   struct hostsfile *next;
   int flags;
   char *fname;
-#ifdef HAVE_LINUX_NETWORK
+#ifdef HAVE_INOTIFY
   int wd; /* inotify watch descriptor */
 #endif
   unsigned int index; /* matches to cache entries for logging */
@@ -1011,6 +1011,9 @@ extern struct daemon {
   int dhcpfd, helperfd, pxefd;
 #if defined(HAVE_LINUX_NETWORK)
   int netlinkfd;
+#if defined(HAVE_INOTIFY)
+  int inotifyfd;
+#endif
 #elif defined(HAVE_BSD_NETWORK)
   int dhcp_raw_fd, dhcp_icmp_fd, routefd;
 #endif
@@ -1492,7 +1495,7 @@ int detect_loop(char *query, int type);
 #endif
 
 /* inotify.c */
-#ifdef HAVE_LINUX_NETWORK
+#ifdef HAVE_INOTIFY
 void inotify_dnsmasq_init();
 int inotify_check(time_t now);
 #  ifdef HAVE_DHCP
diff --git a/src/inotify.c b/src/inotify.c
index 52a30d7..818fe8e 100644
--- a/src/inotify.c
+++ b/src/inotify.c
@@ -15,7 +15,7 @@
 */
 
 #include "dnsmasq.h"
-#ifdef HAVE_LINUX_NETWORK
+#ifdef HAVE_INOTIFY
 
 #include 
 
@@ -216,5 +216,5 @@ static void check_for_dhcp_inotify(struct
inotify_event *in, time_t now)
 
 #endif /* DHCP */
 
-#endif  /* LINUX_NETWORK */
+#endif  /* INOTIFY */
  








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] Inotify code & older linux

[Kevin Darbyshire-Bryant]

On 23/01/2015 14:07, Simon Kelley wrote:
> Yes, that's fine. It'll be a couple of days before I have time to do
> the work.
>
>
> Cheers,
>
> Simon.
>
> On 22/01/15 09:09, Kevin Darbyshire-Bryant wrote:
> > Hi Simon
>
> > I'm wondering if you'd consider putting the new 'inotify' related
> > code as a compile time option please.  Unfortunately there are a
> > few router based projects that rely on old kernels without inotify
> > support.  I've included a patch that I've hopefully generated &
> > coded correctly that wraps the inotify related code into
> > 'HAVE_INOTIFY' blocks.  It probably requires some sanity checking
> > on my behalf.  Thanks for your time.
>
> > Kevin

I've been reminded to point out that the patch posted is strongly based
on a tweak that Asus did to dnsmasq in a recent release of Asuswrt and
"is not mine".

By my 'hopefully generated' comment I was trying to indicate my newbie
status with regard to 'git diff' and patching in general.  I probably
went a bit far in saying 'coded' however things were adjusted to fit
with changes implemented between Asus' version of dnsmasq and the latest
dnsmasq git.  It wasn't quite a git 'auto merge'.  This is also why I
say it needs some sanity checking because the changes I made may be
wrong and indeed there may be better ways to implement what Asus did.

My intention was that these changes could be spread to the wider dnsmasq
using community rather than be lost or kept 'private' to certain
distributions.

Apologies to all those offended,

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] Inotify code & older linux

[Kevin Darbyshire-Bryant]

On 22/01/2015 09:09, Kevin Darbyshire-Bryant wrote:

In addition:  include the inotify build status as part of the version
string:

diff --git a/src/config.h b/src/config.h
index cdca231..eaa0423 100644
--- a/src/config.h
+++ b/src/config.h
@@ -425,6 +425,10 @@ static char *compile_opts =
 "no-"
 #endif
 "DNSSEC "
+#ifndef HAVE_INOTIFY
+"no-"
+#endif
+"inotify "
 #ifndef HAVE_LOOP
 "no-"
 #endif


Hope that helps.

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] Inotify code & older linux

[Kevin Darbyshire-Bryant]

On 26/01/2015 11:29, Simon Kelley wrote:
> No offence taken. I tweaked the patches and pushed the changes into git.
>
> Cheers,
>
> Simon.

Thank you.  Much appreciated.

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] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

Hi Simon,

I've no idea how to go about coding this but I've an idea/requirement
for something along these lines.  It's similar to 'dnssec-no-timecheck'
chicken & egg but a bit more automated.

1) Set a 'check signature time' flag as false.
2) If flag is false, then check the current time of day.  If time of day
is greater than some provided value, say 'year 2015' then set 'check
time signature' as true and now check DNSSEC signature times.

The above assumes that for those devices that don't support a RTC that
they'll default to a time 'much in the past', therefore anything greater
it is 'assumed' that the time has been set correctly via ntp and that
signature checking should go ahead.  To my mind this makes handling
restarting dnsmasq in embedded environments much easier as no
'-SIGHUP'age required, along with the intelligence to automatically
sighup after a brief period of time on a restart.

Thoughts?  Am I talking out of my backside (again)?

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] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

Further to my previous email I've cobbled something together, and it
even appears to work.  There's quite a bit of coding guesswork going on
here and I really shouldn't be let anywhere near a C compiler.  Either
way a new option '-dnssec_tvalid=integer' where integer is number of
seconds since 1970 (epoch)  is implemented.  If current system clock
exceeds this time then dnssec timestamps will be checked, until that
time they are not.

Kevin


diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 40323ed..1687305 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -239,7 +239,8 @@ struct event_desc {
 #define OPT_LOCAL_SERVICE  49
 #define OPT_LOOP_DETECT50
 #define OPT_EXTRALOG   51
-#define OPT_LAST   52
+#define OPT_DNSSEC_TVALID  52
+#define OPT_LAST   53
 
 /* extra flags for my_syslog, we use a couple of facilities since they
are known
not to occupy the same bits as priorities, no matter how syslog.h is
set up. */
@@ -986,6 +987,7 @@ extern struct daemon {
 #endif
 #ifdef HAVE_DNSSEC
   struct ds_config *ds;
+  time_t dnssec_tvalid;
 #endif
 
   /* globally used stuff for DNS */
diff --git a/src/dnssec.c b/src/dnssec.c
index 2693237..3a350c0 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -401,9 +401,15 @@ static int check_date_range(unsigned long
date_start, unsigned long date_end)
 
   /* Checking timestamps may be temporarily disabled */
   if (option_bool(OPT_DNSSEC_TIME))
-return 1;
- 
-  curtime = time(0);
+ if (daemon->dnssec_tvalid) {   
+curtime = time(0);
+if (curtime > daemon->dnssec_tvalid) {
+   reset_option_bool(OPT_DNSSEC_TIME);
+   my_syslog(LOG_INFO, _("time is valid. Now checking DNSSEC
signature timestamps"));
+}
+ }
+ else return 1;
+  else curtime = time(0);
  
   /* We must explicitly check against wanted values, because of
SERIAL_UNDEF */
   return serial_compare_32(curtime, date_start) == SERIAL_GT
diff --git a/src/option.c b/src/option.c
index e4b4865..20bec3c 100644
--- a/src/option.c
+++ b/src/option.c
@@ -152,6 +152,7 @@ struct myoption {
 #define LOPT_DHCP_INOTIFY  340
 #define LOPT_DHOPT_INOTIFY 341
 #define LOPT_HOST_INOTIFY  342
+#define LOPT_DNSSEC_TVALID 343
 
 #ifdef HAVE_GETOPT_LONG
 static const struct option opts[] = 
@@ -309,6 +310,7 @@ static const struct myoption opts[] =
 { "quiet-dhcp6", 0, 0, LOPT_QUIET_DHCP6 },
 { "quiet-ra", 0, 0, LOPT_QUIET_RA },
 { "dns-loop-detect", 0, 0, LOPT_LOOP_DETECT },
+{ "dnssec-tvalid", 1, 0, LOPT_DNSSEC_TVALID },
 { NULL, 0, 0, 0 }
   };
 
@@ -463,6 +465,7 @@ static struct {
   { LOPT_DNSSEC_DEBUG, OPT_DNSSEC_DEBUG, NULL, gettext_noop("Disable
upstream checking for DNSSEC debugging."), NULL },
   { LOPT_DNSSEC_CHECK, OPT_DNSSEC_NO_SIGN, NULL, gettext_noop("Ensure
answers without DNSSEC are in unsigned zones."), NULL },
   { LOPT_DNSSEC_TIME, OPT_DNSSEC_TIME, NULL, gettext_noop("Don't check
DNSSEC signature timestamps until first cache-reload"), NULL },
+  { LOPT_DNSSEC_TVALID, ARG_ONE, "=seconds since epoch",
gettext_noop("Don't check DNSSEC signature timestamps until time exceeds
given time since epoch"), NULL },
 #ifdef OPTION6_PREFIX_CLASS
   { LOPT_PREF_CLSS, ARG_DUP, "set:tag,", gettext_noop("Specify
DHCPv6 prefix class"), NULL },
 #endif
@@ -2463,6 +2466,23 @@ static int one_opt(int option, char *arg, char
*errstr, char *gen_err, int comma
 daemon->max_logs = 100;
   break; 
 
+#ifdef HAVE_DNSSEC
+case LOPT_DNSSEC_TIME:
+  {
+daemon->dnssec_tvalid = 0; /* default */
+break;
+  }
+case LOPT_DNSSEC_TVALID:  /* --log-async */
+  {
+int tvalid;
+if (!atoi_check(arg, &tvalid))
+  ret_err(gen_err);
+set_option_bool(OPT_DNSSEC_TIME);
+daemon->dnssec_tvalid = (time_t)tvalid;
+break; 
+  }
+#endif
+
 case 'P': /* --edns-packet-max */
   {
 int i;






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] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

Sorry, I told you I shouldn't be let anywhere near a C compiler.  Here's
a patch that actually works!  (previously missing a return in dnssec.c)

diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 40323ed..1687305 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -239,7 +239,8 @@ struct event_desc {
 #define OPT_LOCAL_SERVICE  49
 #define OPT_LOOP_DETECT50
 #define OPT_EXTRALOG   51
-#define OPT_LAST   52
+#define OPT_DNSSEC_TVALID  52
+#define OPT_LAST   53
 
 /* extra flags for my_syslog, we use a couple of facilities since they
are known
not to occupy the same bits as priorities, no matter how syslog.h is
set up. */
@@ -986,6 +987,7 @@ extern struct daemon {
 #endif
 #ifdef HAVE_DNSSEC
   struct ds_config *ds;
+  time_t dnssec_tvalid;
 #endif
 
   /* globally used stuff for DNS */
diff --git a/src/dnssec.c b/src/dnssec.c
index 2693237..137f350 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -401,9 +401,16 @@ static int check_date_range(unsigned long
date_start, unsigned long date_end)
 
   /* Checking timestamps may be temporarily disabled */
   if (option_bool(OPT_DNSSEC_TIME))
-return 1;
- 
-  curtime = time(0);
+ if (daemon->dnssec_tvalid) {   
+curtime = time(0);
+if (curtime > daemon->dnssec_tvalid) {
+   reset_option_bool(OPT_DNSSEC_TIME);
+   my_syslog(LOG_INFO, _("time is valid. Now checking DNSSEC
signature timestamps"));
+}
+else return 1;
+ }
+ else return 1;
+  else curtime = time(0);
  
   /* We must explicitly check against wanted values, because of
SERIAL_UNDEF */
   return serial_compare_32(curtime, date_start) == SERIAL_GT
diff --git a/src/option.c b/src/option.c
index e4b4865..20bec3c 100644
--- a/src/option.c
+++ b/src/option.c
@@ -152,6 +152,7 @@ struct myoption {
 #define LOPT_DHCP_INOTIFY  340
 #define LOPT_DHOPT_INOTIFY 341
 #define LOPT_HOST_INOTIFY  342
+#define LOPT_DNSSEC_TVALID 343
 
 #ifdef HAVE_GETOPT_LONG
 static const struct option opts[] = 
@@ -309,6 +310,7 @@ static const struct myoption opts[] =
 { "quiet-dhcp6", 0, 0, LOPT_QUIET_DHCP6 },
 { "quiet-ra", 0, 0, LOPT_QUIET_RA },
 { "dns-loop-detect", 0, 0, LOPT_LOOP_DETECT },
+{ "dnssec-tvalid", 1, 0, LOPT_DNSSEC_TVALID },
 { NULL, 0, 0, 0 }
   };
 
@@ -463,6 +465,7 @@ static struct {
   { LOPT_DNSSEC_DEBUG, OPT_DNSSEC_DEBUG, NULL, gettext_noop("Disable
upstream checking for DNSSEC debugging."), NULL },
   { LOPT_DNSSEC_CHECK, OPT_DNSSEC_NO_SIGN, NULL, gettext_noop("Ensure
answers without DNSSEC are in unsigned zones."), NULL },
   { LOPT_DNSSEC_TIME, OPT_DNSSEC_TIME, NULL, gettext_noop("Don't check
DNSSEC signature timestamps until first cache-reload"), NULL },
+  { LOPT_DNSSEC_TVALID, ARG_ONE, "=seconds since epoch",
gettext_noop("Don't check DNSSEC signature timestamps until time exceeds
given time since epoch"), NULL },
 #ifdef OPTION6_PREFIX_CLASS
   { LOPT_PREF_CLSS, ARG_DUP, "set:tag,", gettext_noop("Specify
DHCPv6 prefix class"), NULL },
 #endif
@@ -2463,6 +2466,23 @@ static int one_opt(int option, char *arg, char
*errstr, char *gen_err, int comma
 daemon->max_logs = 100;
   break; 
 
+#ifdef HAVE_DNSSEC
+case LOPT_DNSSEC_TIME:
+  {
+daemon->dnssec_tvalid = 0; /* default */
+break;
+  }
+case LOPT_DNSSEC_TVALID:  /* --log-async */
+  {
+int tvalid;
+if (!atoi_check(arg, &tvalid))
+  ret_err(gen_err);
+set_option_bool(OPT_DNSSEC_TIME);
+daemon->dnssec_tvalid = (time_t)tvalid;
+break; 
+  }
+#endif
+
 case 'P': /* --edns-packet-max */
   {
 int i;




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] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

On 09/02/2015 16:02, Simon Kelley wrote:
>
>
> On 09/02/15 13:21, Kevin Darbyshire-Bryant wrote:
> > Further to my previous email I've cobbled something together, and
> > it even appears to work.  There's quite a bit of coding guesswork
> > going on here and I really shouldn't be let anywhere near a C
> > compiler.  Either way a new option '-dnssec_tvalid=integer' where
> > integer is number of seconds since 1970 (epoch)  is implemented.
> > If current system clock exceeds this time then dnssec timestamps
> > will be checked, until that time they are not.
>
>
> Answering your previous mail as well, I like this as an idea.
>
> I think the original concept (date after an arbitrary, recent, time id
> better if the time really is arbitrary. Putting timestamps in the
> start-up infrastructure to pass to dnsmasq is a bit pointless: they
> won't be "better" than something compiled into dnsmasq, and they're a
> pain to generate (What's the command to spit out "now" in seconds
> since 1970?). A bit of makefile wizzardry could compile in "now" at
> build time, as another idea.
>
> However it occurs to me that many of the platforms we're talking about
> here don't have an RTC, but they _do_ have non-volatile storage. How
> about storing "now" to NVRAM every hour, and using _that_ as the time
> which must be superceded?
>
>
> The second path is well on the way, BTW, I'm happy to take it and bash
> it into shape, once we agree on exactly what's needed.
>
>
> Cheers,
>
> Simon.
>

Hi Simon,

Hmmm, it's a 'difficult' one.  Building 'now' in at compile time is
certainly an option but it does assume that the firmware won't at some
stage in the future and boot up to a time that's then valid by default. 
I was quite shocked to find the router I'm currently fiddling with
defaulted to December 2014!  And I get your point that even providing a
mechanism to pass a good 'valid' time is itself built into the
firmwareunless it's provided by an additional config file in stored
in NVRAM, which is the approach I've taken.  I do wholeheartedly agree
seconds since 1970 is arcane to say the least and a way to automate that
out has got to be a good idea :-)

I like the idea of storing "now" in 'nvram' somehow very much.   There
are a couple of thoughts on this, and I'm viewing this from an Asus
router 'asuswrt' perspective so may not be thinking of other platform
issues.  I've an NVRAM partition (using JFFS) which uses a spare portion
of flash memory as NVRAM.  Ideally you don't want to write to this too
often as it'll wear the flash out prematurely.  I don't know what the
dnssec signature validity granularity is but would a daily update really
be too infrequent?  Of course I can add a USB stick drive to the router
and use that (in fact I do) but this isn't a default option that say
Asus could put in, they'd have to point to JFFS by default.

My other thought relates to how this file gets created & initialised. 
My head is hurting trying to think this through but the case where the
file exists is the most straightforward (compare the time stored to
"now" and if "now" greater then the clock has hopefully been set and the
file should be updated)  I think a safeguard to creating the file in the
first place needs implementing, in essence something like seeing a
significant time jump forward (say a day) which indicates a clock set
operation.  Fundamentally the idea of passing an option to a timestamp
file along with an update interval is really good. 

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] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

> On 11 Feb 2015, at 22:02, Simon Kelley  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
>> On 09/02/15 18:28, Kevin Darbyshire-Bryant wrote:
>>> On 09/02/2015 16:02, Simon Kelley wrote:
>>> 
>>> 
>>>> On 09/02/15 13:21, Kevin Darbyshire-Bryant wrote:
>>>> Further to my previous email I've cobbled something together,
>>>> and it even appears to work.  There's quite a bit of coding
>>>> guesswork going on here and I really shouldn't be let anywhere
>>>> near a C compiler.  Either way a new option
>>>> '-dnssec_tvalid=integer' where integer is number of seconds
>>>> since 1970 (epoch)  is implemented. If current system clock
>>>> exceeds this time then dnssec timestamps will be checked, until
>>>> that time they are not.
>>> 
>>> 
>>> Answering your previous mail as well, I like this as an idea.
>>> 
>>> I think the original concept (date after an arbitrary, recent,
>>> time id better if the time really is arbitrary. Putting
>>> timestamps in the start-up infrastructure to pass to dnsmasq is a
>>> bit pointless: they won't be "better" than something compiled
>>> into dnsmasq, and they're a pain to generate (What's the command
>>> to spit out "now" in seconds since 1970?). A bit of makefile
>>> wizzardry could compile in "now" at build time, as another idea.
>>> 
>>> However it occurs to me that many of the platforms we're talking
>>> about here don't have an RTC, but they _do_ have non-volatile
>>> storage. How about storing "now" to NVRAM every hour, and using
>>> _that_ as the time which must be superceded?
>>> 
>>> 
>>> The second path is well on the way, BTW, I'm happy to take it and
>>> bash it into shape, once we agree on exactly what's needed.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Simon.
>>> 
>> 
>> Hi Simon,
>> 
>> Hmmm, it's a 'difficult' one.  Building 'now' in at compile time
>> is certainly an option but it does assume that the firmware won't
>> at some stage in the future and boot up to a time that's then valid
>> by default. I was quite shocked to find the router I'm currently
>> fiddling with defaulted to December 2014!  And I get your point
>> that even providing a mechanism to pass a good 'valid' time is
>> itself built into the firmwareunless it's provided by an
>> additional config file in stored in NVRAM, which is the approach
>> I've taken.  I do wholeheartedly agree seconds since 1970 is arcane
>> to say the least and a way to automate that out has got to be a
>> good idea :-)
>> 
>> I like the idea of storing "now" in 'nvram' somehow very much.
>> There are a couple of thoughts on this, and I'm viewing this from
>> an Asus router 'asuswrt' perspective so may not be thinking of
>> other platform issues.  I've an NVRAM partition (using JFFS) which
>> uses a spare portion of flash memory as NVRAM.  Ideally you don't
>> want to write to this too often as it'll wear the flash out
>> prematurely.  I don't know what the dnssec signature validity
>> granularity is but would a daily update really be too infrequent?
>> Of course I can add a USB stick drive to the router and use that
>> (in fact I do) but this isn't a default option that say Asus could
>> put in, they'd have to point to JFFS by default.
>> 
>> My other thought relates to how this file gets created &
>> initialised. My head is hurting trying to think this through but
>> the case where the file exists is the most straightforward (compare
>> the time stored to "now" and if "now" greater then the clock has
>> hopefully been set and the file should be updated)  I think a
>> safeguard to creating the file in the first place needs
>> implementing, in essence something like seeing a significant time
>> jump forward (say a day) which indicates a clock set operation.
>> Fundamentally the idea of passing an option to a timestamp file
>> along with an update interval is really good.
>> 
>> Kevin
>> 
> 
> I think  we need to be careful to distinguish two different things here.
> 
> 
> There's the idea of saving a "last good time" in NVRAM so that we can
> sanity-check the kernel time, and not do time checks until i

Re: [Dnsmasq-discuss] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

> On 14 Feb 2015, at 14:47, Simon Kelley  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
>> On 12/02/15 12:01, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>>> The principle I agree with.  I'm wondering about the mechanics of
>>> accessing this NVRAM 'last good time'.  Is this something you're
>>> thinking that dnsmasq should access & maintain, in which case a
>>> file stored in a non-volatile filesystem would be the most 
>>> cross-platform method.  Or are you thinking the device OS should
>>> write a parameter into dnsmasq's config file at start (as I've 
>>> cobbled together) ?
>> 
>>> I have to say that I'd quite like dnsmasq to handle all the 
>>> timestamp related stuff so  dnssec could simply be a case of 
>>> throwing a switch and everything is handled automagically.  That
>>> might encourage home router manufacturers to include & enable by
>>> default. But what do I know!?
>> 
> 
>> 
>>> I'm not a fan of the 'proxy for now' idea for exactly the reasons
>>> you describe.  I think it better to wait for 'now' to really be
>>> after 'last good time', the implication is that NTP has done its
>>> stuff & sync'd the clock.  I would hope that NTP would be early
>>> on in the startup process so the exploit window narrow.
>> 
>> 
> 
> If the device will always have NVRAM available in the form of a
> filesystem, then using a time stamp on that is the obvious way to go.
> The only disadvantage I can see is that some devices may have NVRAM,
> but not be able to use it to store a filesystem. I don't have the
> knowledge to be able to have a strong opinion on that.

I don't really have that knowledge either, I've experience with Broadcom router 
platforms running the likes of Tomato and/or Asuswrt.  These have had jffs 
filesystems from very early days (and I've not yet encountered a situation 
where the NVRAM has worn out either). 

> 
> Assuming we have a fileysystem, then the following algorithm would
> seem to work.
> 
> On startup, if the timestamp on a NVRAM file is in the future, disable
> time checking for DNSSEC. The first time the timestamp goes into the
> past, enable timestamp checking henceforward, and reset the timestamp
> on the file to "now"
> 
> That leaves only the case where at startup, the file doesn't exist. I
> think creating it and setting its mtime to 01-01-2015, then running
> the rest of the algorithm, will probably do in that case.
> 
> Extending dnssec-no-timecheck, to take a pathname to enable this mode
> seems a reasonable idea.

Sounds excellent. Is it worth being really clever and setting the default time 
to build time rather than 01-01-2015?  As a further wear protection effort, 
only update mtime on the existing file if the difference exceeds 1 day?  This 
would limit the amount of writes on process start (Asuswrt restarts dnsmasq for 
the most bizarre reasons)

> 
> So
> 
> - --dnssec-no-timecheck
> 
> works as before, with SIGHUP
> 
> - --dnssec-no-timecheck=/path/to/nvfilesystem
> 
> invokes the new behaviour.
> 
> How's that sound?

Really good!

And really appreciate your time & consideration of this.

Kevin

> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJU32AYAAoJEBXN2mrhkTWi8VkQAImoX1tf0utktpqG7FIzFpI5
> YyqGseTFw+4PreofAatDTgKdpgqFPACUYfqoj+56Xbk2u4jUFoxfeUrSLQwQ9C75
> eXbvWynhul1omVZjB96yXDkpysxQ5yhajLk7cgmIYpX6HBOtng3TiAfUGRqUa7ny
> qTxo6Ap0Al3RKsilZCBTcw3/G5yJg/rQuQGsuL/66nLW/au5sORw2AP/K4EbRAID
> Iw4jjfAWc3I7TgPEc2AX6nxiaA0+B2Kl7Tw6VUnmjsEwAjhjNgIKEeDrlgwXxxih
> CvnnHT/GSA6Dxa7rqrhzZ3B5AQzfsrIxhZTqwU/hkibspBWwye/P1thLWV67pmlc
> /EKHQsRydqlCZL43Ji1hRVJlnycU26AzePi+u0EgdJ/ayt4hwZC78jiKRfGFrh4b
> 5BAR07qjO14ZlVmCUYeaS3eAi4OYtk017Pbosdhc6V5CsSn0rIyKJw4Ir2gfyFSl
> UvVbTFiSST0pp2cKJjYRZrgf/LfoGW/7Is21DcAZMn9LLGq8TTWt8ImA+cQWGg3f
> ItQqsgrKI/8J18ThcAJvZM2UyW119hSEy7iIpsaw1h2mB961X+q6GeW7tx47AuVy
> 9MpBfjNaS2LTaOClOceEFCLCtLpIlYL8WwnTnU+C4cVXp6dRyO/4B9SrSY2vD50i
> 3rPLTS626d2Zq0MnVYfk
> =96X2
> -END PGP SIGNATURE-


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] DHCP Request Flood

[Kevin Darbyshire-Bryant]

On 25/02/2015 09:14, Gavin Hill wrote:
> As a quick update, I tried changing 
>
> dhcp-range=192.168.1.1,192.168.1.99,static,48h
>
> to
>
> dhcp-range=192.168.1.1,192.168.1.99,static,infinite
>
> Things slowed down a little and I’m seeing fewer log entries, but it
> still doesn’t explain why the 48h entry didn’t seem to work.  I’m
> assuming 48h is a valid syntax?

My suggestion would be to put 'log-dhcp' in the dnsmasq config file and
see what these devices are asking for in terms of dhcp options.
Sometimes the clients are poorly written, sometimes they're just persist
in asking questions to which dnsmasq doesn't know the answer.

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] a little feedback on the new dnssec startup method in openwrt

[Kevin Darbyshire-Bryant]

Chaps,

If I may interject:


On 02/04/2015 22:21, Dave Taht wrote:
> On Thu, Apr 2, 2015 at 1:20 PM, Simon Kelley  wrote:
> On 02/04/15 19:41, Dave Taht wrote:
> >>> A) Not clear what happens if it tries to write it while the jffs
> >>> filesystem is still being cleaned
>
> Not sure I have anything sensible to add here.
>
> >>>
> >>> B)  the dnssec_timestamp file needs to go somewhere that can be
> >>> written by nobody.
>
> This is documented in the manpage entry.
>
> nobody is the default, but you most systems have a "dnsmasq" user and
> run with --user=dnsmasq

I've been fiddling/meddling with Openwrt & dnsmasq RC's the past week or
so.  I modded the openwrt package to create /etc/dnsmasq.d and the
dnsmasq init script to chown nobody:nogroup /etc/dnsmasq.d (as I can't
work out how to get the build scripts to change the owner at image build
time)   That directory is used to store a dnsmasq timestamp file and is
there specifically to survive reboots.otherwise the timestamp
mechanism is slightly pointless :-)There is a security issue in the
sense that 'nobody' can mess with the file if they so choose.  I
considered a dnsmasq user, but I wonder on further knock ons with regard
to 'luci' reading dhcp lease files and the like.

There's some new secure computing options coming in (yet to be enabled
by default AFAIK) that effectively partition the filesystems that each
process can see to a per process view.  That may go some way to negating
the need to create 'mr. dnsmasq' rather than keeping everything as
'nobody'.   I've yet to play with the secccomp option though I've done
my best to update the init script to be seccomp, timestamp &
customisable dhcp.leases aware  (sorry gone a bit openwrt there!)

Ideally 'luci' needs to have the all the dnssec options exposed
including the new timestamp file as a customisable location.

> > Well, if it is perpetually created in /tmp on boot, how does it detect
> > the time slew?
>
> > It seemed to me that writing it to flash closed a vulnerability during
> > a quick reboot cycle.

I've even considered stopping the 'sysfixtime' service as this has the
potential to confuse dnsmasq in the event it doesn't have the timestamp
file to reference.

Here's a plea/offer to the Openwrt aware people (John?):  I'm very new
to Openwrt and the past week has been quite a learning curve on the
build & packaging process.  I think I've probably logged an erroneous
ticket due to my lack of experience.  What I would say is that there is
a willing idiot here who would be glad to offer the tweaks & bits &
pieces I've done so far I do need a bit of help, asking the odd
idiot question or two to get me to a state where I can hopefully be more
help than a hindrance.

Maybe these will help: 



diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 9795d1a..46bc698 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -15,6 +15,7 @@ ADD_LOCAL_HOSTNAME=1
 CONFIGFILE="/var/etc/dnsmasq.conf"
 HOSTFILE="/tmp/hosts/dhcp"
 TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf"
+TIMESTAMPFILE="/etc/dnsmasq.d/dnsmasq.timestamp"
 
 xappend() {
local value="$1"
@@ -202,6 +203,7 @@ dnsmasq() {
 
config_get_bool dnssec "$cfg" dnssec 0
[ "$dnssec" -gt 0 ] && {
+   xappend "--dnssec-timestamp=$TIMESTAMPFILE"
xappend "--conf-file=$TRUSTANCHORSFILE"
xappend "--dnssec"
append_bool "$cfg" dnsseccheckunsigned
"--dnssec-check-unsigned"
@@ -554,10 +556,12 @@ start_service() {
 
procd_add_jail dnsmasq ubus log
procd_add_jail_mount $CONFIGFILE $TRUSTANCHORSFILE $HOSTFILE
/etc/passwd /dev/urandom /etc/dnsmasq.conf /tmp/dnsmasq.d
/tmp/resolv.conf.auto /etc/hosts
-   procd_add_jail_mount_rw /var/run/dnsmasq/ /tmp/dhcp.leases
+   procd_add_jail_mount_rw /var/run/dnsmasq/ $leasefile $TIMESTAMPFILE
   
procd_close_instance
 
+   chown nobody:nogroup /etc/dnsmasq.d
+
# before we can call xappend
mkdir -p /var/run/dnsmasq/
mkdir -p $(dirname $CONFIGFILE)
@@ -575,6 +579,9 @@ start_service() {
 
args=""
config_foreach dnsmasq dnsmasq
+
+   procd_add_jail_mount_rw $leasefile
+
config_foreach dhcp_host_add host
echo >> $CONFIGFILE
config_foreach dhcp_boot_add boot



diff --git a/package/network/services/dnsmasq/Makefile
b/package/network/services/dnsmasq/Makefile
index dcbb63a..597186a 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -8,17 +8,19 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
-PKG_VERSION:=2.72
-PKG_RELEASE:=4
+PKG_VERSION:=2.73rc3
+PKG_RELEASE:=1
 
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
-PKG_MD5SUM:=cf82f81cf09ad3d47612985012240483
+PKG_SOURCE:=$(PKG_NAME)-

Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Kevin Darbyshire-Bryant]

Continues to work here on my iPhone hiding behind openwrt cc trunk 
dnsmasq2.73rc7

Were I not on the iPhone I could do some dig'age :-)

--
Cheers,

ke...@darbyshire-bryant.me.uk
Sent from my phone, apologies for brevity, spelling & top posting

> On 6 May 2015, at 20:21, Dave Taht  wrote:
> 
> nslookup www.ietf.org fails again... it did not fail a few days ago.
> 
> chrome returns nxdomain
> 
> 
> -- 
> Dave Täht
> Open Networking needs **Open Source Hardware**
> 
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
> 
> ___
> 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] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Kevin Darbyshire-Bryant]

On 07/05/2015 13:54, Simon Kelley wrote:
> On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
>> Simon Kelley  writes:
>>
>>> It's difficult to see how that would work in practise for DNS. Take
>>> the Google-public-DNS example. It's clearly not sane for Google's
>>> servers to do PMTU on the address of every client, just to send one
>>> UDP packet, and caching PMTU for clients is going to get hard, fast.
>>> If the reply-size is bigger than the PMTU what happens anyway?
>>> Presumably a truncated response, to force fallback to TCP.
>> Well, IPv6 also mandates a minimum PMTU of 1280 bytes. So a source host
>> that doesn't do PMTU discovery should either limit itself to 1280 bytes
>> packets or fragment at the source. Routers are not going to do it. See
>> https://tools.ietf.org/html/rfc2460#section-5 :)
> But if they fragment, what size should they fragment to? I guess inthe
> absence of any information to the contrary, 1280 bytes. I wonder if the
> Google public DNS is failing to do that, or if it is, and the path to me
> is dropping fragments?
>
> Simon.

For me, a variable but persistent problem reported by the ICSI Netalyzer is one 
of "the
path between you and us doesn't handle fragmented IPv6 traffic properly".  
Another symptom
of this is, I know not if this is cause or effect, is that the ipv6 traceroute 
they run also doesn't
complete.

The behaviour between working or not can change for months at a time, which 
suggests
a core routing difference rather than any ipv4/v6 tunnel config change (I use 
Hurricane
Electric's free tunnelbroker service for IPv6 & have tried changing tunnel MTU)

Certainly my initial understanding of IPv6 was that 'it didn't do 
fragmentation', which isn't
quite true.  When I get some time at home alone with my router (!) I shall do a 
bit more
digging.  But mishandling of IPv6 fragments is going to cause hell for edns.

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] [PATCH] Update DNSSEC timestamp file on process TERM

[Kevin Darbyshire-Bryant]

Patch to update the DNSSEC timestamp file upon receipt of
SIGTERM.  Helps to ensure the last known good time is noted
at system shutdown.

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/dnsmasq.c |  9 +
 src/dnsmasq.h |  1 +
 src/dnssec.c  | 11 +--
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 514e10b..04d5758 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1321,6 +1321,15 @@ static void async_event(int pipe, time_t now)
if (daemon->lease_stream)
  fclose(daemon->lease_stream);
 
+#ifdef HAVE_DNSSEC
+   /* update timestamp file on TERM if time is considered valid */
+   if (daemon->back_to_the_future)
+ {
+if (utime(daemon->timestamp_file, NULL) == -1)
+   my_syslog(LOG_ERR, _("failed to update mtime on %s: %s"), 
daemon->timestamp_file, strerror(errno));
+ }
+#endif
+
if (daemon->runfile)
  unlink(daemon->runfile);

diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index de146c6..e4035db 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 back_to_the_future;
   char *timestamp_file;
 #endif
 
diff --git a/src/dnssec.c b/src/dnssec.c
index 39b6b51..f1adc93 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -427,13 +427,12 @@ static int serial_compare_32(unsigned long s1, unsigned 
long s2)
 */
 
 static time_t timestamp_time;
-static int back_to_the_future;
 
 int setup_timestamp(void)
 {
   struct stat statbuf;
   
-  back_to_the_future = 0;
+  daemon->back_to_the_future = 0;
   
   if (!daemon->timestamp_file)
 return 0;
@@ -447,7 +446,7 @@ int setup_timestamp(void)
  /* time already OK, update timestamp, and do key checking from the 
start. */
  if (utime(daemon->timestamp_file, NULL) == -1)
my_syslog(LOG_ERR, _("failed to update mtime on %s: %s"), 
daemon->timestamp_file, strerror(errno));
- back_to_the_future = 1;
+ daemon->back_to_the_future = 1;
  return 0;
}
   return 1;
@@ -487,17 +486,17 @@ static int check_date_range(unsigned long date_start, 
unsigned long date_end)
  and start checking keys */
   if (daemon->timestamp_file)
 {
-  if (back_to_the_future == 0 && difftime(timestamp_time, curtime) <= 0)
+  if (daemon->back_to_the_future == 0 && difftime(timestamp_time, curtime) 
<= 0)
{
  if (utime(daemon->timestamp_file, NULL) != 0)
my_syslog(LOG_ERR, _("failed to update mtime on %s: %s"), 
daemon->timestamp_file, strerror(errno));
  
- back_to_the_future = 1;   
+ daemon->back_to_the_future = 1;
  set_option_bool(OPT_DNSSEC_TIME);
  queue_event(EVENT_RELOAD); /* purge cache */
} 
 
-  if (back_to_the_future == 0)
+  if (daemon->back_to_the_future == 0)
return 1;
 }
   else if (option_bool(OPT_DNSSEC_TIME))
-- 
1.9.1


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

[Dnsmasq-discuss] fe80/10 link local dns forwarding

[Kevin Darbyshire-Bryant]

Hi All,

After enabling dnsmasq's dns logging the other day I was a little
surprised to see queries for fe80:: being forwarded to my ISP's
resolvers.  I'd say that they're extremely unlikely to know anything
about my link local stuff so as a solution I've added the following to
my config:

server=/8.e.f.ip6.arpa/

What don't I understand here?  Awaiting education :-)

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] fe80/10 link local dns forwarding

[Kevin Darbyshire-Bryant]

Ahh, excellent!  Very helpful Vladislav.  Looks like a have a few more
zones to not leak to the Internet :-)

Thanks,

Kevin

On 07/09/2015 15:54, Vladislav Grishenko wrote:
> Hi Kevin,
>
> There's RFC 6303 for that, current status is best current practice.
> As for dnsmasq implementation of that recommendations, it could depend on 
> auth support, since it enables zone support.
>
> Best Regards, Vladislav Grishenko
>
>> -Original Message-
>> From: Dnsmasq-discuss [mailto:dnsmasq-discuss-
>> boun...@lists.thekelleys.org.uk] On Behalf Of Kevin Darbyshire-Bryant
>> Sent: Monday, September 07, 2015 6:28 PM
>> To: dnsmasq-discuss@lists.thekelleys.org.uk
>> Subject: [Dnsmasq-discuss] fe80/10 link local dns forwarding
>>
>> Hi All,
>>
>> After enabling dnsmasq's dns logging the other day I was a little surprised 
>> to
>> see queries for fe80:: being forwarded to my ISP's resolvers.  I'd say that
>> they're extremely unlikely to know anything about my link local stuff so as a
>> solution I've added the following to my config:
>>
>> server=/8.e.f.ip6.arpa/
>>
>> What don't I understand here?  Awaiting education :-)
>>
>> Kevin
>

-- 
Thanks,

ke...@darbyshire-bryant.me.uk
M: +44 7947 355344 H: +44 1256 478597


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

[Dnsmasq-discuss] dhcp-option 0.0.0.0 address interpretation possible bug?

[Kevin Darbyshire-Bryant]

Hi All,

dnsmasq 2.75

Putting 'dhcp-option=ntp-server,0.0.0.0' in dnsmasq.conf is throwing an
error "bad dhcp-option at line 73 of /etc/dnsmasq.conf"  Replacing it
with 'dhcp-option=42,0.0.0.0' allows dnsmasq to start and behave
properly.  I've noticed similar behaviour with 'netbios-ns' (option 44) 
The manpage states "special address 0.0.0.0 is taken to mean the address
of the machine running dnsmasq".

dhcpv6 options don't throw an error when using text versions of dhcpv6
options and special addresses (::, fe80::, fd00::) so I assume they're
okay but haven't checked the addresses contained in dhcpv6 replies yet.

I'm adopting my usual stance of assuming I'm an idiot and doing
something wrongawait education :-)

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] RFC 5908 - DHCPv6 NTP option 56

[Kevin Darbyshire-Bryant]

Hi All,

I've been looking at providing NTP server addresses to my DHCPv6 clients
using dnsmasq.  2 RFCs seem applicable, Simple NTP provision RFC4075
defines option 31 and known to dnsmasq as 'sntp-server'.  RFC5908
defines a more flexible/complicated provision mechanism using option 56,
known to dnsmasq as 'ntp-server'.

RFC5908 uses sub-options to option 56 defining a choice of sub-option 1 
unicast NTP server address, sub-option 2 Multicast server address and
sub-option 3 provision of a FQDN of the NTP server.

Looking at the dnsmasq logs (I've not yet got to packet capture) and
limited understanding of the code, I'm not convinced that dnsmasq's
option 56 implementation understands the usage of sub-options.

As ever, assuming I've mis-understood something here!

Best regards,

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] dhcp-option 0.0.0.0 address interpretation possible bug?

[Kevin Darbyshire-Bryant]

On 10/09/15 22:13, Simon Kelley wrote:
> On 10/09/15 10:39, Kevin Darbyshire-Bryant wrote:
>> Hi All,
>>
>> dnsmasq 2.75
>>
>> Putting 'dhcp-option=ntp-server,0.0.0.0' in dnsmasq.conf is throwing an
>> error "bad dhcp-option at line 73 of /etc/dnsmasq.conf"  Replacing it
>> with 'dhcp-option=42,0.0.0.0' allows dnsmasq to start and behave
>> properly.  I've noticed similar behaviour with 'netbios-ns' (option 44) 
>> The manpage states "special address 0.0.0.0 is taken to mean the address
>> of the machine running dnsmasq".
>>
>> dhcpv6 options don't throw an error when using text versions of dhcpv6
>> options and special addresses (::, fe80::, fd00::) so I assume they're
>> okay but haven't checked the addresses contained in dhcpv6 replies yet.
>>
>> I'm adopting my usual stance of assuming I'm an idiot and doing
>> something wrongawait education :-)
>
> You've got the syntax wrong, it should be
>
> dhcp-option=option:ntp-server,0.0.0.0
Ahhh!  The light dawns, one day I'll be able to read man pages properly
too :-)

Thanks Simon.
>
>
> Cheers,
>
> Simon.
>
>
>> 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




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] No IPv6

[Kevin Darbyshire-Bryant]

On 16/09/15 15:48, Nickolai Dobrynin wrote:
> Hello world!
>
> I can't get IPv6 working with dnsmasq.  My ISP supports IPv6 "natively",
> but when I run 'ping6 -c 1 google.com' on a client, I get "Network 
> unreachable".
> When I ping a host that's IPv4-only, the message becomes "unknown host".  My
> router (with dnsmasq atop) sits between the modem and the rest of the network.
>
> I do see some DNS queries (see below) logged from the pings (I assume) I just
> mentioned, but I'm not sure what to make of these logs since I don't know how
> healthy ones look.
>
> 'ifconfig' shows one IPv6 address (for that particular network
> interface), and it
> starts with f80::.  Not terribly useful.
>
> Many thanks,
> Nickolai Dobrynin
>
Hi Nickolai,

It sounds to me like your client doesn't have a world routable ipv6
address.  In ipv6 land, network/network prefixes are handed out by
'Router Advertisements' with optionally additional info by DHCPv6. 
dnsmasq can handle the RA/DHCPv6 requirement very well indeed,
alternately another common tool is 'radvd' which may already be running
on your router.

Check out the 'enable-ra' and 'dhcp-range' options of dnsmasq.  As a
brief and probably too specific example, I've the following on my
openwrt based router:

dhcp-range=::2, :::, constructor:br-lan,64, 12h
enable-ra
ra-param=br-lan,high,0

The br-lan interface is my bridge lan interface with wifi radios &
ethernet switch, this has a world routable ipv6 prefix allocated to it
(in my case by an ipv6 tunneling mechanism..no native yet)  A dhcpv6
range based on this prefix is constructed and the ipv6 prefix is
advertised as well as the instruction to use stateful dhcpv6.

You may find these additional options useful:

dhcp-option=option6:dns-server,[fe80::]
dhcp-option=option6:domain-search,your.local.domain.here
dhcp-option=option6:sntp-server,[fe80::]

These advertise the local ipv6 dns & ntp server to be the link-local
address of the machine running dnsmasq.  Also they advertise the local
dns domain name.

Finally, recently I've taken to using the following:

server=/0.in-addr.arpa/
server=/127.in-addr.arpa/
server=/254.169.in-addr.arpa/
server=/2.0.192.in-addr.arpa/
server=/100.51.198.in-addr.arpa/
server=/113.0.203.in-addr.arpa/
server=/255.255.255.255.in-addr.arpa/

server=/d.f.ip6.arpa/
server=/8.e.f.ip6.arpa/
server=/9.e.f.ip6.arpa/
server=/a.e.f.ip6.arpa/
server=/b.e.f.ip6.arpa/

For the purposes of trying to be a good netizen the above lines prevent
dnsmasq from forwarding reverse lookups (address to name) for address
ranges that really should be handled locally (my ISP really doesn't know
about my link-local address range, so I don't ask, which means it
doesn't ask the root servers either!)

Maybe some of this helps.

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] RFC6303 support - especially IPv6

[Kevin Darbyshire-Bryant]

Hi Simon,

I wonder if I could encourage you to look at extending the 'bogus-priv'
option to include some IPv6 zones?  In essence dnsmasq is currently
forwarding ipv6 link-local reverse queries when in reality root servers
aren't going to know anything.  Looking in the archives I see ipv6
reverses & 'bogus-priv' has been brought up before, and typically
stalled on deciding what to block.  I think RFC6303 answers those
questions to a large extent.

Attached is a patch to include extra IPv4 zones that are listed in that
document.  Maybe it'll help reduce some typing, though I'm concerned it
may also affect 'rebind zones' which I'm much less confident about :-) 
I couldn't find any IPv6 filtering otherwise I would have extended that too.

IPv6 Zones I'm currently filtering as per that document are:


'/d.f.ip6.arpa/'
'/8.e.f.ip6.arpa/'
'/9.e.f.ip6.arpa/'
'/a.e.f.ip6.arpa/'
'/b.e.f.ip6.arpa/'
'/0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/'
'/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/'


I've another more controversial idea that I'll put as another email as I
think it'll generate much more traffic!

Cheers,

Kevin
From abe37dd25e466f813b4bc5864c1bd7ad676ba6c8 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant 
Date: Mon, 19 Oct 2015 13:27:15 +0100
Subject: [PATCH] Update ipv4 bogus-priv to RFC6303 zones

RFC6303 specifies & recommends following zones not be forwarded
to globally facing servers.
+--+---+
| Zone | Description   |
+--+---+
| 0.IN-ADDR.ARPA   | IPv4 "THIS" NETWORK   |
| 127.IN-ADDR.ARPA | IPv4 Loopback NETWORK |
| 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL   |
| 2.0.192.IN-ADDR.ARPA | IPv4 TEST-NET-1   |
| 100.51.198.IN-ADDR.ARPA  | IPv4 TEST-NET-2   |
| 113.0.203.IN-ADDR.ARPA   | IPv4 TEST-NET-3   |
| 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST|
+--+---+

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/rfc1035.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/rfc1035.c b/src/rfc1035.c
index 6a51b30..4eb1772 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -756,10 +756,14 @@ int private_net(struct in_addr addr, int ban_localhost)
   return
 (((ip_addr & 0xFF00) == 0x7F00) && ban_localhost)  /* 127.0.0.0/8(loopback) */ ||
 ((ip_addr & 0xFF00) == 0x)  /* RFC 5735 section 3. "here" network */ ||
-((ip_addr & 0x) == 0xC0A8)  /* 192.168.0.0/16 (private)  */ ||
 ((ip_addr & 0xFF00) == 0x0A00)  /* 10.0.0.0/8 (private)  */ ||
 ((ip_addr & 0xFFF0) == 0xAC10)  /* 172.16.0.0/12  (private)  */ ||
-((ip_addr & 0x) == 0xA9FE)  /* 169.254.0.0/16 (zeroconf) */ ;
+((ip_addr & 0x) == 0xC0A8)  /* 192.168.0.0/16 (private)  */ ||
+((ip_addr & 0x) == 0xA9FE)  /* 169.254.0.0/16 (zeroconf) */ ||
+((ip_addr & 0xFF00) == 0xC200)  /* 192.0.2.0/24   (test-net) */ ||
+((ip_addr & 0xFF00) == 0xC6336400)  /* 198.51.100.0/24(test-net) */ ||
+((ip_addr & 0xFF00) == 0xCB007100)  /* 203.0.113.0/24 (test-net) */ ||
+((ip_addr & 0x) == 0x)  /* 255.255.255.255/32 (broadcast)*/ ;
 }
 
 static unsigned char *do_doctor(unsigned char *p, int count, struct dns_header *header, size_t qlen, char *name, int *doctored)
-- 
1.9.1



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] Enable bogus-priv by default

[Kevin Darbyshire-Bryant]

Hi Simon & list,

Ok, here's the controversial idea.  Can we consider enabling
'bogus-priv' by default and have an additional option say 'allow-priv'
to now disable?

My feeling is that not forwarding 'link-local' type requests upstream by
default is a cleaner way of having things configured.  Bearing in mind
the popularity of dnsmasq in all sorts of devices (Internet of Things) a
'be kind to your upstream servers and don't ask daft questions' default
should at least be considered.

I'm sure the flaws in my idea, logic and thinking will now be loudly
explained :-)

Kind regards,

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] Enable bogus-priv by default

[Kevin Darbyshire-Bryant]

On 20/10/15 21:35, Simon Kelley wrote:
> To add to the list of canonical uses for dnsmasq: DHCP and DNS services
> to VMs and containers in things like OpenStack. These typically use
> RFC1918 addresses (there's no point in being able to spin a new VM in
> seconds if you have to go buy it a real IPv4 address on the black market
> first.) so that's another argument against.
>
> I think that the "principle of least surprise" would stop me from
> _changing_ the default, even if I was convinced that the current choice
> is the wrong one. It's much too late to change.
>
> Actually, this isn't something that the code author needs to decide:
> Vanishingly few people install dnsmasq from source. It's a choice for
> the packager. That doesn't get me off the hook, since I package dnsmasq
> for Debian (and therefore Ubuntu, too). I note, for instance that
>
> --local-service
>
> defaults OFF in the dnsmasq code, but is defaulted ON in new Debian
> installations until explicitly turned off. The same could apply to
> bogus-priv.
>
> Of course that means the Kevin has far more people who he needs to
> convince to act
>
I think I've had it very well explained that my viewpoint is very narrow
:-)  And what's the saying about choosing battles wisely?  Not this
battle.  I did say controversial...and apparently only 50% silly this time.

Ideally those cheap, low margin home router manufacturers  will remember
to put '--bogus-priv' in their configs.

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] dnsmasq 2.75 build options

[Kevin Darbyshire-Bryant]

On 07/12/15 04:39, Shane Manjarres wrote:
> Looking at the build options listed in /src/config.h it states the
> following:
>  
> *The default set of options to build*
>  
> HAVE_DHCP
> HAVE_DHCP6
> HAVE_TFTP
> HAVE_SCRIPT
> HAVE_AUTH
> HAVE_IPSET
> HAVE_LOOP
>  
> *In the same config.h file is says you can disable options using the
> following:*
>  
> NO_IPV6
> NO_TFTP
> NO_DHCP
> NO_DHCP6
> NO_SCRIPT
> NO_LARGEFILE
> NO_AUTH
> NO_INOTIFY
> NO_NETTLE_ECC
> NO_GMP
>  
> *This apparently is the complete list of all the options you can have:*
> ** 
> HAVE_BROKEN_RTC
> HAVE_TFTP
> HAVE_DHCP
> HAVE_DHCP6
> HAVE_SCRIPT
> HAVE_LUASCRIPT
> HAVE_DBUS
> HAVE_IDN
> HAVE_CONNTRACK
> HAVE_IPSET
> HAVE_AUTH
> HAVE_DNSSEC
> HAVE_LOOP
> HAVE_INOTIFY
> I don't understand if the default build options above are the only
> options built in during build time then why are there options to
> disable  the following options where they have no HAVE options to go
> along with them:
>  
> NO_IPV6
> NO_LARGEFILE
> NO_NETTLE_ECC
> NO_GMP
GMP is the GNU Multiple Precision maths library and is only relevant for
DNSSEC operation (crypto)  The actual crypto is provided by 'nettle'. 
Nettle can be built with its own (slower) maths lib instead of GMP,
hence NO_GMP is really an option for (or passed on to) nettle - it
doesn't affect what features are built into dnsmasq.  Similarly nettle
itself can be built without elliptic curve crypto (NO_NETTLE_ECC)

The other 2 options are 'disable only' - I suspect to indicate they're
more switching off 'defaults'.  NO_IPV6 turns off all IPv6 functionality
in dnsmasq.  Disabling largefile support is to cope with the case where
'uclibc' doesn't support >32 bit file offset pointers/sizes.  Dnsmasq
goes back quite a way :-)

Kevin
>  
> Why do the above 4 options exist if they don’t for instance include
> HAVE_LARGEFILE or HAVE_GMP. Are the above 4 options build in by
> default as well and provide NO options to exclude them from the build
> process? I'm somewhat confused. Thank you for your time.
>  
>
>
> 
> Avast logo   
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com 
>
>
>
>
> ___
> 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] 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

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

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 
>  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] 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] 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

[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] 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

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
>&g

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
>>>

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] 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

[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 
Date: Fri, 27 May 2016 10:23:47 +0100
Subject: [PATCH] Improve dnssec SIGHUP behaviour

Signed-off-by: Kevin Darbyshire-Bryant 
---
 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 as is documented in the manpage.

kind regards,

Kevin



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

Signed-off-by: Kevin Darbyshire-Bryant 
---
 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 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

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] 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, &ifr) != -1 )
-	iface_addr = ((struct sockaddr_in *) &ifr.ifr_addr)->sin_addr;
-  else
 	{
-	  my_syslog(MS_DHCP | LOG_WARNING, _("DHCP packet received on %s which has no address"), ifr.ifr_name);
-	  return;
+	  addrp = &iface_addr;
+	  iface_addr = ((struct sockaddr_in *) &ifr.ifr_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 *)&iface_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, &parm);
 	}
   
+  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, &parm, 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] 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 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", &sin6_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", &sin6_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", &sin6_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

[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

[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 
---
 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, &trunc, 
nameoffset, &ansp, 
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

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 
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 
---
 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
@@ -29

[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]

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

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 do

[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] 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, &ia_end, &ia_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, &t1cntr);




___
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

[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] 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

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] 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] [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] 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&task_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] 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

[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] 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&task_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 
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.