xfrin_messages.mes 14 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.

# No namespace declaration - these constants go in the global namespace
Jelte Jansen's avatar
Jelte Jansen committed
16
# of the xfrin messages python module.
17

18
19
20
% XFRIN_AUTH_LOADZONE sending Auth loadzone for origin=%1, class=%2
There was a successful zone transfer.  We send the "loadzone" command for the
zone to b10-auth.
21

22
23
24
25
26
% XFRIN_AXFR_INCONSISTENT_SOA AXFR SOAs are inconsistent for %1: %2 expected, %3 received
The serial fields of the first and last SOAs of AXFR (including AXFR-style
IXFR) are not the same.  According to RFC 5936 these two SOAs must be the
"same" (not only for the serial), but it is still not clear what the
receiver should do if this condition does not hold.  There was a discussion
27
about this at the IETF dnsext working group:
28
29
30
31
32
33
34
35
36
http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
and the general feeling seems that it would be better to reject the
transfer if a mismatch is detected.  On the other hand, also as noted
in that email thread, neither BIND 9 nor NSD performs any comparison
on the SOAs.  For now, we only check the serials (ignoring other fields)
and only leave a warning log message when a mismatch is found.  If it
turns out to happen with a real world primary server implementation
and that server actually feeds broken data (e.g. mixed versions of
zone), we can consider a stricter action.
37

Jelte Jansen's avatar
Jelte Jansen committed
38
% XFRIN_BAD_MASTER_ADDR_FORMAT bad format for master address: %1
39
The given master address is not a valid IP address.
40

Jelte Jansen's avatar
Jelte Jansen committed
41
% XFRIN_BAD_MASTER_PORT_FORMAT bad format for master port: %1
42
The master port as read from the configuration is not a valid port number.
43

Jelte Jansen's avatar
Jelte Jansen committed
44
% XFRIN_BAD_TSIG_KEY_STRING bad TSIG key string: %1
45
The TSIG key string as read from the configuration does not represent
46
a valid TSIG key. The key is ignored.
47

Jelte Jansen's avatar
Jelte Jansen committed
48
% XFRIN_BAD_ZONE_CLASS Invalid zone class: %1
49
The zone class as read from the configuration is not a valid DNS class.
Jelte Jansen's avatar
Jelte Jansen committed
50
51
52
53

% XFRIN_CC_SESSION_ERROR error reading from cc channel: %1
There was a problem reading from the command and control channel. The
most likely cause is that xfrin the msgq daemon is not running.
54

Jelte Jansen's avatar
Jelte Jansen committed
55
% XFRIN_COMMAND_ERROR error while executing command '%1': %2
56
57
58
There was an error while the given command was being processed. The
error is given in the log message.

Jelte Jansen's avatar
Jelte Jansen committed
59
60
61
62
% XFRIN_CONNECT_MASTER error connecting to master at %1: %2
There was an error opening a connection to the master. The error is
shown in the log message.

63
64
65
% XFRIN_EXITING exiting
The xfrin daemon is exiting.

66
% XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1
67
In an attempt of IXFR processing, the beginning SOA of the first difference
68
69
(following the initial SOA that specified the final SOA for all the
differences) was found.  This means a connection for xfrin tried IXFR
70
and really got a response for incremental updates.
71
72
73
74
75
76
77
78
79
80
81
82

% XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1
Non incremental transfer was detected at the "first data" of a transfer,
which is the RR following the initial SOA.  Non incremental transfer is
either AXFR or AXFR-style IXFR.  In the latter case, it means that
in a response to IXFR query the first data is not SOA or its SOA serial
is not equal to the requested SOA serial.

% XFRIN_IMPORT_DNS error importing python DNS module: %1
There was an error importing the python DNS module pydnspp. The most
likely cause is a PYTHONPATH problem.

83
% XFRIN_INVALID_ZONE_DATA zone %1 received from %2 is broken and unusable
84
85
86
87
The zone was received, but it failed sanity validation. The previous version
of zone (if any is available) will be used. Look for previous
XFRIN_ZONE_INVALID messages to see the exact problem(s).

Jelte Jansen's avatar
Jelte Jansen committed
88
% XFRIN_IXFR_TRANSFER_SUCCESS incremental IXFR transfer of zone %1 succeeded (messages: %2, changesets: %3, deletions: %4, additions: %5, bytes: %6, run time: %7 seconds, %8 bytes/second)
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
The IXFR transfer for the given zone was successful.
The provided information contains the following values:

messages: Number of overhead DNS messages in the transfer.

changesets: Number of difference sequences.

deletions: Number of Resource Records deleted by all the changesets combined,
including the SOA records.

