A few ideas and questions

Unbound
1

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&gt; (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&gt; 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?

2

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&gt; (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&gt; 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

3

Why is OE easier on IPv6? Because there is less chance of a NAT?

Paul

4

Ok, sorry for not replying earlier; I was waiting for Unbound to stop
resolving again with debugging and logging enabled.

Why is OE easier on IPv6? Because there is less chance of a NAT?

Paul

No NATs, and OE with RDNS makes it possible to connect to a client and
still have OE, instead of having it only possible in a client to
server connection. FTP's PORT comand is a good example of this (If I
recall correctly).

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.

I should explain my setup a bit better. My router is on a dual stack
and serves DNS requests for my LAN via Unbound. The server that is set
as IPv6-only, is my public OpenVPN server. It runs its own instance of
Unbound and forwards requests to my main router's Unbound instance,
except those for the ".el" zone. The VPN is IPv6-only (technically a
rogue IPv4 network could be setup, but it is discouraged), so I have
no need for IPv4 support in its Unbound; clients can use their own
recursive resolver and point it to the server serving ".el", or they
can more easily use the VPN's own resolver which serves "." and ".el".
I am refering to dual stack usage for the IP protocol preference idea
I mentioned earlier. I'm sure it wouldn't be used by many people yet,
but I would be suprised if noone oher than me were to use it (may also
help with debugging). It is definitely a minor request, regardless.

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

Every few days or so Unbound (on the VPN server) would stop forwarding
requests to my router's Unbound instance, but generally (not certain
if always), the ".el" zone would still resolve over the other server,
which is just an authoritive server. Unbound would return SERVFAILs,
but still be reachable. I turned on debugging and had to wait quite
some time for it to stop working again; it took quite a while as it
just stopped today. It even did so twice or three times today, so it
seems like something in particular is breaking it. Here is what seems
to be the relevant part in the logs
<ftp://icadyptes.go-beyond.org/other/unbound-log.txt&gt;\. I don't quite
understand the errors, but hopefully they are enough. Let me know if
you need anything else.

As I was writing this email I came across some problems with my DNSSEC
setup. Part of it appeared to be incorrectly configured, but I also
seem to have had problems with the trusted-key-file parser in Unbound.
After spending a while diagnosing it, I brought it to a point where I
could have an identical (asside from the syntax) entry in
trusted-key-file and trust-anchor-file, and the domain would only
correctly authenticate via trust-anchor-file. I have many other zones
in trusted-key-file, and it is now together with a trust-anchor-file
only holding a single dnskey entry. The domain that was not working is
eleuther.net (which did not work in trusted-key-file), go-beyond.org
works fine and is in the trusted-key-file. Perhaps there is a bug
surrounding the parsing? Sorry I don't have any logs or details of
this, I was a bit frustrated over the time spent debuging it and
didn't want to spend any more time once I fixed it. If you can't think
of any immediate potential problems, I'd be happy to give you more
specifics. I've had similair issues before, but was never certain
where the problem was exactly.

Thanks,
Teran (sega01)

5

Hi Teran,

Teran McKinney wrote:

Every few days or so Unbound (on the VPN server) would stop forwarding
requests to my router's Unbound instance, but generally (not certain
if always), the ".el" zone would still resolve over the other server,
which is just an authoritive server. Unbound would return SERVFAILs,
but still be reachable. I turned on debugging and had to wait quite
some time for it to stop working again; it took quite a while as it
just stopped today. It even did so twice or three times today, so it
seems like something in particular is breaking it. Here is what seems
to be the relevant part in the logs
<ftp://icadyptes.go-beyond.org/other/unbound-log.txt&gt;\. I don't quite
understand the errors, but hopefully they are enough. Let me know if
you need anything else.

The log file indicates that the router is not responding always. Due to
excessive timeouts, unbound has 'blacklisted' that IP address. This
lasts for 15 minutes by default.
  infra-host-ttl: 900 # seconds
So, the part where the retry was done, the timeouts, is not in this log
excerpt. Are you experiencing periods of high packet loss?

As a workaround, you could put the infra-host-ttl: 3
This limits nonresolving to 3 seconds.

As I was writing this email I came across some problems with my DNSSEC
setup. Part of it appeared to be incorrectly configured, but I also
seem to have had problems with the trusted-key-file parser in Unbound.
After spending a while diagnosing it, I brought it to a point where I
could have an identical (asside from the syntax) entry in
trusted-key-file and trust-anchor-file, and the domain would only
correctly authenticate via trust-anchor-file. I have many other zones
in trusted-key-file, and it is now together with a trust-anchor-file
only holding a single dnskey entry. The domain that was not working is
eleuther.net (which did not work in trusted-key-file), go-beyond.org
works fine and is in the trusted-key-file. Perhaps there is a bug
surrounding the parsing? Sorry I don't have any logs or details of
this, I was a bit frustrated over the time spent debuging it and
didn't want to spend any more time once I fixed it. If you can't think
of any immediate potential problems, I'd be happy to give you more
specifics. I've had similair issues before, but was never certain
where the problem was exactly.

Could you email me the details privately? If you still have them.
I admit the trusted-key BIND format parser is a hack, but it does work
for me, maybe I missed a cornercase.

Best regards,
   Wouter

6

I actually don't have any sensitive data in my DNSSEC setup, so I am
just posting this to the mailling list directly. Now that I think
about it, perhaps the DNSSEC problems with my eleuther.net domain were
causing the timeouts that caused the VPN's resolver to experience a
long enough time out to stop resolving from it. Here is my (now
working) router's Unbound configuration:
<ftp://icadyptes.go-beyond.org/other/unbound/&gt;\. It is a bit messy, and
I don't mind moving to the traditional trust-anchor-file format
entirely. I will change the timeout for now.

My network is generally quite stable, and I doubt it is packet loss. I
could run some tests, but I haven't noticed any abnormally slow
resolves or problems of that nature.

Thanks,
Teran (sega01)