named quits resolving certain domains
mike miller
mikem at ndtel.com
Wed Jan 24 16:16:53 UTC 2001
Today I am still having the problem of not being able to resolve
domains. I used the nslookup -debug command to obtain the following:
[root at ns1 named]# nslookup -debug triton.net
;; res_nmkquery(QUERY, 2.5.198.205.in-addr.arpa, IN, PTR)
------------
Got answer:
HEADER:
opcode = QUERY, id = 41603, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion
avail.
questions = 1, answers = 1, authority records = 3, additional
= 3
QUESTIONS:
2.5.198.205.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 2.5.198.205.in-addr.arpa
name = ns1.stellarnet.com
ttl = 86400 (1D)
AUTHORITY RECORDS:
-> 5.198.205.in-addr.arpa
nameserver = ns.stellarnet.com
ttl = 86400 (1D)
-> 5.198.205.in-addr.arpa
nameserver = ns1.stellarnet.com
ttl = 86400 (1D)
-> 5.198.205.in-addr.arpa
nameserver = ns2.stellarnet.com
ttl = 86400 (1D)
ADDITIONAL RECORDS:
-> ns.stellarnet.com
internet address = 209.74.65.10
ttl = 86400 (1D)
-> ns1.stellarnet.com
internet address = 205.198.5.2
ttl = 86400 (1D)
-> ns2.stellarnet.com
internet address = 209.74.65.15
ttl = 86400 (1D)
------------
Server: ns1.stellarnet.com
Address: 205.198.5.2
;; res_nmkquery(QUERY, triton.net, IN, A)
------------
Got answer:
HEADER:
opcode = QUERY, id = 41604, rcode = SERVFAIL
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional
= 0
QUESTIONS:
triton.net, type = A, class = IN
------------
;; res_nmkquery(QUERY, triton.net.stellarnet.com, IN, A)
------------
Got answer:
HEADER:
opcode = QUERY, id = 41605, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion
avail.
questions = 1, answers = 0, authority records = 1, additional
= 0
QUESTIONS:
triton.net.stellarnet.com, type = A, class = IN
AUTHORITY RECORDS:
-> stellarnet.com
ttl = 86400 (1D)
origin = ns.stellarnet.com
mail addr = hostmaster.stellarnet.com
serial = 199902043
refresh = 10800 (3H)
retry = 3600 (1H)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
------------
*** ns1.stellarnet.com can't find triton.net: Non-existent host/domain
Why does it say triton.net.stellarnet.com when its only triton.net. I
then did a dig on triton.net and it produced the following:
[root at ns1 named]# dig triton.net
; <<>> DiG 8.2 <<>> triton.net
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; triton.net, type = A, class = IN
;; ANSWER SECTION:
triton.net. 13h10m45s IN A 209.172.0.5
;; AUTHORITY SECTION:
triton.net. 1d20h57m7s IN NS NS2.triton.net.
triton.net. 1d20h57m7s IN NS NS1.triton.net.
;; ADDITIONAL SECTION:
NS2.triton.net. 1d20h57m7s IN A 209.172.0.8
NS1.triton.net. 1d20h57m7s IN A 209.172.0.5
;; Total query time: 1 msec
;; FROM: ns1.stellarnet.com to SERVER: default -- 205.198.5.2
;; WHEN: Wed Jan 24 10:15:31 2001
;; MSG SIZE sent: 28 rcvd: 112
Then I did another nslookup and it worked???
very confusing??
[root at ns1 named]# nslookup triton.net
Server: ns1.stellarnet.com
Address: 205.198.5.2
Non-authoritative answer:
Name: triton.net
Address: 209.172.0.5
Kevin Darcy wrote:
>
> 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.
More information about the bind-users
mailing list