additions: Number of Resource Records added by all the changesets combined,
including the SOA records.

bytes: Full size of the transfer data on the wire.

run time: Time (in seconds) the complete ixfr took.

bytes/second: Transfer speed.

Note that there is no cross-checking of additions and deletions; if the same
RR gets added and deleted in multiple changesets, it is counted each time;
therefore, for each changeset, there should at least be 1 deletion and 1
addition (the updated SOA record).

% XFRIN_IXFR_UPTODATE IXFR requested serial for %1 is %2, master has %3, not updating
The first SOA record in an IXFR response indicates the zone's serial
at the primary server is not newer than the client's.  This is
basically unexpected event because normally the client first checks
the SOA serial by an SOA query, but can still happen if the transfer
is manually invoked or (although unlikely) there is a rapid change at
the primary server between the SOA and IXFR queries.  The client
implementation confirms the whole response is this single SOA, and
aborts the transfer just like a successful case.

Jelte Jansen's avatar
Jelte Jansen committed
123
% XFRIN_MSGQ_SEND_ERROR error while contacting %1 and %2
124
125
126
There was a problem sending a message to the xfrout module or the
zone manager. This most likely means that the msgq daemon has quit or
was killed.
127

128
129
130
% XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER error while contacting %1
There was a problem sending a message to the zone manager. This most
likely means that the msgq daemon has quit or was killed.
131

132
133
134
135
136
137
% XFRIN_NOTIFY_UNKNOWN_MASTER got notification to retransfer zone %1 from %2, expected %3
The system received a notify for the given zone, but the address it came
from does not match the master address in the Xfrin configuration. The notify
is ignored. This may indicate that the configuration for the master is wrong,
that a wrong machine is sending notifies, or that fake notifies are being sent.

Jelte Jansen's avatar
Jelte Jansen committed
138
139
140
141
142
143
% XFRIN_RETRANSFER_UNKNOWN_ZONE got notification to retransfer unknown zone %1
There was an internal command to retransfer the given zone, but the
zone is not known to the system. This may indicate that the configuration
for xfrin is incomplete, or there was a typographical error in the
zone name in the configuration.

144
145
146
% XFRIN_STARTED xfrin started
This informational message is output by xfrin when all initialization
has been completed and it is entering its main loop.
Jelte Jansen's avatar
Jelte Jansen committed
147
148

% XFRIN_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down
149
150
151
There was a keyboard interrupt signal to stop the xfrin daemon. The
daemon will now shut down.

Jelte Jansen's avatar
Jelte Jansen committed
152
153
154
155
% XFRIN_TRANSFER_SUCCESS full %1 transfer of zone %2 succeeded (messages: %3, records: %4, bytes: %5, run time: %6 seconds, %7 bytes/second)
The AXFR transfer of the given zone was successful.
The provided information contains the following values:

156
messages: Number of overhead DNS messages in the transfer.
Jelte Jansen's avatar
Jelte Jansen committed
157
158
159
160
161
162

records: Number of Resource Records in the full transfer, excluding the
final SOA record that marks the end of the AXFR.

bytes: Full size of the transfer data on the wire.

163
run time: Time (in seconds) the complete axfr took.
Jelte Jansen's avatar
Jelte Jansen committed
164

165
bytes/second: Transfer speed.
Jelte Jansen's avatar
Jelte Jansen committed
166

167
168
169
170
171
172
173
% XFRIN_TSIG_KEY_NOT_FOUND TSIG key not found in key ring: %1
An attempt to start a transfer with TSIG was made, but the configured TSIG
key name was not found in the TSIG key ring (configuration option
tsig_keys/keys). The transfer is aborted. The key name that could not be
found is shown in the log message. Check the configuration and the
TSIG key ring.

Jelte Jansen's avatar
Jelte Jansen committed
174
% XFRIN_UNKNOWN_ERROR unknown error: %1
175
176
An uncaught exception was raised while running the xfrin daemon. The
exception message is printed in the log message.
177

178
179
180
181
% XFRIN_XFR_OTHER_FAILURE %1 transfer of zone %2 failed: %3
The XFR transfer for the given zone has failed due to a problem outside
of the xfrin module.  Possible reasons are a broken DNS message or failure
in database connection.  The error is shown in the log message.
182
183
184
185
One common cause of this error could be a locked database; especially when
using sqlite3 where a single transaction involving write operations blocks
any other read or write transactions. This is not a critical error, and
the transfer will be attempted again at the next retry time.
186

