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 > Dnsmasqfirstname.lastname@example.org > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss