named quits resolving certain domains

Wed Jan 24 00:03:28 UTC 2001

Okay, so you're not forwarding currently, which eliminates a whole class of
problems involving inability to talk to your forwarders.

Why would you think that forwarding would make more sense in your situation (i.e.
an Internet-connected box)? Do you have an ultrafast connection to a capacious,
reliable nameserver-farm with a consistently rich cache? If not, then it's likely
that overall you're doing better performance-wise resolving names directly than
you would be if you were constantly adding extra resolver "hops" through
forwarders. Frankly, I'm not particularly enamored of using forwarding for
performance reasons. If you go this route, however, at least make sure you define
"forward first" (the default) instead of "forward only", so you won't be dead in
the water if the forwarders go away.

As for your original problem, at this point I'd recommend turning on nameserver
debugging and running some test queries. The debug output should show you what
nameservers are being contacted, whether there are any retries, etc.

- Kevin

mike miller wrote:

> Here is a snippet from the named.conf file:
>
> options {
>         directory "/var/named/";
>
>         // query-source address * port 53;
> };
>
> logging {
>         channel normal_logs {
>                 severity info;                  // level 3 debugging to
> file
>                 file "/var/adm/named";          // foo
>                 print-time yes;                 // timestamp log entries
>                 print-category yes;             // print category name
>                 print-severity yes;             // print severity level
>         };
>         category default { normal_logs; };
> };
>
> zone "." {
>         type hint;
>         file "cache.ndb";
> };
>
> zone "0.0.127.in-addr.arpa" {
>         type master;
>         file "networks/127.0.0.ndb";
> };
>
> zone "66.74.209.in-addr.arpa" {
>         type master;
>         file "networks/209.74.66.ndb";
> };
>
> zone "laketoyota.com" {
>         type master;
>         file "master/laketoyota.com.ndb";
> };
>
> There are about 100 more domains in this file.
> The cache.ndb file is the named.root text as taken off of the internic
> ftp site FTP.RS.INTERNIC.NET.
> This is the master server conf running on a sparc E3500 with 2 gig of
> ram and 4 processors.
> We are not using forwarding at this time, but from looking at the
> documentation it would seem to make much more sense.
> Also I have very limited security and am looking at adding an ACL for
> zone transfers, would there be any other security concerns?
>
> Kevin Darcy wrote:
> >
> > If you insist on using nslookup, please at least use "-debug" so we can see
> > what's going on. Better yet, use "dig".
> >
> > Other than lameness, I don't see anything obviously wrong with
> > travelnewsletter.com or nancysnotions.com (I didn't check all of the others
> > in your list). I don't think lameness alone would absolutely prevent you
> > from resolving names in the domain -- at least, it doesn't stop my
> > nameservers from resolving those names. So there is likely something else
> > going on. More diagnostics from the lookup tool (as recommended above) might
> > help, but ultimately you might have to turn on nameserver debugging to get
> > to the root cause of the problem.
> >
> > How is your nameserver configured, by the way? Any chance you could post the
> > named.conf? Specifically, I'd be interested in knowing whether it is
> > forwarding to resolve Internet names or just using an Internet root hints
> > file.
> >
> > - Kevin
> >
> > mike miller wrote:
> >
> > > Here is some more information, Joy is out of the office today and I told
> > > her I would help her out today.
> > > The sparc dns server is setup as the master while the intel boxes are
> > > slaves.
> > > The following is typical of any of the three name servers:
> > >
> > > [root at ndtc3500 /tmp]# nslookup travelnewsletter.com
> > > Server:  ns.stellarnet.com
> > > Address:  209.74.65.10
> > >
> > > *** ns.stellarnet.com can't find travelnewsletter.com: Non-existent
> > > host/domain
> > > [root at ndtc3500 /tmp]# nslookup travelnewsletter.com 134.129.111.111
> > > Server:  ns1.NoDak.edu
> > > Address:  134.129.111.111
> > >
> > > Non-authoritative answer:
> > > Name:    travelnewsletter.com
> > > Address:  216.242.58.254
> > >
> > > Only the off site name sever will resolve the query.  If I restart named
> > > sometimes it will resolve the above example but then it quits resolving
> > > it.
> > > This is named logging output:
> > > 20-Jan-2001 06:32:18.924 default: info: ns_forw:
> > > query(travelnewsletter.com) All possible A RR's lame
> > > 20-Jan-2001 10:42:20.066 default: info: ns_forw:
> > > query(travelnewsletter.com) All possible A RR's lame
> > > Other domains that the same or similar logging (lame-servers: info: Lame
> > > server on 'nancysnotions.com' (in 'nancysnotions.com'?):
> > > [12.127.16.67].53 'RMTU.MT.RS.ELS-GMS.ATT.NET
> > >
> > > There are a few other domains that I am also having problems with:
> > > womensforum.com
> > > edventures.com
> > > wilnet1.com
> > > nancysnotions.com
> > > mailzilla.net
> > > myrealbox.com
> > > silverclicks.com
> > > classicorclunker.com
> > > esperanto.nu
> > > and many others... which i can get to resolve by using some one else's
> > > name server.
> > > Most other domains resolve okay, the domains that These servers are
> > > authoritative all work and all of the popular domains like yahoo, cnn,
> > > microsoft, netscape all seem to be fine...????
> > >
> > > Mike
> > >
> > > On Fri, Jan 19, 2001 at 11:45:14AM -0600, Joy Newland wrote:
> > > > The problem that I am having happens to all three,  named resolves for
> > > > awhile and than quits.  It is very inconsistent, it will quit resolving
> > > > some domain, but when I go off site it works every time.  Any ideas?
> > >
> > > I'm afraid you'll have to give some more details. Specifically, what
> > > does "quit resolving" mean?
> > >
> > > Does the nameserver process stop running? Does it stay running but
> > > when queried does it not send an answer? Does it send an answer but it's
> > > one which you know to be incorrect?
> > >
> > > Can you give a real example, with a real domain name and real debugging
> > > logging output?
> > >
> > > james
> > > --
> > > James Raftery (JBR54)
> > >   "Managing 4000 customer domains with BIND has been a lot like
> > >    herding cats." - Mike Batchelor, on dns at list.cr.yp.to.