Maintained by: NLnet Labs

[Unbound-users] A few ideas and questions

Teran McKinney
Wed Sep 17 00:02:39 CEST 2008


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