[LEDE-DEV] dnsmasq dnssec problem

Mon Jan 1 08:28:06 PST 2018

> On 1 Jan 2018, at 15:31, e9hack <e9hack at gmail.com> wrote:
> 
> Hi,
> 
> dnsmasq with dnssec enabled doesn't work properly. If dnssec is enabled, the parameter dnssec-no-timecheck is add too,
> depend on some conditions related to sysntpd. If this parameter is added and dnsmasq receives a SIGHUP before ntpd was
> able to set the time, name resolution isn't possible, because dnsmasq does check the time window now and invalidates
> every answer from an upstream server. If parameter dnssec-no-timecheck is added, parameter
> dnssec-timestamp=/var/state/dnsmasqsec must be add too.
No, since time will have increased since that file was created, dnsmasq will still consider time valid & hence will fail if your clock time differs significantly from reality.

The dnssec v time v resolution of nameservers chicken/egg problem is a right pain in the arse.  See commit 5acfe55d7139a5294192bddf10fe3a1de3180e8d for ideas on how this is supposed to work.

Another aspect of this problem is the overuse of SIGHUP by dnsmasq - it does many things, one of which is to indicate ‘time valid’.  Unfortunately an early (before time is set) issuance of SIGHUP will break name resolution.  More unfortunately odhcpd (used by LEDE for dhcpv6) uses SIGHUP to ask dnsmasq to reread host files on lease updates ( I probably haven’t hit this issue as often as I could because I use dnsmasq for dhcpv6/RA)

A potential solution is to use another signal, something I’ve been pondering for a while.

> 
> Regards,
> Hartmut
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Cheers,

Kevin D-B

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20180101/60e15831/attachment.sig>