Strange behavior with AAAA record

Unbound
1

Hi,

I have been using Unbound 1.01 for about a week and have tested it on
multiple boxes. It has a very rich feature set, ran perfectly on a 486
with 16MB of RAM (needed to set it to use less caching memory though),
and the configuration file is awesome.

However, I think I may have uncovered a bug in Unbound and/or iputils.
When trying to ping6 my most recently created subdomain from Zoneedit
(icadyptes.eleuther.net; currently waiting for the domain to transfer
to Joker so I can point it to my VPS with NSD and have full IPv6
glue), my boxes resolving to an Unbound daemon spike in CPU usage and
get about 3 pings through in 20 seconds. The latency is fine and there
is no packet loss, however. Drill shows the correct AAAA record which
I can ping6 directly without problems. If I use OpenDNS or the hosts
file manually I do not have this issue with ping6. Other domains on
Zoneedit with AAAA records work perfectly (icadyptes.go-beyond.org,
{,www.}go-beyond.org, foureightysix.go-beyond.org,
{,www.}eleuther.net) with ping6 and Unbound.

Setting Zoneedit's nameserver in resolv.conf or the IP that NSD
resides on causes no such oddities while ping6'ing. This strange
behavior only occurs when using Unbound. I would also think that
iputil's ping6 should not spike the CPU usage so much whatever DNS
information it is getting.

Here is output of Drill comparing Unbound and OpenDNS' reponse:

[root@virtualgnu etc]# drill icadyptes.eleuther.net aaaa @::1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51355
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;; icadyptes.eleuther.net. IN AAAA

;; ANSWER SECTION:
icadyptes.eleuther.net. 4328 IN AAAA 2001:470:3:e::1123:5813

;; AUTHORITY SECTION:
eleuther.net. 7016 IN NS ns14.zoneedit.com.
eleuther.net. 7016 IN NS ns2.zoneedit.com.

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: ::1
;; WHEN: Fri Aug 1 21:38:00 2008
;; MSG SIZE rcvd: 117

[root@virtualgnu etc]# drill icadyptes.eleuther.net aaaa @208.67.222.222
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 6759
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; icadyptes.eleuther.net. IN AAAA

;; ANSWER SECTION:
icadyptes.eleuther.net. 7200 IN AAAA 2001:470:3:e::1123:5813

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 197 msec
;; SERVER: 208.67.222.222
;; WHEN: Sat Aug 2 00:03:45 2008
;; MSG SIZE rcvd: 68

Perhaps this could be related to the usage of the short hand '::' in
the AAAA record, with Unbound not properly reformatting the response
from Zoneedit? Or maybe it is just a bug in iputils? Other utilities
(telnet, Arch Linux package manager) seem to work fine with Unbound's
response though.

Any ideas, suggestions, or anything else I could try?

Thanks,
Teran (sega01)

2

Any ideas, suggestions, or anything else I could try?

Compare straces of both ping runs?

O.

3

* Teran McKinney:

Perhaps this could be related to the usage of the short hand '::' in
the AAAA record, with Unbound not properly reformatting the response
from Zoneedit?

The :: is added during presentation, it's not on the wire.

It looks like the problem is with the reverse lookup for
2001:470:3:e::1123:5813, which is broken. Apparently, Unbound tries
harder to get a resolution, which takes more time and slows ping6 down.

4

Sorry Florian, I accidentally sent this directly to just you and not to the ML.

5

* Teran McKinney:

There are 4 instances of "::ffff:0.0.0.0" in the
icadyptes.eleuther.net dump and none from one that works fine. I am
suprised that it works when using Zoneedit's servers directly but not
when through Unbound.

They refuse the reverse lookup, avoiding the timeout (just guessing).

6

Florian Weimer wrote:

* Teran McKinney:

There are 4 instances of "::ffff:0.0.0.0" in the
icadyptes.eleuther.net dump and none from one that works fine. I am
suprised that it works when using Zoneedit's servers directly but not
when through Unbound.

They refuse the reverse lookup, avoiding the timeout (just guessing).

There is only one server that will answer for the reverse zone you ask
for. It answers (sometimes) after maybe 3 seconds. Unbound has to wait
for that.

Also that remote server has recursion enabled, which it should not have.
~ When it does answer, I saw answers that contained failures.

I understand you want an answer faster, but there was no answer that
unbound can give you, except by giving up faster.

The only solution I can think of is by giving up quicker. That means
this poor 3 seconds slow server with lots of dropped packets never gets
to say anything, when it has useful data to reply.

Best regards,
~ Wouter