On 11 Feb 2015, at 22:02, Simon Kelley si...@thekelleys.org.uk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/02/15 18:28, Kevin Darbyshire-Bryant wrote:
On 09/02/2015 16:02, Simon Kelley wrote:
On 09/02/15 13:21, Kevin Darbyshire-Bryant wrote:
Further to my previous email I've cobbled something together,
and it even appears to work. There's quite a bit of coding
guesswork going on here and I really shouldn't be let anywhere
near a C compiler. Either way a new option
'-dnssec_tvalid=integer' where integer is number of seconds
since 1970 (epoch) is implemented. If current system clock
exceeds this time then dnssec timestamps will be checked, until
that time they are not.
Answering your previous mail as well, I like this as an idea.
I think the original concept (date after an arbitrary, recent,
time id better if the time really is arbitrary. Putting
timestamps in the start-up infrastructure to pass to dnsmasq is a
bit pointless: they won't be better than something compiled
into dnsmasq, and they're a pain to generate (What's the command
to spit out now in seconds since 1970?). A bit of makefile
wizzardry could compile in now at build time, as another idea.
However it occurs to me that many of the platforms we're talking
about here don't have an RTC, but they _do_ have non-volatile
storage. How about storing now to NVRAM every hour, and using
_that_ as the time which must be superceded?
The second path is well on the way, BTW, I'm happy to take it and
bash it into shape, once we agree on exactly what's needed.
Cheers,
Simon.
Hi Simon,
Hmmm, it's a 'difficult' one. Building 'now' in at compile time
is certainly an option but it does assume that the firmware won't
at some stage in the future and boot up to a time that's then valid
by default. I was quite shocked to find the router I'm currently
fiddling with defaulted to December 2014! And I get your point
that even providing a mechanism to pass a good 'valid' time is
itself built into the firmwareunless it's provided by an
additional config file in stored in NVRAM, which is the approach
I've taken. I do wholeheartedly agree seconds since 1970 is arcane
to say the least and a way to automate that out has got to be a
good idea :-)
I like the idea of storing now in 'nvram' somehow very much.
There are a couple of thoughts on this, and I'm viewing this from
an Asus router 'asuswrt' perspective so may not be thinking of
other platform issues. I've an NVRAM partition (using JFFS) which
uses a spare portion of flash memory as NVRAM. Ideally you don't
want to write to this too often as it'll wear the flash out
prematurely. I don't know what the dnssec signature validity
granularity is but would a daily update really be too infrequent?
Of course I can add a USB stick drive to the router and use that
(in fact I do) but this isn't a default option that say Asus could
put in, they'd have to point to JFFS by default.
My other thought relates to how this file gets created
initialised. My head is hurting trying to think this through but
the case where the file exists is the most straightforward (compare
the time stored to now and if now greater then the clock has
hopefully been set and the file should be updated) I think a
safeguard to creating the file in the first place needs
implementing, in essence something like seeing a significant time
jump forward (say a day) which indicates a clock set operation.
Fundamentally the idea of passing an option to a timestamp file
along with an update interval is really good.
Kevin
I think we need to be careful to distinguish two different things here.
There's the idea of saving a last good time in NVRAM so that we can
sanity-check the kernel time, and not do time checks until it looks
good. This is a roundabout way of getting information to dnsmasq that
NTP is running, and avoids the chicken and egg that NTP needs to do DNS.
The principle I agree with. I'm wondering about the mechanics of accessing
this NVRAM 'last good time'. Is this something you're thinking that dnsmasq
should access maintain, in which case a file stored in a non-volatile
filesystem would be the most cross-platform method. Or are you thinking the
device OS should write a parameter into dnsmasq's config file at start (as I've
cobbled together) ?
I have to say that I'd quite like dnsmasq to handle all the timestamp related
stuff so dnssec could simply be a case of throwing a switch and everything is
handled automagically. That might encourage home router manufacturers to
include enable by default. But what do I know!?
There's a second idea, which is to use the last good time as a proxy
for now. Ie always check DNSSEC key times, but use the last value
written to NVRAM. That's probably good 99% of the time, but will break
if you leave your router switched off for a couple of months. It will
also
