[Unbound-users] Strange SERVFAIL from unbound

[Wouter Wijngaards]

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

Hi Aaron,

Aaron Hopkins wrote:
> So unbound just cares that it has a valid address for a given nameserver,
> not that any of them are A, even if it wants to use IPv4?  If so, this
> seems
> problematic.

Yes this is a bug.  I have fixed it in svn trunk right now, and it is
ready for the 1.1.0 release.

> If I have "ip6: no" in the config, is there a reason it is handling AAAA at
> all?

Yes, because if there are only AAAA addresses for the nameservers, but
no A addresses, then the zone is unreachable and we should not go back
to the TLD servers to get a new delegation.  Also, more importantly I
guess, the reverse for ip4: no configurations.

I have fixed in trunk that it fetches A when it needs them.
And also the inverted bug for people in ipv6 only environments.

> And if it matters, zen.spamhaus.org is a strange zone, in that it is served
> by rbldnsd in lazy/minimal-answers mode that doesn't bother to fill out an
> authoritative section.  This apparently saves a lot of bandwidth, and the
> only claimed operational difference is that they have to wait longer for
> recursive servers to notice nameserver changes.

Interesting.

> the time, and I didn't leave logging enabled over the weekend, as the logs
> grow way too quickly on this active nameserver.

Thanks for the information!

> I'll set up a testbed to try and reproduce.

You can run svn trunk or 1.1.0 release on your production, so it does
not suffer the problem.

>> If it happens again can you query with dig +norec a.ns.spamhaus.org ?
>> And dig +norec +cdflag +dnssec a.ns.spamhaus.org ?
> 
> I tried this out while it was operating normally, and it showed different
> TTLs on A and AAAA:
> 
> a.ns.spamhaus.org.      8871    IN      A       194.109.9.7
> a.ns.spamhaus.org.      8871    IN      A       192.150.94.204
> a.ns.spamhaus.org.      10299   IN      AAAA    2001:7b8:3:1f:0:2:53:1
> 
> Also, only 3 of the nameservers offer either A or AAAA results with just
> +norec.  I have to add +cdflag +dnssec to get As for all 22 nameservers.
> And for some reason, the AAAAs all have longer TTLs than the As.

So, do I understand correctly, that you only did +norec queries (any
query without +norec updated the cache so could invalidate further
results), and that you only got replies for most of the nameservers with
 +norec +cdflag +dnssec ?

Seems like they are marked as bogus.  But spamhaus is not DNSSEC signed?

If they are really marked bogus for some mysterious reason, then the
1.1.0 version will even stronger reject it; 1.1.0 does not query
nameservers with bogus addresses. But 1.0.2 did query bogus addresses,
so it isn't really the reason things are wrong for you.

The reason that things are going wrong is the TTL for A records much
lower than AAAA records.  This is also exactly what I fixed for.  I do
not really understand this massive difference in A and AAAA time values.
  It could be 'coincidence' in the lookups.  Jaco told me a smaller zone
had the problem more often, which supports the randomness (more likely
with less records).

I hope the fix works for you, let me know if you get new troubles.

By the way, about the huge log files, the upcoming 1.1.0 release has a
remote control tool where you can change the verbosity online, once the
problem has happened, to very high, then log a couple queries, and turn
verbosity back down again.

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

iEYEARECAAYFAkkisaoACgkQkDLqNwOhpPhF4ACgjQzPVoqgaTNKpCwtgN/FUaHx
evAAn2AOh+U/waalaR+wqKVe420KjdLH
=ou1p
-----END PGP SIGNATURE-----