On 11/11/20 7:07 PM, Hal Murray via devel wrote: > I've been thinking about something like this for a while. The idea is to be > able to specify the IP Address to be used for contacting a NTP or NTS-KE > server.
If you want to specify the IP address, just specify the IP address
("server 1.2.3.4") and don't bother with a hostname. Specifying an IP
instead of a hostname has historically been relatively popular with NTP,
especially in "network devices" (as opposed to "servers").
With NTS-KE, then you have the problem of certificate validation. That
is, the server needs to present a certificate with the IP address in the
subjectAltName. (Does NTPsec properly verify such a certificate today?)
Such certificates are available from paid CAs (and can be generated by
your own internal CA) but are not yet available from Let's Encrypt. The
good news is that they have finally put this on the TO DO list,
primarily because of demand from DNS-over-TLS:
https://letsencrypt.org/upcoming-features/#ip-addresses-in-certificates
https://github.com/letsencrypt/boulder/pull/4920
> There was discussion on the IETF-NTP list today about how to get NTP started
> on systems without (or broken) CMOS/TOY clocks whem you are using DNSSEC
> which
> needs time.
ntpd could maintain a cache (in /var/lib or better /var/cache) of the
results of DNS lookups. Specifically, something like this:
1. On startup, read the existing cache from disk, if present. This is
now an in-memory cache.
2. When ntpd gets a DNS query result, add it to the in-memory cache. If
the entry is new or different than the existing entry, set a flag that
the cache has changed. Cache entries will also have a timestamp of when
they were obtained. If ntpd has not yet set the system clock, use 0 as
the timestamp.
3. Once ntpd sets the system clock for the first time, update any cache
entries with 0 as the timestamp to the current time. Then, start a
periodic check: every X period of time, check to see if entries need to
be expired. If so, remove them and set the flag. If the cache
modification flag is set (from either adds or expirations), write out
the cache to disk and clear the flag. (The flag and periodic check are
to avoid a disk write for every DNS lookup.)
Only using timestamps after ntpd has set the clock should be a way to
safely set timestamps and handle cache expiration. The cache entry
lifetime should be very long.
Alternatively, instead of using timestamps to expire cache entries,
maybe a better policy would be to keep everything for the hostnames of
the configured servers/pools (and nothing else).
Then, of course, we need to actually use the cache:
4. If a DNS lookup fails (either a SERVFAIL or timeout), check the
cache. Perhaps this is _only_ used until ntpd sets the system clock?
So for a system with no battery-backed clock, on boot, ntpd will read
the old cache from disk. It will then try to resolve things via DNS,
which will fail because the on-box DNSSEC-validating resolver cannot
validate DNSSEC or the resolver cannot validate the DNS-over-TLS
certificate or whatever. That failure will result in the ntpd DNS cache
being used. Now it can spin up associations as normal.
There's still the chicken-and-egg issue with validating NTS certificates
without having valid time, but I have discussed that before:
https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/942
--
Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
