summaryrefslogtreecommitdiff
path: root/doc/arm/Bv9ARM.7.html
blob: 33eeee98a1b822822438cfc4c839c0a0659b7a83 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
<TITLE> Section 7.	Troubleshooting</TITLE></HEAD>
<BODY BGCOLOR="#ffffff">
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=997350">
 </A>
Section 7.	Troubleshooting</H1>
</OL>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997351">
 </A>
7.1	Common Log Messages and What They Mean</H3>
</OL>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997352">
 </A>
lame server</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997353"></A>
<CODE CLASS="grammar_literal">ns named[111]: Lame server on 'www.example.com' (in 'example.com'?): [192.168.0.2].53 'ns2.example.com'</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997354">
 </A>
This is a harmless error message. It means that the server at 192.168.0.2 (<EM CLASS="pathname">
ns2.example.com</EM>
) is listed as a nameserver for &quot;<EM CLASS="pathname">
example.com</EM>
&quot;, but it doesn't really know anything about <EM CLASS="pathname">
example.com</EM>
.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997355">
 </A>
If this is a zone under your control, check each of the nameservers to ensure that they are configured to answer questions properly.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997356">
 </A>
If it's a zone out on the Internet, it would be nice to notify the owners of the domain in question so that they can take a look at it. In practice, though, not many people have time to do this.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997357">
 </A>
bad referral</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997358"></A>
<CODE CLASS="grammar_literal">ns named[111]: bad referral (other.com !&lt; subdomain.other.com)</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997359">
 </A>
This indicates that your nameserver (<EM CLASS="pathname">
ns.example.com</EM>
) queried the nameserver for <EM CLASS="pathname">
example2.com</EM>
 to find out how to get to <EM CLASS="pathname">
subdomain.example2.com</EM>
. The name server <EM CLASS="pathname">
example2.com</EM>
 told your nameserver that <EM CLASS="pathname">
subdomain.example2.com</EM>
 was delegated to some <EM CLASS="pathname">
other.example2.com</EM>
, so your nameserver queried that.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997360">
 </A>
<EM CLASS="pathname">
someother.example2.com</EM>
 didn't think that <EM CLASS="pathname">
subdomain.example2.com</EM>
 had been delegated to it, so it referred your server (<EM CLASS="pathname">
ns.example.com</EM>
) back to the <EM CLASS="pathname">
example2.com</EM>
 nameserver.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997361">
 </A>
not authoritative for</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997362"></A>
<CODE CLASS="grammar_literal">ns named-xfer[111]: [192.168.0.1] not authoritative for example.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997363">
 </A>
This error usually shows up on a slave server. It indicates that the master server is not answering authoritatively for the zone. This usually happens when the zone is rejected (while <CODE CLASS="Program-Process">
named</CODE>
 is loading) on the master server. Check the logs on the master server. If ancount -- 0, you may be pointing at the wrong master server for the zone.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997364">
 </A>
rejected zone</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997365"></A>
<CODE CLASS="grammar_literal">ns named[111]: master zone &quot;example.com&quot; (IN) rejected due to errors (serial111)</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997366">
 </A>
This indicates that the <EM CLASS="pathname">
example.com</EM>
 zone was rejected because of an error in the zone file. Check the lines above this error. <CODE CLASS="Program-Process">
named</CODE>
 will usually tell you what it didn't like and where to find it in the zone file.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997367">
 </A>
no NS RRs found</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997368"></A>
<CODE CLASS="grammar_literal">ns named[111]: Zone &quot;example.com&quot; (file example.com.db): no NS RRs found at zonetop</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997369">
 </A>
The <EM CLASS="pathname">
example.com.db</EM>
 file is missing NS records at the top of the zone (in the SOA section). Check to make sure they exist and that there is white space (spaces or tabs) in front of them. White spaces matter here.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997370">
 </A>
