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?


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.

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

Cheers,

Simon.


On 03/01/18 11:07, Kevin Darbyshire-Bryant wrote:
> 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?
> 
> 
> 
> 
> 
> 
> Cheers,
> 
> Kevin D-B
> 
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to