Hi,
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:
https://indico.dns-oarc.net/event/21/contribution/35/material/slides/
0.pdf
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
root
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...
Best,
-Michael
Cheers,
Simon.
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@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
