[Unbound-users] A few ideas and questions

[Teran McKinney]

Hi,

After using Unbound for about a month and a half now, I've conjured up
a few ideas I would like to share. I have also come across a few
things that may be bugs, but I'm not sure.

While Unbound has been working perfectly under normal use (with
DNSSEC, too), I have had a few problems with a seperate Unbound
resolver forwarding requests to my primary resolver and a nameserver
for a private TLD. I originally did this with a root.hints file (I
discovered that Unbound keeps the default root servers unless they are
explicitly overwritten by root.hints, and found this to be a bit
strange), but it would often stop resolving to the primary resolver
for "." (which it should use for all zones except ".el"). I also tried
with a stub zone for ".el" and forwarding ".", however stub zones do
not seem to work when a forwarding zone is set. Finally, I settled on
using forwarding for both zones, but this seems to stop resolving both
"." and ".el" quite often. Before, I had positioned the ".el"
forwarding zone above the "." zone in the config file, but have since
(this morning), reordered them to see if that was the source of the
problem. It has not stopped resolving yet, but I will have to wait and
see. Here is the current configuration:
<ftp://icadyptes.go-beyond.org/other/unbound.conf> (fd11:2358:1321::1
points to NSD running on the same server).

I have a couple suggestions for Unbound, but they are quite minor in
general and Unbound is already an amazing caching resolver. The
release notes for 1.0.2
<http://www.unbound.net/documentation/patch_announce102.html> are very
comprehensive, and much like a full-blown article on DNS security. It
states that Unbound even randomly alternates between resolving over
IPv4 and IPv6 when possible for more security. While this behavior is
very impressive and helps increase security, I think that an option to
prefer IPv4 or IPv6 would be nice to have. Opportunistic encryption
through IPSEC is easier to do on IPv6, and could offer additional
protection underneath the application layer. For that reason, and
because I would rather see more of my packets go out over IPv6, I
would personally like to be able to set my resolver to always prefer
IPv6, even at the slight cost of security. Of course, this is quite
minor in comparsion to the rest of Unbound and the needs of a caching
resolver. I would like to submit a patch for it, but have neither the
C skills (yet), or time.

If my above experience with stub zones not working with forwarding
zones was not just user error, I think it would be nice to be able to
use stub zones and forwarding zones in the same configuration. By the
way, how does Unbound treat stub zones differently than forwarding
zones? Also, for some reason, requests forwarded to my main Unbound
resolver answer requests with bad DNSSEC signatures (IE: one of the
purposefully invalid subdomains at dnssec-tools.org), even though such
requests directly through that server give no results (since the
resolver has been configured with that domain's DNSSEC key). Perhaps I
should be using stub zones instead? I don't understand why it would
not give an identical answer to the server it forwards requests to,
but am not a master of the DNS protocol either.

Let me know if you need any more information or help testing patches.

Thanks,
Teran (sega01)

PS: Does NLnet Labs have an IRC channel?