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 > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