187
188
189
190
191
192
193
194
195
196
197
198
199
200
% XFRIN_XFR_PROCESS_FAILURE %1 transfer of zone %2/%3 failed: %4
An XFR session failed outside the main protocol handling.  This
includes an error at the data source level at the initialization
phase, unexpected failure in the network connection setup to the
master server, or even more unexpected failure due to unlikely events
such as memory allocation failure.  Details of the error are shown in
the log message.  In general, these errors are not really expected
ones, and indicate an installation error or a program bug.  The
session handler thread tries to clean up all intermediate resources
even on these errors, but it may be incomplete.  So, if this log
message continuously appears, system resource consumption should be
checked, and you may even want to disable the corresponding transfers.
You may also want to file a bug report if this message appears so
often.
201

202
203
204
% XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 with %3 failed: %4
The XFR transfer for the given zone has failed due to an internal error.
The error is shown in the log message.
205

206
207
208
209
210
211
% XFRIN_XFR_TRANSFER_FALLBACK falling back from IXFR to AXFR for %1
The IXFR transfer of the given zone failed. This might happen in many cases,
such that the remote server doesn't support IXFR, we don't have the SOA record
(or the zone at all), we are out of sync, etc. In many of these situations,
AXFR could still work. Therefore we try that one in case it helps.

Michal 'vorner' Vaner's avatar
Michal 'vorner' Vaner committed
212
% XFRIN_XFR_TRANSFER_PROTOCOL_VIOLATION %1 transfer of zone %2 with %3 failed: %4
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
The XFR transfer for the given zone has failed due to a protocol
error, such as an unexpected response from the primary server.  The
error is shown in the log message.  It may be because the primary
server implementation is broken or (although less likely) there was
some attack attempt, but it can also happen due to configuration
mismatch such as the remote server does not have authority for the
zone any more but the local configuration hasn't been updated.  So it
is recommended to check the primary server configuration.

% XFRIN_XFR_TRANSFER_STARTED %1 transfer of zone %2 started
A connection to the master server has been made, the serial value in
the SOA record has been checked, and a zone transfer has been started.

% XFRIN_ZONE_CREATED Zone %1 not found in the given data source, newly created
On starting an xfrin session, it is identified that the zone to be
transferred is not found in the data source.  This can happen if a
secondary DNS server first tries to perform AXFR from a primary server
without creating the zone image beforehand (e.g. by b10-loadzone).  As
of this writing the xfrin process provides backward compatible
behavior to previous versions: creating a new one in the data source
not to surprise existing users too much.  This is probably not a good
idea, however, in terms of who should be responsible for managing
zones at a higher level.  In future it is more likely that a separate
zone management framework is provided, and the situation where the
given zone isn't found in xfrout will be treated as an error.

239
240
241
242
243
244
% XFRIN_ZONE_INVALID Newly received zone %1/%2 fails validation: %3
The zone was received successfully, but it failed validation. The problem
is severe enough that the new version of zone is discarded and the old version,
if any, will stay in use. New transfer will be attempted after some time.
The problem needs to be fixed in the zone data on the remote server.

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
% XFRIN_ZONE_MULTIPLE_SOA Zone %1 has %2 SOA RRs
On starting an xfrin session, it is identified that the zone to be
transferred has multiple SOA RRs.  Such a zone is broken, but could be
accidentally configured especially in a data source using "non
captive" backend database.  The implementation ignores entire SOA RRs
and tries to continue processing as if the zone were empty.  This
means subsequent AXFR can succeed and possibly replace the zone with
valid content, but an IXFR attempt will fail.

% XFRIN_ZONE_NO_SOA Zone %1 does not have SOA
On starting an xfrin session, it is identified that the zone to be
transferred does not have an SOA RR in the data source.  This is not
necessarily an error; if a secondary DNS server first tries to perform
transfer from a primary server, the zone can be empty, and therefore
doesn't have an SOA.  Subsequent AXFR will fill in the zone; if the
attempt is IXFR it will fail in query creation.

% XFRIN_ZONE_SERIAL_AHEAD Serial number (%1) for %2 received from master %3 < ours (%4)
The response to an SOA query prior to xfr indicated that the zone's
SOA serial at the primary server is smaller than that of the xfrin
client.  This is not necessarily an error especially if that
particular primary server is another secondary server which hasn't got
the latest version of the zone.  But if the primary server is known to
be the real source of the zone, some unexpected inconsistency may have
happened, and you may want to take a closer look.  In this case xfrin
doesn't perform subsequent zone transfer.
271
272
273
274
275
276

% XFRIN_ZONE_WARN Newly received zone %1/%2 has a problem: %3
The zone was received successfully, but when checking it, it was discovered
there's some issue with it. It might be correct, but it should be checked
and possibly fixed on the remote server. The problem is described in the
message. The problem does not stop the zone from being used.