One A record fails on one server on Sunday evening
Josh Luthman
The server having the problem is CentOS 4.4 running bind 9.2.4
The second server configured similarly is CentOS 3.9 also running bind 9.2.4.
There is one A record on Godaddy's DNS servers that fails look ups on the 4.4 server start around 7PM EST Sunday. I have been able to solve this each Monday morning by issuing the commands (rndc reload && /etc/init.d/named restart).
I have not had to do this on the second 3.9 server.
I am looking for any suggestions or ideas to help fix this issue. Thanks in advance!
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
"When you have eliminated the impossible, that which remains, however improbable, must be the truth."
--- Sir Arthur Conan Doyle
Jeremy C. Reed
> advance!
To get good help, you may want to tell us what the issue is. Provide
real names and show your real tests. Also the version of BIND you are
using is out of date and is no longer supported.
Josh Luthman
The command dig mail.alexandertelecominc.com @firstserver times out. Not sure what else I can provide that would help.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
"When you have eliminated the impossible, that which remains, however improbable, must be the truth."
--- Sir Arthur Conan Doyle
Bill Larson
> --000e0cd32f54da30b8047764ddcc
> Content-Type: text/plain; charset=ISO-8859-1
>
> The issue is that the A record no longer gets resolved.
>
> The command dig mail.alexandertelecominc.com @firstserver times out. Not
> sure what else I can provide that would help.
Well, when you are querying this "firstserver" (whatever that is - giving us
a fully qualified domain name would be helpful), it times out. The DNS
server on this "firstserver" isn't answering the query.
"Not sure what else I can provide that would help". You don't give us much
to work with.
Bill Larson
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> "When you have eliminated the impossible, that which remains, however
> improbable, must be the truth."
> --- Sir Arthur Conan Doyle
>
>
> On Mon, Nov 2, 2009 at 10:13 AM, Jeremy C. Reed <jr...@isc.org> wrote:
>
> > > I am looking for any suggestions or ideas to help fix this issue.
Thanks
> > in
> > > advance!
> >
> > To get good help, you may want to tell us what the issue is. Provide
> > real names and show your real tests. Also the version of BIND you are
> > using is out of date and is no longer supported.
>
> --000e0cd32f54da30b8047764ddcc
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> The issue is that the A record no longer gets resolved.<br><br>The command
=
> dig <a
href=3D"http://mail.alexandertelecominc.com">mail.alexandertelecomin=
> c.com</a> @firstserver times out.=A0 Not sure what else I can provide that
=
> would help.<br>
>
> <br>Josh Luthman<br>Office: 937-552-2340<br>Direct: 937-552-2343<br>1100
Wa=
> yne St<br>Suite 1337<br>Troy, OH 45373<br><br>"When you have
eliminate=
> d the impossible, that which remains, however improbable, must be the
truth=
> ."<br>
>
> --- Sir Arthur Conan Doyle<br>
> <br><br><div class=3D"gmail_quote">On Mon, Nov 2, 2009 at 10:13 AM, Jeremy
=
> C. Reed <span dir=3D"ltr"><<a
href=3D"mailto:jr...@isc.org">jr...@isc.or=
> g</a>></span> wrote:<br><blockquote class=3D"gmail_quote"
style=3D"borde=
> r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-
le=
> ft: 1ex;">
>
> <div class=3D"im">> I am looking for any suggestions or ideas to help
fi=
> x this issue.=A0 Thanks in<br>
> > advance!<br>
> <br>
> </div>To get good help, you may want to tell us what the issue is.
Provide<=
> br>
> real names and show your real tests. Also the version of BIND you are<br>
> using is out of date and is no longer supported.</blockquote></div><br>
>
> --000e0cd32f54da30b8047764ddcc--
>
--
Josh Luthman
Starting ~7PM EST Sunday evening the command
dig mail.alexandertelecominc.com @74.218.88.168 #fails
dig mail.alexandertelecominc.com @4.2.2.2 #works
until I issue
rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
"When you have eliminated the impossible, that which remains, however improbable, must be the truth."
--- Sir Arthur Conan Doyle
Jeremy C. Reed
> dig mail.alexandertelecominc.com @74.218.88.168 #fails
What does "fails" mean?
> dig mail.alexandertelecominc.com @4.2.2.2 #works
>
> until I issue
>
> rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server
Check named logs and look at named cache before you reload (next time).
Bill Larson
> Let me say it this way...
>
> Starting ~7PM EST Sunday evening the command
>
> dig mail.alexandertelecominc.com @74.218.88.168 #fails
> dig mail.alexandertelecominc.com @4.2.2.2 #works
>
> until I issue
>
> rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server
Ok, we're getting somewhere. Do the logs on your 74.218.88.168 server tell
you anything? Is there anything unusual logged prior to ~7PM EST Sunday?
Again, without knowing more there is no way that we can identify exactly
what occurred to cause the query to fail. Also, even with all the
information that is available, we may still not be able to identify the
problem.
Then again, is this a one time situation or does it occur regularly?
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> "When you have eliminated the impossible, that which remains, however
> improbable, must be the truth."
> --- Sir Arthur Conan Doyle
I don't know exactly why, but this statement struck me. Sherlock Holmes
should never have been susceptable to this logical falicy.
The opposite of "the impossible" is "the possible", but no matter how
improbable this "possible" may be, this is not the same as "truth".
A counter example, something occurs and there are three posited causes. One
cause is "impossible" and can be eliminated. This leaves the other two
possibilities, no matter how improbable. This does NOT make both, or
either, of these possibilities "the truth".
--
Josh Luthman
Currently there are no logs - what categories would you suggest I start logging?
The server comes back with simply no response. It just times out. It resolves every other record I could think of to ask it. Also, it may or may not be relevant but if I ssh in I can ping (and hence resolve) the mail.alexandertelecominc.com.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
"When you have eliminated the impossible, that which remains, however improbable, must be the truth."
--- Sir Arthur Conan Doyle
Barry Margolin
Josh Luthman <jo...@imaginenetworksllc.com> wrote:
> It has happened the last 4 or 5 Sunday nights.
>
> Currently there are no logs - what categories would you suggest I start
> logging?
>
> The server comes back with simply no response. It just times out. It
> resolves every other record I could think of to ask it. Also, it may or may
> not be relevant but if I ssh in I can ping (and hence resolve) the
> mail.alexandertelecominc.com.
When it's failing, make a cache dump. Check the cache for the NS
records of the domain, and the A records for the nameservers.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Josh Luthman
rndc dumpdb on the first execute took a few seconds, but after updatedb && locate named_dump.db (as it suggested it would store it there) returns nothing. The man page for rndc doesn't say anything about these commands either.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
"When you have eliminated the impossible, that which remains, however improbable, must be the truth."
--- Sir Arthur Conan Doyle
In article <mailman.872.1257181...@lists.isc.org>,
Josh Luthman <jo...@imaginenetworksllc.com> wrote:
> It has happened the last 4 or 5 Sunday nights.
>
> Currently there are no logs - what categories would you suggest I start
> logging?
>
> The server comes back with simply no response. It just times out. It
> resolves every other record I could think of to ask it. Also, it may or may
> not be relevant but if I ssh in I can ping (and hence resolve) the
> mail.alexandertelecominc.com.
When it's failing, make a cache dump. Check the cache for the NS
records of the domain, and the A records for the nameservers.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Mark Andrews
In message <961092e10911030921x3ff...@mail.gmail.com>, Josh
> How do I export the cache dump?
>
> rndc dumpdb on the first execute took a few seconds, but after updatedb &&
> locate named_dump.db (as it suggested it would store it there) returns
> nothing. The man page for rndc doesn't say anything about these commands
> either.
You need to look at either of the following locations. The latter
is used when <dump-file> contains a absolute path.
<chroot><directory><dump-file>
<chroot><dump-file>
<chroot> (as specified by -t on the command line)
<directory> (as specified by the "directory" clause in named.conf
and defaults to ".")
<dump-file> (as specified by the "dump-file" clause in named.conf and
defaults to "named_dump.db")
e.g.
<chroot> = "/choot"
<directory> = "/var/named"
<dump-file> = "named_dump.db"
gives "/choot/var/named/named_dump.db"
<chroot> = "/var/named"
<directory> = "."
<dump-file> = "named_dump.db"
gives "/var/named/./named_dump.db"
<chroot> = (not set as -t not used)
<directory> = "/var/named"
<dump-file> = "named_dump.db"
gives "/var/named/named_dump.db"
<chroot> = "/chroot"
<directory> = "/var/named"
<dump-file> = "/data/named_dump.db"
gives "/chroot/data/named_dump.db"
Mark
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> "When you have eliminated the impossible, that which remains, however
> improbable, must be the truth."
> --- Sir Arthur Conan Doyle
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org