michael.tremer at ipfire.org
Tue Jul 28 14:19:56 BST 2015
that is good news that you considered implementing this, too.
On Mon, 2015-07-27 at 19:31 +0100, Simon Kelley wrote:
> I've considered it, and in an ideal world would like to implement it.
> My experience is the _nothing_ to do with DNSSEC is "not too
> difficult" and, to be honest, any system deploying the releases of
> dnsmasq with DNSSEC to-date which can't be updated is in a bad way
> anyway. I hope we're close to a stable implementation now, so maybe
> now is the time to start thinking about this. Of course this is only
> relevant of the root key really does get rolled sometime soon, and if
> that doesn't cause the end of world.
I guess DNSSEC is working alright in dnsmasq now. There are some issues
here and there, but some of them are caused by other things on the way
like MTU issues, broken upstream resolvers and so on.
The official information is that a key rollover will happen "at some
time in 2015":
There is no schedule yet, but we better be prepared.
> My ideal would be to a have a stand-alone RFC5011 daemon, which is
> responsible for keeping the OS's idea of the root key(s) up-to-date.
> Debian already has a package which provides a central copy of the
> keys, and dnsmasq will use these is it's installed. Having something
> which does that but dynamically updates them would be good.
Hmm, I do not really think that an extra daemon is such a good idea. I
do not know what the reasons are that you would prefer this, but here
is my view:
This daemon will only be needed once every five years. It will run
additionally and almost never do anything. I guess most problems that
we will have then are similar to the leap second bugs - very rare
events that never really tests and when it is showtime everything fails
miserably. Not that I don't trust your coding skills, but certainly
this daemon won't receive much love.
The daemon would require to implement DNSSEC again. I am not sure if
parts of the codebase of dnsmasq can be used on their own. It doesn't
look like that to me. One could use something like libunbound or
similar because that would have an implementation to verify the DNSSEC
signatures, but would also be lots of code that is pulled in and barely
used. I am not sure what other users of dnsmasq would think about this
who are running embedded systems on very tiny flash. Creating a
libdnsmasq that does the same job will probably require lots of work in
dnsmasq that isn't worth it for such a tiny job like RFC5011.
If you want to save systems from downloading the new trust-anchor
multiple times because they have multiple resolvers that need the keys
a single stand-along daemon would help. But even if that would happen
for each of them independently that would not create more load on the
network or require any other resources.
None of these are arguments that require a hundred percent to implement
the functionality inside dnsmasq but I still think that this is the
better idea. Lots of code is there and can easily be used. Updating to
a newly downloaded key is done very quickly and we could implement a
trigger that can do better error handling and maybe start updating the
DNSKEY of the . zone when something went wrong along the validation
process. This might have some security implications but still is an
idea to make the transitions to a new key as easy as we possibly can.
Is this even a requirement to just update the . zone? What if I use a
trust-anchor for my own zone? Shouldn't that one be updated, too? In
that case it is again better to check the running configuration of
dnsmasq and then perform an update for these, too (didn't check what
the RFC says about this).
Just my thoughts...
> On 23/07/15 10:18, Michael Tremer wrote:
> > Hello Simon, hello list,
> > I was just wondering if someone has ever considered to support
> > RFC5011 in dnsmasq:
> > https://tools.ietf.org/html/rfc5011
> > This will automatically update the trust anchor in case the KSK of
> > the root zone is replaced which will probably happen this year.
> > The implementation should not be too difficult. Most of the stuff
> > that is required is already there. dnsmasq needs to fetch the
> > DNSKEY record(s) of the . zone regularly and check if the KSK has
> > changed. If so the signature needs to be validated of course and
> > then the new key material needs to be stored somewhere on disk.
> > If this is not implemented all instances that use DNSSEC won't work
> > any more. As dnsmasq is often deployed on systems that are not too
> > regularly updated (hardware routers and so on) I think it is a
> > good idea to implement this RFC.
> > As far as I know unbound and others support this RFC.
> > Best, -Michael
> > _______________________________________________ Dnsmasq-discuss
> > mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Dnsmasq-discuss