Maintained by: NLnet Labs

[Unbound-users] Release 0.7.2

W.C.A. Wijngaards
Wed Jan 30 15:48:35 CET 2008

Hash: SHA1

Hi Alexander,

Alexander Gall wrote:
| One thing I've noticed is a slight difference in the way BIND and
| unbound deal with dead servers at delegation points.  There was one
| domain for which all name servers were unreachable.  Both caches
| eventually marked these servers as bad and returned "SERFVAIL" quickly
| (for as long as they cache this type of information), but I had the
| impression that BIND was timing out on the queries for a longer period
| of time than unbound before marking the servers as bad.

Unbound gives up *this* query quickly. The server is not marked bad yet,
but further attempts are only done on subsequent queries. The first try
fails quickly, but later tries get more time. 2 minutes max timeout,
then the server is marked bad.

|> I think I'll demote the error message, as it does not bother the
|> resolver operator. What do you think? Would you like to have the
|> addresses printed to the log anyway?
| Yes, that would be useful and yes, you can move the message itself to
| a higher verbosity level.  Speaking of logging: I think I prefer the
| modular approach to logging used by BIND.  If you only have a
| verbosity level to tune, it can be hard to get to certain information
| without having to collect vast amounts of unwanted information as
| well.  Verbosity 2 is already so verbose that I don't want to use it
| on a regular basis.

OK have bumped it to verbosity 2. Have also added remote address info to
the error messages. (in svn trunk).

| What about classifying all messages and let the user set the verbosity
| for each class (which is essentially what BIND does)?  I don't mind
| much if there is only a single log file, as long as the messages are
| tagged with the class so I can pick out what I need with simple tools.
| In general, what I would find exetremely useful (and what I've been
| missing so much with BIND) is a catalog of log messages, possibly
| including additional information what events can cause a message to be
| generated.  If you're going to do this, please add unique tags for
| every message, so you can change the message text in later releases
| but still identify the message itself.
| I have this Perl script that analyzes my BIND logs and I have to
| change it with every release of BIND because they often change the
| message texts.

Nice idea. Some type names and a verbosity value for each.
I'll think about it. It would mean a bit of a revision of the logging

The trouble is keeping such a catalog up to date. Maybe
source-code-annotation can help here :-)

Best regards,
~   Wouter
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -