> On 5 Jan 2018, at 11:10, Karl Palsson <ka...@tweak.net.au> wrote: > > > The freshly released busybox 1.28 has a number of DNS related > fixes for NTP btw. > > ntpd: do run the script at least once in 11 minutes > ntpd: improve treatment of DNS resolution failures > ntpd: mention in help text that -d can be repeated > ntpd: perform DNS resolution out of send/receive loop. Closes 10466 > ntpd: skip over setting next DNS resolution attempt if it is not needed > > > Cheers, > Karl P
Hi Karl, Thanks for the pointers and thoughts, unfortunately none of the fixes can help. It’s a sort of race problem. For background (and I apologise if you know any of this already) dnssec offers a means of validating dns data is correct within a zone. Part of that validation includes a timestamp ‘this zone data is to be trusted until such a time’. This implies that the requestor of the data has a good (enough) idea of the current time in order to work out if it should trust the response or not. dnsmasq can validate whether a non dnssec zone should be a non dnssec zone (in other words, is someone faking to us that a dnssec zone is actually a non dnssec zone and thus can fake further responses within that zone) - it does so by getting a dnssec signed message that ‘the non dnssec zone is really a non dnssec zone’ with a timestamp (and hence needs time to be valid to verify) dnsmasq can run with dnssec enabled (—dnssec) where it just checks dnssec signed zones (and hence requires valid times). It can also run with unsigned zone checking (—dnssec-check-unsigned) which would also required valid time set. From the dnsmasq man page: "DNSSEC signatures are only valid for specified time windows, and should be rejected outside those windows. This generates an interesting chicken-and-egg problem for machines which don't have a hardware real time clock. For these machines to determine the correct time typically requires use of NTP and therefore DNS, but validating DNS requires that the correct time is already known. Setting this flag removes the time-window checks (but not other DNSSEC validation.) only until the dnsmasq process receives SIGHUP. The intention is that dnsmasq should be started with this flag when the platform determines that reliable time is not currently available. As soon as reliable time is established, a SIGHUP should be sent to dnsmasq, which enables time checking, and purges the cache of DNS records which have not been throughly checked." ntpd needs name resolution to work in order to turn ‘a.ntpservername.org’ into an address and query it for time. name resolution needs the time to be set correctly in order to validate the returned address info - the ferocity/severity of checking non dnssec zones being determined by ‘—dnssec-check-unsigned’) As described in the manpage, dnsmasq offers a way out of the chicken/egg problem by relaxing the time validation until dnsmasq is signalled that it should go into full paranoia mode (—dnssec-no-timecheck), the signal being sent a SIGHUP. This makes SIGHUP a rather important signal, but unfortunately, dnsmasq uses SIGHUP to indicate other things as well as ‘time is valid for dnssec’. These ‘other things’ are important to other LEDE processes (typically procd & odhcpd) and are being sent more frequently. The problem with that is that the ‘other things’ are erroneously telling dnsmasq that time is valid, *before* ntpd has actually had a chance to set the correct system time. This breaks name resolution for dnssec zone (—dnssec) and potentially completely (—dnssec-check-unsigned). If you were checking only dnssec zones (ie no —dnssec-check-unsigned) AND your ntp server names resided in a non-dnssec zone, then eventually access to the dnssec zone would come good. So, I’ve currently a patch in submission with dnsmasq to change which signal is used to indicate that time checking should be enabled. It’s similar to the v1 patch here, but better ;-) I intend to backport the upstream patch once it has settled. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
