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

[Kevin Darbyshire-Bryant]

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

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

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

Now that I like :-)

Cheers,

Kevin


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

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

[Kevin Darbyshire-Bryant]

Hi Simon,

Happy New Year!

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

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

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

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

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

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

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

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



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



Cheers,

Kevin D-B

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



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