[Unbound-users] A few ideas and questions

[Wouter Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Teran,

Thank you for your feedback. Below, I'll try to answer your questions.

Teran McKinney wrote:
> 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.

Right now, a forward-zone beats stubs below it. Forwarding is done
first, and the forwarder is supposed to do everything below that name ;
no resolution towards the stub is done.

The reasoning here was that performing the recursive lookup means
chasing stubs and referrals.  A forwarder performs the recursive lookup
for you, and thus no stubs or referrals is done by the downstream
forwarding-client for names below the forward-zone.

> 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).

The order in the config file should not matter for stubs and forward-zones.

If you set a forward zone for ".", then unbound ignores all stubs, and
the forwarded-to server has to handle the .el domain.

I do not understand what you mean with that it stopped resolving quite
often. Apart from that it shouldn't be working the way you think it does
:-). It sounds like there could be a bug. Could you explain more or send
me log files when it stops (mail me perhaps off mailing list).

If you want .el traffic to take a different route then "." traffic you
have two ways:
- - use forwarders; forward zone ".el" one way, forward "." another way.
- - use stubs; stub zone for ".el" and root-hints for "." another way.

Your config file has the first. It should work.

> 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.

Are there other people that need this (prefer ipv6) feature, is it
really useful?
I note that in your config, you have do-ip4: no, so it already uses ipv6
addresses only.  Unbound does not perform ip4to6mapping or something, so
in your setup, only ipv6 nameservers are used.

> 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

Interesting idea.  Of course changing this sort of big assumptions needs
careful consideration.  This way of working stems back to the
Java-Unbound prototype.  So, although I would like to support you, I do
not want to change the 'default behaviour'.

> way, how does Unbound treat stub zones differently than forwarding

forwarding is checked first, if below a forwarded name, use that.
stubs checked second, and recursive lookup is performed.

> 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.

Unbound right now, does not trust the upstream resolver (even if you
install unbound there).  Therefore it sends the CD (checking disabled)
bit to upstream requests, so that it can apply its own validation policy.

You need to configure validation for your downstream server.

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

OK, thank you.

> PS: Does NLnet Labs have an IRC channel?

No.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjGMMgACgkQkDLqNwOhpPiI0gCgm4X5vHikR+LNEXsYFdUNhzUz
LkQAoLFr/4IW+/do+dt9pnbZNZmy6Sld
=QGBl
-----END PGP SIGNATURE-----