Bug 2212111
| Summary: | [RFE] Design and implement a way to auto-correct time with DNSSEC validation enabled early on boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Menšík <pemensik> |
| Component: | unbound | Assignee: | Petr Menšík <pemensik> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | akhaitovich, mlichvar, paul.wouters, pemensik, pj.pandit |
| Target Milestone: | --- | Keywords: | FutureFeature, RFE |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| URL: | https://lists.nlnetlabs.nl/pipermail/unbound-users/2023-April/008075.html | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Petr Menšík
2023-06-03 22:55:12 UTC
I think statistics counter increasing each time the timestamp were not accepted for RRSIG, but otherwise the signature would pass, would be helpful. That would allow chrony to trigger time synchronization event, where we try to accept wider range of time for a initial time set. It could query that counter if all names known failed to resolve, whether to enable the special mode. But if it worked fine, it would boot with full security. Useful for devices without RTC like raspberry PI or old devices, where the clock got wrong for whatever reason. Found interesting requirement: https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-validator-requirements-04.html#name-time-deviation-and-absence- STARTUP: A DRO MUST provide a mean to update the time without relying on DNSSEC when the DNSSEC validator is started. The resolver MUST NOT start if the time synchronization does not succeed at start time. ... In other words, the mechanisms may have to update the time over an unsecure DNSSEC resolution. ^ The problem I see with this is getaddrinfo() in glibc does not provide a way to make unsecure resolution. It either works or not. Usage of dns-specific API like res_query() would not use /etc/hosts and similar databases. So they can result in different responses. It seems to me we should add ability to request validation of timestamps disabled in a query. Which is possible with CD bit set in DNS query, but nothing such is available in getaddrinfo(). There was a nice talk on this topic by Otto Moerbeek at FOSDEM 2024 DNS room: https://fosdem.org/2024/schedule/event/fosdem-2024-1856-bootstrapping-time-on-openbsd/ They are using CD bit to get around. This problem stays also when DNS over TLS would be used. Which would be more more important issue for us on upcoming RHEL 10. I think we want capability of booting with wrong time and autofixing it. No matter if just DNSSEC or just DNS over TLS or both of them were used. OpenNTP source seems to be at: https://cvsweb.openbsd.org/src/usr.sbin/ntpd/ And oh, that thing seems to be still using CVS. RES_USE_CD were added to DNS requests. One is used at: https://cvsweb.openbsd.org/src/usr.sbin/ntpd/ntp_dns.c?rev=1.28&content-type=text/x-cvsweb-markup RES_USE_CD is defined at: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/include/resolv.h?rev=1.23&content-type=text/x-cvsweb-markup Of course our glibc-headers-x86-2.38.9000-39.fc40.noarch does not provide any such flag to use. But I think we would want to use getaddrinfo() API anyway, so that flag would have to be propagated there. There is no AI_* flag defined in /usr/include/netdb.h to allow that in current version. What is used by our preferred chrony project is getaddrinfo call. https://gitlab.com/chrony/chrony/-/blob/4.5/nameserv.c?ref_type=tags#L87 I think we want AI_CHECK_DISABLED_TIME flag, which would be used only if the resolution has failed AND it happened during initial time synchronization only. Once machine time is obtained first time, there should be not a reason to use this flag until the next boot. I think we may want EDNS0 extension in our query, which might accompany CD flag in the query. That would request checking signatures, but skipping only time checks if supported. Just as with val-override-date: -1. Implementations now supporting this extension would do just CD flag. Those understanding the extension would reduce checks just partially. We may want to provide lower bound in that exception, which should include the lastest confirmed time this machine knows. Working as lowest accepted time for synchronization and query verification. Oh, at dns-oarc mattermost someone mentioned using negative trust anchor on pool.ntp.org. That is what we should do in default installation. It did not made sense at first on unsigned domain ntp.org. But presence of NTA makes unbound stop verifications of parent domains, which usually fail on org. verification. With the NTA in place it works out-of-the box. This helps: unbound-control insecure_add pool.ntp.org I think we want to add into default configuration: server: domain-insecure: pool.ntp.org |