Re: smoketest #6 of cerowrt is go for testing

[Evan Hunt <ethanol@gmail.com>]

DNSSEC doesn't need atomic clock accuracy.  Accurate to within an hour
is more than sufficient.

A bog-simple anycasted UDP time/daytime server could get the job done
beautifully.  Even SNTP is overkill for this.  We could use a time
server to get the clock into the right ballpark, then start named,
then start ntpd to set the clock for real.

Or NTP could make a leap-of-faith on startup and query for server
addresses with DNSSEC checking disabled.  There's no standard API for
that yet, though (dnssec-tools.org has proposed one, val_getaddrinfo()
and val_getnameinfo(), and there's a reference implementation, but I
don't think it's made it out into any distributions yet).

Or, named can run with the dnssec-accept-expired option set to yes,
causing it to ignore signature expiration times, then switch the
option off after the date has been set correctly--but this is
cumbersome (and leaves named open to replay attacks during the
initialization interval).

In the absence of a standard DNSSEC-aware gethostinfo() API, I like
the anycasted time server idea.  I'll see if I can interest anyone at
ISC in providing such a service.  (And maybe the ntpns.org name
servers could provide it, since they're anycasted already?  I'm not
sure whom to ask.)

Evan

On Sun, Jul 17, 2011 at 8:50 AM, Dave Hart
<davehart_gmail_exchange_tee@davehart.net> wrote:
> On Sun, Jul 17, 2011 at 12:34 UTC, Dave Taht <dave.taht@gmail.com> wrote:
>> On Sat, Jul 16, 2011 at 10:35 PM, Dave Hart
>> <davehart_gmail_exchange_tee@davehart.net> wrote:
>>>
>>> On Sun, Jul 17, 2011 at 00:02 UTC, Rick Jones <rick.jones2@hp.com> wrote:
>>> > If you configure ntpd with bare IP addresses rather than names, will the
>>> > getaddrinfo() return without attempting any DNS in the first place?
>>>
>>> Yes, basically.  ntpd might not even call getaddrinfo() in that case
>>> (it may use inet_pton() or similar to convert the IP address to binary
>>> representation).  At any rate, using only numeric IPv4 or IPv6
>>> addresses will avoid any DNS lookups.
>>
>> While there is one group that is finally providing ntp time via anycast -
>> which is a good solution to a large extent! - there is only the one (small)
>> group doing so, rather than the needed '3'.
>>
>> http://news.ntppool.org/2011/03/expanding-the-anycast-dns-serv.html
>
> You misread the announcement:  What is anycast is the DNS service for
> pool.ntp.org provided by (among others) a.ntpns.org, which is the
> anycast IP now served from 3 sites.  Anycast is being used to spread
> the load of the custom DNS server software used for *.pool.ntp.org.
> NTP time service is not being anycast by the pool operators.
>
> I do know of one operator who provides NTP time service over anycasted
> IP addresses, but it is not a good solution in general.  For simple
> clients it makes no difference, but for full NTP, a single IP address
> is assumed to represent a single oscillator reached via a single
> network path.  ntpd keeps an eight-deep history for each configured
> server of the delay, root dispersion, and apparent offset.  NTP's
> clock filter algorithm chooses the lowest-delay sample from this
> history, which helps remove the majority of error caused by network
> delay variation -- the lowest delay sample represents the best guess
> at the actual path round-trip time.  Using an anycast IP address as a
> ntpd time source violates the assumption and results in samples from
> more than one oscillator reached via more than one path being compared
> as if they represented a single clock and path.
>
>> And I'm reluctant, given the sordid history of hard coding ntp IP addresses,
>>
>> http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
>>
>> to hard code *any* until far more anycast servers are online.
>
> If you are using well-behaved NTP clients and reasonable
> configurations, each server can handle many thousands of clients, each
> of which is polling every 1024 seconds once settled in.  For
> bootstrapping, where you need to set the time in order to enable
> DNSSEC in order to enable normal operation using pool.ntp.org, you can
> reasonably get by with a handful of hardcoded NTP server IPs, assuming
> you are doing a one-shot NTP query during startup then switching to
> DNS and pool.ntp.org for ongoing clock sync.
>
>> To take a step backwards on this, there are extensive notes on the circular
>> dependencies between time and dnssec logged here.
>>
>> http://www.bufferbloat.net/issues/205
>>
>> I'd implemented a hack to try to address these circular depenencies last
>> week in the named-latest package repo, while also coping with
>>
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2464
>>
>> I think I addressed the latter issue, but *good*. :) The 'fix' for the
>> ntp/dnssec/bind/network dependencies seems to have some problems, however,
>> notably really slow startup in general.
>>
>>
>> To step further back on this:
>>
>> I had implemented ntp (with 7 contacted servers in the conf file!) in the
>
> IMO 7 is not an extreme number of NTP servers to associate with.  I
> help operate a pool NTP server which has 15 associations configured
> using maxpoll 8 (256s).  A handful of those are for monitoring
> purposes, but the majority are there to provide a wide variety of
> stable oscillators, in hopes of keeping better time by giving NTP the
> information it needs to ignore transient outliers.  That still amounts
> to an average of about 4 queries to lower-stratum "upstream" sources
> per minute, which is trivial compared to the 20,000 client NTP queries
> it serves each minute (currently averaging 363 pkts/sec).
>
>> first place due to the "cosmic background bufferbloat detector" idea
>> extensively discussed on the comp.protocols.ntp newsgroup, and because I
>> wanted to be able to compare large sample data sets against known-to-be
>> accurate time, with a large deployment of client routers that had a
>> configuration I could trust to be accurate, talking to a yet-to-be-deployed
>> string of ntp servers (via hopefully a helpful operator) that could work on
>> this with us.
>
> Even better would be comparing against a local NTP server set up with
> a GPS + PPS (pulse-per-second).  Using off-the-shelf components, the
> hardware cost in the US is between $30 and $100.   $30 gets you a Sure
> GPS that has PPS but requires good eyes and a steady soldering hand to
> bring it from the PCB to the RS-232 connection.  For less than $70 you
> can get a Garmin GPS 18x LVC, which requires less accurate soldering
> to provide 5VDC power (often via USB) and a DB-9 connector for its
> bare-lead 232 connection.  For $100 you can get a ready-to-use 18x LVC
> with DB-9 serial and USB power cables provided by a third party.
>
> Cheers,
> Dave Hart
>