Name resolution fails if not forwarding

Daniele d.imbrogino at
Wed Jan 9 14:17:53 UTC 2013

This is the scenario.

I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04,
virtualized on VirtualBox.
The network works properly because if I indicate a different server from my
own BIND9 (the first line of '/etc/resolv.conf' is, for example,
`nameserver`) the lookups and any action on the Internet succeed.

BIND9 configuration is the default one.
I deleted all local zones that I added (even if internal lookups worked
correctly). Now there are only default zones (root, localhost,,,
Options are the default ones
options {
    directory "/var/cache/bind";

    dnssec-validation auto;

    auth-nxdomain no;

    listen-on-v6 {any;}

In this situation, if I dig anything the lookup fails, and the log is full
of "lame server" and "FORMERR".

Perhaps the problem is due to the presence of “dnssec-validaton“ line?

2013/1/8 Kevin Darcy <kcd at>

> On 1/8/2013 9:35 AM, Daniele wrote:
>> If I use BIND9 forwarding all the queries not belonging to my local
>> zones, it works.
>> But if I don't forward those queries, `dig` sometimes (and this is weird)
>> fails (with "connection timed out; no servers could be reached") and the
>> logs are full of "lame server", "FORMERR".
>> Why?
> My guess is that your nameserver is having so much trouble resolving
> Internet names that it's thrashing and this is causing intermittent
> slowdowns/failures resolving even names from local zones.
> You might be able to confirm or deny this speculation by looking at how
> many concurrent recursive clients you have (e.g. through rndc).
> If confirmed, this leads to the bigger question of why you're having
> trouble resolving Internet names. "Lame server" is almost certainly a
> problem with the remote nameserver and/or the delegation to that
> nameserver, rather than your nameserver or anything in between. FORMERR, on
> the other hand, might be caused if some intermediate device is mangling
> your packets. Personally, I'd do a packet capture at various points in the
> path and analyze the results. Improper handling of EDNS0 frequently leads
> to these types of symptoms.
>                                     - Kevin
> ______________________________**_________________
> Please visit**listinfo/bind-users<>to unsubscribe from this list
> bind-users mailing list
> bind-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bind-users mailing list