unbound-anchor DNSKEY read-only import

Eric Luehrsen ericluehrsen at hotmail.com
Thu May 25 00:48:49 UTC 2017



On 05/24/2017 02:07 PM, Petr Menšík via Unbound-users wrote:
> Hello,
> 
> today I found a limitation of unbound-anchor related to package
> management. I am not sure if it is by design. If root anchor is managed
> and updated by periodic updates, everything is fine.
> 
> However when I tried to update new DNS trust anchor to unbound libraries
> before it even appeared, I have found no secure way to do it. It does
> only read existing DNSKEYS from file passed by -a parameter. After each
> successful query that file is modified. That makes the file not replaced
> by package management, because it contains changes.
> 
> I have been looking for way to add more keys into that file, but
> unbound-anchor does not allow more trust anchor files. When I append new
> keys into the file, It will work well next time, but no syntax is
> checked when appending. It would be great if it can test syntax, test
> whether it is already managed and add new key if not yet.
> 
> I think it would be useful if there was something like BIND
> managed-keys. Source of new trusted anchor is only initialized from user
> configured file. Then keys are managed in private bind directory, where
> key rolling occurs. I were unable to find a way to do something similar
> with unbound-anchor. Is there possible workaround with -C config file?
> 
> I am willing to create patch, but would like opinions from you. Do you
> think it would be useful?
> 
> It would be also nice if there was possible fallback from
> /etc/resolv.conf servers to direct root querying. If unbound operates in
> environment that refuses direct access to internet servers, it will
> never refresh DNSSEC key without manual configuration. I think it is not
> expected. Something like forward first; option in bind configuration. It
> would be handy, but I have workaround for this. Just try first with -f
> /etc/resolv.conf, if it fails try without it. It would be nice to have
> different return code for configuration failures and for DNS query
> failures however.
> 
> Best Regards,
> Petr Menšík

Hi Petr -

In OpenWrt/LEDE, the Unbound package takes action to protect flash ROM 
which also could be expanded more to manage the keys. The start and stop 
scripts copy everything from /etc/unbound (ROM) to /var/lib/unbound 
(tmpfs, RAM). Unbound is chroot to this location also. Unbound is busy 
with RFC5011 tracking and this could wear down the flash otherwise. 
During the stop script (includes restarts) the "root.key" file is 
checked and if new enough copied back to /etc/unbound.

This was the result from this bug report. The script solution is a bit 
clumsy. Maybe this concept should be revisited for inclusion in Unbound 
proper.

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=837

- Eric



More information about the Unbound-users mailing list