On 30/09/15 03:22, Yousong Zhou wrote: > Hi, hope this comment is not too late :)
To be blunt I've given up. There's a 'companion' patch https://patchwork.ozlabs.org/patch/522968/ which also is mentally in the same state. Ultimately if ntpd can be persuaded to set a flag when it considers time valid, then dnsmasq can be started with '--dnssec-no-timecheck' when invalid and without '--dnssec-no-timecheck' when it is valid irrespective of local (correctly?) set RTC. There's clearly a hole in the sense that if dnssec is sent SIGHUP whilst -dnssec-no-timecheck is included AND the time hasn't been set correctly then name resolution will stop. Removing the 'SIGHUP' awareness of dnssec-no-timecheck from what I remember of the code would be a trivial patch. ntpd should completely restart dnsmasq to ensure its cache is completely security validated. This would also cope with the case where sysfixtime has picked up a 'naughty' file and set the time far in the future, though now I'm mentally having issues with time going backwards. I quote pertinent options from the dnsmasq man page for reference: *--dnssec* Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the DNSSEC records needed to validate the replies. The replies are validated and the result returned as the Authenticated Data bit in the DNS packet. In addition the DNSSEC records are stored in the cache, making validation by clients more efficient. Note that validation by clients is the most secure DNSSEC mode, but for clients unable to do validation, use of the AD bit set by dnsmasq is useful, provided that the network between the dnsmasq server and the client is trusted. Dnsmasq must be compiled with HAVE_DNSSEC enabled, and DNSSEC trust anchors provided, see *--trust-anchor.* Because the DNSSEC validation process uses the cache, it is not permitted to reduce the cache size below the default when DNSSEC is enabled. The nameservers upstream of dnsmasq must be DNSSEC-capable, ie capable of returning DNSSEC records with data. If they are not, then dnsmasq will not be able to determine the trusted status of answers. In the default mode, this menas that all replies will be marked as untrusted. If *--dnssec-check-unsigned* is set and the upstream servers don't support DNSSEC, then DNS service will be entirely broken. *--dnssec-check-unsigned* As a default, dnsmasq does not check that unsigned DNS replies are legitimate: they are assumed to be valid and passed on (without the "authentic data" bit set, of course). This does not protect against an attacker forging unsigned replies for signed DNS zones, but it is fast. If this flag is set, dnsmasq will check the zones of unsigned replies, to ensure that unsigned replies are allowed in those zones. The cost of this is more upstream queries and slower performance. See also the warning about upstream servers in the section on *--dnssec* *--dnssec-no-timecheck* 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. *--dnssec-timestamp=<path>* Enables an alternative way of checking the validity of the system time for DNSSEC (see --dnssec-no-timecheck). In this case, the system time is considered to be valid once it becomes later than the timestamp on the specified file. The file is created and its timestamp set automatically by dnsmasq. The file must be stored on a persistent filesystem, so that it and its mtime are carried over system restarts. The timestamp file is created after dnsmasq has dropped root, so it must be in a location writable by the unprivileged user that dnsmasq runs as. Note, by default openwrt uses 'dnssec, dnssec-check-unsigned, dnssec-timestamp' - The man page arguably doesn't also emphasize enough that if signature checking is enabled and the current time is incorrect then resolution will fail (everything marked as bogus) I await a new patch from a much better coder than me with enthusiasm!
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
