On 04/03/2012 02:30 PM, Barry Margolin wrote:
In article<mailman.421.1333467523.63724.bind-us...@lists.isc.org>,
Keith Burgoyne<ke...@silverorange.com> wrote:
On 04/03/2012 11:14 AM, Barry Margolin wrote:
In article<mailman.419.1333434497.63724.bind-us...@lists.isc.org>,
Chuck Swiger<cswi...@mac.com> wrote:
On 4/2/2012 10:37 PM, Keith Burgoyne wrote:
[ ... ]
I've recently replaced the master server at 24.222.7.11, and am now
running
bind 9.7.3.
My question is: I keep seeing log entries like
Apr 2 23:24:17 clementine named[5870]: lame server resolving
'comuna.silverorange.com' (in 'silverorange.com'?): 24.222.7.12#53
Apr 2 23:24:01 clementine named[5870]: lame server resolving 'veseys.com'
(in
'veseys.com'?): 24.222.7.12#53
and the list goes on. I don't get a lot, probably a few a minute. But
where
do
they come from?
Does the following help:
http://www.dnsvalidation.com/reports/4f7a96b37d79ee3769000012
http://www.dnsvalidation.com/reports/4f7a97bd7d79ee3d4200000c
ns3.silverorange.com seems to be down, and the other two nameservers being
Since the log message is specifically about ns1, how could ns3's status
be relevant?
listed aren't responding to TCP port 53.
Why would clementine be trying TCP? His server appears to support
EDNS0, so it shouldn't need it.
I'm not saying this isn't a problem, but I don't think it would cause
this symptom.
@Chuck: I've sorted out the TCP issue with ns2. I'm not sure why the
tests are failing for ns3, though. I can dig successfully on it from a
variety of networks, using both TCP and UDP. I re-ran the tests, and ns1
seems to check out.
@Barry: The previous sysadmin set some of our NS entries on some of our
domains in no particular order. As a result, some of the domains list
the master (ns1.silverorange.com) as the second or third entry. Not sure
if that matters. I'm correcting that now, and will know if that makes a
difference a little later.
There's no significance to order of any records in DNS. By default,
BIND shuffles them each time it answers, to get simple load balancing
(unless the client sorts them). And client nameservers use NS records
by remembering response times, and preferring the faster servers (a
simple form of GSLB).
If a server doesn't respond, you don't get a "lame server" message, it
just goes on to the next server. And it will be remembered as a slow
server, so it won't be tried again for a while.
I think I have narrowed down the problem to an issue with my internal
DNS. ns1.silverorange.com is split into two separate views: internal and
external. Obviously, internal handles all local hostnames and allows for
recursive look ups to local clients. External blocks recursive lookups
for all domains not hosted by us.
By enabling "querylog yes;" in named.conf, I could see that lame errors
appear to be generated only by requests for domains we host that live in
the external view, made from the internal side. For example:
Apr 4 17:55:24 clementine named[22480]: client 192.168.0.254#34358:
view internal: query: silverorange.com IN A -EDC (192.168.0.12)
Apr 4 17:55:24 clementine named[22480]: lame server resolving
'silverorange.com' (in 'silverorange.com'?): 24.222.7.12#53
Why would using the internal view cause a lame error?
Thanks again for your help!
_______________________________________________
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
