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 <k...@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@lists.isc.org > https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users> >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users