Name resolution fails if not forwarding

[Daniele]

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 8.8.8.8`) 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,
127.in-addr.arpa, 0.in-addr.arpa, 255.in-addr.arpa).
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".

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


2013/1/8 Kevin Darcy <kcd at chrysler.com>

>
> 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 https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130109/c82f772c/attachment.html>