no default TTL set</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997371"></A>
<CODE CLASS="grammar_literal">ns named[111]: Zone &quot;example.com&quot; (file example.com.db): No default TTL set using SOA minimum instead</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997372">
 </A>
You will need to add a <KBD CLASS="Literal-user-input">
$TTL</KBD>
 to the top of the <EM CLASS="pathname">
example.com.db</EM>
 zone file. See RFC 2308, or <A HREF="Bv9ARM.5.html#19693" CLASS="XRef">
Setting TTLs</A>
 for information on how to use <CODE CLASS="grammar_literal">
$TTL</CODE>
.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997373">
 </A>
no root nameserver for class</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997374"></A>
<CODE CLASS="grammar_literal">findns: No root nameservers for class IN?</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997375">
 </A>
Your nameserver is having problems finding the root nameservers. Check your root hints file to make sure it is not corrupted. Also, make sure that your nameserver can reach the Internet.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997376">
 </A>
If you are running an internal root nameserver, make sure it is configured properly and is answering queries.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997377">
 </A>
address already in use</H6>
</UL>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997378"></A>
<CODE CLASS="grammar_literal">ctl_server: bind: Address already in use</CODE>
</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997379">
 </A>
This usually indicates that another copy of BIND is already running. Verify that you have killed old copies of the daemon.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997380">
 </A>
This can also pop up if you originally ran named as &quot;root&quot; and now run it as a regular user. named may have left behind an ndc control socket that is owned by root if it crashed, or was not killed gracefully.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997381">
 </A>
This means that the regular user wouldn't be able to delete it, so it would think named is still running. The solution is to remove any ndc sockets in <EM CLASS="pathname">
/usr/local/etc</EM>
, or <EM CLASS="pathname">
/var/run</EM>
, etc.</P>
</DIV>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997382">
 </A>
7.2	Common Problems</H3>
</OL>
<DIV>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997383">
 </A>
7.2.1	It's not working; how can I figure out what's wrong?</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997384">
 </A>
The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand (see the sample configurations in <A HREF="Bv9ARM.3.html#30164" CLASS="XRef">
Sample Configuration and Logging.</A>
). The log files provide a source of hints and information that can be used to figure out what went wrong and how to fix the problem.</P>
</DIV>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997388">
 </A>
7.3	Incrementing and Changing the Serial Number</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1001230">
 </A>
Zone serial numbers are just numbers--they aren't date related. A lot of people set them to a number that represents a date, usually of the form YYYYMMDDRR. A number of people have been testing these numbers for Y2K compliance and have set the number to the year 2000 to see if it will work. They then try to restore the old serial number. This will cause problems, because serial numbers are used to indicate that a zone has been updated. If the serial number on the secondary server is lower than the serial number on the primary, the secondary server will attempt to update its copy of the zone.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997390">
 </A>
Setting the serial number to a lower number on the primary server than the secondary server means that the secondary will not perform updates to its copy of the zone.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997391">
 </A>
The solution to this is to add 2147483647 (2^31-1) to the number, reload the zone and make sure all secondaries have updated to the new zone serial number, then reset the number to what you want it to be, and reload the zone again.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997392">
 </A>
7.4	Where Can I Get Help?</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1001264">
 </A>
The Internet Software Consortium (ISC) offers a wide range of support and service agreements for BIND and DHCP servers. Four levels of premium support are available and each level includes support for all ISC programs, significant discounts on products and training, and a recognized priority on bug fixes and non-funded feature requests. In addition, ISC offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in BIND and DHCP.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997394">
 </A>
To discuss arrangements for support, contact 
<A HREF="mailto:info@isc.org">info@isc.org</A>
or visit the ISC web page at<BR>
<EM CLASS="URL">
<A HREF="http://www.isc.org/services/support/">http://www.isc.org/services/support/</A></EM>
 to read more.</P>
</DIV>
<DIV>
<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
</DIV>
</BODY>
</HTML>