Name resolution fails if not forwarding
d.imbrogino at gmail.com
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 188.8.131.52`) 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
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 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".
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users