BIND 10 trac1037, updated. 83f58ed580b457a424d4279d1deb8e698a0fcc9d [trac1037] Message ID modifications
BIND 10 source code commits
bind10-changes at lists.isc.org
Fri Jun 24 10:11:56 UTC 2011
The branch, trac1037 has been updated
via 83f58ed580b457a424d4279d1deb8e698a0fcc9d (commit)
via 34698cb3c81a724da952e6d0059572c4536e3a0b (commit)
via 0494c88638d05f2c2004cf897f6360b06400b6c1 (commit)
from fef88019d325474471a353304499e7919023912e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 83f58ed580b457a424d4279d1deb8e698a0fcc9d
Author: Stephen Morris <stephen at isc.org>
Date: Fri Jun 24 11:11:33 2011 +0100
[trac1037] Message ID modifications
commit 34698cb3c81a724da952e6d0059572c4536e3a0b
Author: Stephen Morris <stephen at isc.org>
Date: Fri Jun 24 10:48:14 2011 +0100
[trac1037] Remove $PREFIX directive
commit 0494c88638d05f2c2004cf897f6360b06400b6c1
Author: Stephen Morris <stephen at isc.org>
Date: Fri Jun 24 10:47:19 2011 +0100
[trac1037] Rename resolvedef.mes resolve_messages.mes
-----------------------------------------------------------------------
Summary of changes:
src/lib/resolve/Makefile.am | 12 ++--
src/lib/resolve/recursive_query.cc | 42 ++++++------
src/lib/resolve/resolve_log.h | 2 +-
.../{resolvedef.mes => resolve_messages.mes} | 71 ++++++++++----------
4 files changed, 63 insertions(+), 64 deletions(-)
rename src/lib/resolve/{resolvedef.mes => resolve_messages.mes} (77%)
-----------------------------------------------------------------------
diff --git a/src/lib/resolve/Makefile.am b/src/lib/resolve/Makefile.am
index 94ad371..ceccce8 100644
--- a/src/lib/resolve/Makefile.am
+++ b/src/lib/resolve/Makefile.am
@@ -8,8 +8,8 @@ AM_CPPFLAGS += $(SQLITE_CFLAGS)
AM_CXXFLAGS = $(B10_CXXFLAGS)
# Define rule to build logging source files from message file
-resolvedef.h resolvedef.cc: resolvedef.mes
- $(top_builddir)/src/lib/log/compiler/message $(top_srcdir)/src/lib/resolve/resolvedef.mes
+resolve_messages.h resolve_messages.cc: resolve_messages.mes
+ $(top_builddir)/src/lib/log/compiler/message $(top_srcdir)/src/lib/resolve/resolve_messages.mes
# Tell Automake that the nsasdef.{cc,h} source files are created in the build
# process, so it must create these before doing anything else. Although they
@@ -17,9 +17,9 @@ resolvedef.h resolvedef.cc: resolvedef.mes
# anyway), there is no guarantee as to exactly _when_ in the build they will be
# created. As the .h file is included in other sources file (so must be
# present when they are compiled), the safest option is to create it first.
-BUILT_SOURCES = resolvedef.h resolvedef.cc
+BUILT_SOURCES = resolve_messages.h resolve_messages.cc
-CLEANFILES = *.gcno *.gcda resolvedef.cc resolvedef.h
+CLEANFILES = *.gcno *.gcda resolve_messages.cc resolve_messages.h
lib_LTLIBRARIES = libresolve.la
libresolve_la_SOURCES = resolve.h resolve.cc
@@ -29,14 +29,14 @@ libresolve_la_SOURCES += resolver_callback.h resolver_callback.cc
libresolve_la_SOURCES += response_classifier.cc response_classifier.h
libresolve_la_SOURCES += recursive_query.cc recursive_query.h
-nodist_libresolve_la_SOURCES = resolvedef.h resolvedef.cc
+nodist_libresolve_la_SOURCES = resolve_messages.h resolve_messages.cc
libresolve_la_LIBADD = $(top_builddir)/src/lib/dns/libdns++.la
libresolve_la_LIBADD += $(top_builddir)/src/lib/exceptions/libexceptions.la
libresolve_la_LIBADD += $(top_builddir)/src/lib/log/liblog.la
# The message file should be in the distribution.
-EXTRA_DIST = resolvedef.mes
+EXTRA_DIST = resolve_messages.mes
# Note: the ordering matters: -Wno-... must follow -Wextra (defined in
# B10_CXXFLAGS)
diff --git a/src/lib/resolve/recursive_query.cc b/src/lib/resolve/recursive_query.cc
index ad073ae..d692dc1 100644
--- a/src/lib/resolve/recursive_query.cc
+++ b/src/lib/resolve/recursive_query.cc
@@ -147,7 +147,7 @@ RecursiveQuery::RecursiveQuery(DNSService& dns_service,
// Set the test server - only used for unit testing.
void
RecursiveQuery::setTestServer(const std::string& address, uint16_t port) {
- LOG_WARN(isc::resolve::logger, RESLIB_TESTSERV).arg(address).arg(port);
+ LOG_WARN(isc::resolve::logger, RESLIB_TEST_SERVER).arg(address).arg(port);
test_server_.first = address;
test_server_.second = port;
}
@@ -177,7 +177,7 @@ public:
void success(const isc::nsas::NameserverAddress& address) {
// Success callback, send query to found namesever
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CB, RESLIB_RUNQUSUCC)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CB, RESLIB_RUNQ_SUCCESS)
.arg(address.getAddress().toText());
rq_->nsasCallbackCalled();
rq_->sendTo(address);
@@ -185,7 +185,7 @@ public:
void unreachable() {
// Nameservers unreachable: drop query or send servfail?
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CB, RESLIB_RUNQUFAIL);
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CB, RESLIB_RUNQ_FAIL);
rq_->nsasCallbackCalled();
rq_->makeSERVFAIL();
rq_->callCallback(true);
@@ -311,7 +311,7 @@ private:
// if we have a response for our query stored already. if
// so, call handlerecursiveresponse(), if not, we call send()
void doLookup() {
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RUNCALOOK)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RUNQ_CACHE_LOOKUP)
.arg(questionText(question_));
Message cached_message(Message::RENDER);
@@ -319,7 +319,7 @@ private:
if (cache_.lookup(question_.getName(), question_.getType(),
question_.getClass(), cached_message)) {
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RUNCAFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RUNQ_CACHE_FIND)
.arg(questionText(question_));
// Should these be set by the cache too?
cached_message.setOpcode(Opcode::QUERY());
@@ -366,7 +366,7 @@ private:
protocol_ = protocol; // Store protocol being used for this
if (test_server_.second != 0) {
// Send query to test server
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_TESTUPSTR)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_TEST_UPSTREAM)
.arg(questionText(question_)).arg(test_server_.first);
gettimeofday(¤t_ns_qsent_time, NULL);
++outstanding_events_;
@@ -379,7 +379,7 @@ private:
} else {
// Ask the NSAS for an address for the current zone,
// the callback will call the actual sendTo()
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_NSASLOOK)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_NSAS_LOOKUP)
.arg(cur_zone_);
// Can we have multiple calls to nsas_out? Let's assume not
@@ -440,7 +440,7 @@ private:
// is, we reset our 'current servers' to the root servers).
if (cname_count_ >= RESOLVER_MAX_CNAME_CHAIN) {
// CNAME chain too long - just give up
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_LONGCHAIN)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_LONG_CHAIN)
.arg(questionText(question_));
makeSERVFAIL();
return true;
@@ -456,7 +456,7 @@ private:
question_.getType());
// Follow CNAME chain.
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_FOLLOWCNAME)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_FOLLOW_CNAME)
.arg(questionText(question_));
doLookup();
return false;
@@ -465,7 +465,7 @@ private:
case isc::resolve::ResponseClassifier::NXDOMAIN:
case isc::resolve::ResponseClassifier::NXRRSET:
// Received NXDOMAIN or NXRRSET, just copy and return
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_NXDOMRR)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_NXDOM_NXRR)
.arg(questionText(question_));
isc::resolve::copyResponseMessage(incoming, answer_message_);
// no negcache yet
@@ -496,7 +496,7 @@ private:
// (this requires a few API changes in related
// libraries, so as not to need many conversions)
cur_zone_ = rrs->getName().toText();
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_REFERZONE)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_REFER_ZONE)
.arg(cur_zone_);
found_ns = true;
break;
@@ -522,7 +522,7 @@ private:
return false;
} else {
// Referral was received but did not contain an NS RRset.
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_NONSRRSET)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_NO_NS_RRSET)
.arg(questionText(question_));
// TODO this will result in answering with the delegation. oh well
@@ -554,7 +554,7 @@ private:
case isc::resolve::ResponseClassifier::NOTSINGLE:
case isc::resolve::ResponseClassifier::OPCODE:
case isc::resolve::ResponseClassifier::RCODE:
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_RCODERR)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_RCODE_ERR)
.arg(questionText(question_));
// Should we try a different server rather than SERVFAIL?
makeSERVFAIL();
@@ -751,7 +751,7 @@ public:
if (retries_--) {
// Retry
LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS,
- RESLIB_PROTOCOLRTRY)
+ RESLIB_PROTOCOL_RETRY)
.arg(questionText(question_)).arg(dpe.what())
.arg(retries_);
send();
@@ -769,7 +769,7 @@ public:
}
} else if (!done_ && retries_--) {
// Query timed out, but we have some retries, so send again
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_TIMEOUTRTRY)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_RESULTS, RESLIB_TIMEOUT_RETRY)
.arg(questionText(question_))
.arg(current_ns_address.getAddress().toText()).arg(retries_);
current_ns_address.updateRTT(isc::nsas::AddressEntry::UNREACHABLE);
@@ -993,7 +993,7 @@ RecursiveQuery::resolve(const QuestionPtr& question,
question->getClass(), *answer_message) &&
answer_message->getRRCount(Message::SECTION_ANSWER) > 0) {
// Message found, return that
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RESCAFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RECQ_CACHE_FIND)
.arg(questionText(*question)).arg(1);
// TODO: err, should cache set rcode as well?
@@ -1007,7 +1007,7 @@ RecursiveQuery::resolve(const QuestionPtr& question,
question->getClass());
if (cached_rrset) {
// Found single RRset in cache
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RRSETFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RRSET_FOUND)
.arg(questionText(*question)).arg(1);
answer_message->addRRset(Message::SECTION_ANSWER,
cached_rrset);
@@ -1016,7 +1016,7 @@ RecursiveQuery::resolve(const QuestionPtr& question,
} else {
// Message not found in cache, start recursive query. It will
// delete itself when it is done
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_RESCANOTFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_RECQ_CACHE_NO_FIND)
.arg(questionText(*question)).arg(1);
new RunningQuery(io, *question, answer_message,
test_server_, buffer, callback,
@@ -1055,7 +1055,7 @@ RecursiveQuery::resolve(const Question& question,
answer_message->getRRCount(Message::SECTION_ANSWER) > 0) {
// Message found, return that
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RESCAFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RECQ_CACHE_FIND)
.arg(questionText(question)).arg(2);
// TODO: err, should cache set rcode as well?
answer_message->setRcode(Rcode::NOERROR());
@@ -1068,7 +1068,7 @@ RecursiveQuery::resolve(const Question& question,
question.getClass());
if (cached_rrset) {
// Found single RRset in cache
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RRSETFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_CACHE, RESLIB_RRSET_FOUND)
.arg(questionText(question)).arg(2);
answer_message->addRRset(Message::SECTION_ANSWER,
cached_rrset);
@@ -1078,7 +1078,7 @@ RecursiveQuery::resolve(const Question& question,
} else {
// Message not found in cache, start recursive query. It will
// delete itself when it is done
- LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_RESCANOTFND)
+ LOG_DEBUG(isc::resolve::logger, RESLIB_DBG_TRACE, RESLIB_RECQ_CACHE_NO_FIND)
.arg(questionText(question)).arg(2);
new RunningQuery(io, question, answer_message,
test_server_, buffer, crs, query_timeout_,
diff --git a/src/lib/resolve/resolve_log.h b/src/lib/resolve/resolve_log.h
index 89d23c6..1f2869e 100644
--- a/src/lib/resolve/resolve_log.h
+++ b/src/lib/resolve/resolve_log.h
@@ -16,7 +16,7 @@
#define __RESOLVE_LOG__H
#include <log/macros.h>
-#include "resolvedef.h"
+#include "resolve_messages.h"
namespace isc {
namespace resolve {
diff --git a/src/lib/resolve/resolve_messages.mes b/src/lib/resolve/resolve_messages.mes
new file mode 100644
index 0000000..fd384f1
--- /dev/null
+++ b/src/lib/resolve/resolve_messages.mes
@@ -0,0 +1,154 @@
+# 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.
+
+$NAMESPACE isc::resolve
+
+% RESLIB_ANSWER answer received in response to query for <%1>
+A debug message recording that an answer has been received to an upstream
+query for the specified question. Previous debug messages will have indicated
+the server to which the question was sent.
+
+% RESLIB_CNAME CNAME received in response to query for <%1>
+A debug message recording that CNAME response has been received to an upstream
+query for the specified question. Previous debug messages will have indicated
+the server to which the question was sent.
+
+% RESLIB_DEEPEST did not find <%1> in cache, deepest delegation found is %2
+A debug message, a cache lookup did not find the specified <name, class,
+type> tuple in the cache; instead, the deepest delegation found is indicated.
+
+% RESLIB_FOLLOW_CNAME following CNAME chain to <%1>
+A debug message, a CNAME response was received and another query is being issued
+for the <name, class, type> tuple.
+
+% RESLIB_LONG_CHAIN CNAME received in response to query for <%1>: CNAME chain length exceeded
+A debug message recording that a CNAME response has been received to an upstream
+query for the specified question (Previous debug messages will have indicated
+the server to which the question was sent). However, receipt of this CNAME
+has meant that the resolver has exceeded the CNAME chain limit (a CNAME chain
+is where on CNAME points to another) and so an error is being returned.
+
+% RESLIB_NO_NS_RRSET no NS RRSet in referral response received to query for <%1>
+A debug message, this indicates that a response was received for the specified
+query and was categorised as a referral. However, the received message did
+not contain any NS RRsets. This may indicate a programming error in the
+response classification code.
+
+% RESLIB_NSAS_LOOKUP looking up nameserver for zone %1 in the NSAS
+A debug message, the RunningQuery object is querying the NSAS for the
+nameservers for the specified zone.
+
+% RESLIB_NXDOM_NXRR NXDOMAIN/NXRRSET received in response to query for <%1>
+A debug message recording that either a NXDOMAIN or an NXRRSET response has
+been received to an upstream query for the specified question. Previous debug
+messages will have indicated the server to which the question was sent.
+
+% RESLIB_PROTOCOL protocol error in answer for %1: %3
+A debug message indicating that a protocol error was received. As there
+are no retries left, an error will be reported.
+
+% RESLIB_PROTOCOL_RETRY protocol error in answer for %1: %2 (retries left: %3)
+A debug message indicating that a protocol error was received and that
+the resolver is repeating the query to the same nameserver. After this
+repeated query, there will be the indicated number of retries left.
+
+% RESLIB_RCODE_ERR RCODE indicates error in response to query for <%1>
+A debug message, the response to the specified query indicated an error
+that is not covered by a specific code path. A SERVFAIL will be returned.
+
+% RESLIB_RECQ_CACHE_FIND found <%1> in the cache (resolve() instance %2)
+This is a debug message and indicates that a RecursiveQuery object found the
+the specified <name, class, type> tuple in the cache. The instance number
+at the end of the message indicates which of the two resolve() methods has
+been called.
+
+% RESLIB_RECQ_CACHE_NO_FIND did not find <%1> in the cache, starting RunningQuery (resolve() instance %2)
+This is a debug message and indicates that the look in the cache made by the
+RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery
+object has been created to resolve the question. The instance number at
+the end of the message indicates which of the two resolve() methods has
+been called.
+
+% RESLIB_REFERRAL referral received in response to query for <%1>
+A debug message recording that a referral response has been received to an
+upstream query for the specified question. Previous debug messages will
+have indicated the server to which the question was sent.
+
+% RESLIB_REFER_ZONE referred to zone %1
+A debug message indicating that the last referral message was to the specified
+zone.
+
+% RESLIB_RESOLVE asked to resolve <%1> (resolve() instance %2)
+A debug message, the RecursiveQuery::resolve method has been called to resolve
+the specified <name, class, type> tuple. The first action will be to lookup
+the specified tuple in the cache. The instance number at the end of the
+message indicates which of the two resolve() methods has been called.
+
+% RESLIB_RRSET_FOUND found single RRset in the cache when querying for <%1> (resolve() instance %2)
+A debug message, indicating that when RecursiveQuery::resolve queried the
+cache, a single RRset was found which was put in the answer. The instance
+number at the end of the message indicates which of the two resolve()
+methods has been called.
+
+% RESLIB_RTT round-trip time of last query calculated as %1 ms
+A debug message giving the round-trip time of the last query and response.
+
+% RESLIB_RUNQ_CACHE_FIND found <%1> in the cache
+This is a debug message and indicates that a RunningQuery object found
+the specified <name, class, type> tuple in the cache.
+
+% RESLIB_RUNQ_CACHE_LOOKUP looking up up <%1> in the cache
+This is a debug message and indicates that a RunningQuery object has made
+a call to its doLookup() method to look up the specified <name, class, type>
+tuple, the first action of which will be to examine the cache.
+
+% RESLIB_RUNQ_FAIL failure callback - nameservers are unreachable
+A debug message indicating that a RunningQuery's failure callback has been
+called because all nameservers for the zone in question are unreachable.
+
+% RESLIB_RUNQ_SUCCESS success callback - sending query to %1
+A debug message indicating that a RunningQuery's success callback has been
+called because a nameserver has been found, and that a query is being sent
+to the specified nameserver.
+
+% RESLIB_TEST_SERVER setting test server to %1(%2)
+This is an internal debugging message and is only generated in unit tests.
+It indicates that all upstream queries from the resolver are being routed to
+the specified server, regardless of the address of the nameserver to which
+the query would normally be routed. As it should never be seen in normal
+operation, it is a warning message instead of a debug message.
+
+% RESLIB_TEST_UPSTREAM sending upstream query for <%1> to test server at %2
+This is a debug message and should only be seen in unit tests. A query for
+the specified <name, class, type> tuple is being sent to a test nameserver
+whose address is given in the message.
+
+% RESLIB_TIMEOUT query <%1> to %2 timed out
+A debug message indicating that the specified query has timed out and as
+there are no retries left, an error will be reported.
+
+% RESLIB_TIMEOUT_RETRY query <%1> to %2 timed out, re-trying (retries left: %3)
+A debug message indicating that the specified query has timed out and that
+the resolver is repeating the query to the same nameserver. After this
+repeated query, there will be the indicated number of retries left.
+
+% RESLIB_TRUNCATED response to query for <%1> was truncated, re-querying over TCP
+A debug message, this indicates that the response to the specified query was
+truncated and that the resolver will be re-querying over TCP. There are
+various reasons why responses may be truncated, so this message is normal and
+gives no cause for concern.
+
+% RESLIB_UPSTREAM sending upstream query for <%1> to %2
+A debug message indicating that a query for the specified <name, class, type>
+tuple is being sent to a nameserver whose address is given in the message.
diff --git a/src/lib/resolve/resolvedef.mes b/src/lib/resolve/resolvedef.mes
deleted file mode 100644
index 61870a6..0000000
--- a/src/lib/resolve/resolvedef.mes
+++ /dev/null
@@ -1,155 +0,0 @@
-# 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.
-
-$PREFIX RESLIB_
-$NAMESPACE isc::resolve
-
-% ANSWER answer received in response to query for <%1>
-A debug message recording that an answer has been received to an upstream
-query for the specified question. Previous debug messages will have indicated
-the server to which the question was sent.
-
-% CNAME CNAME received in response to query for <%1>
-A debug message recording that CNAME response has been received to an upstream
-query for the specified question. Previous debug messages will have indicated
-the server to which the question was sent.
-
-% DEEPEST did not find <%1> in cache, deepest delegation found is %2
-A debug message, a cache lookup did not find the specified <name, class,
-type> tuple in the cache; instead, the deepest delegation found is indicated.
-
-% FOLLOWCNAME following CNAME chain to <%1>
-A debug message, a CNAME response was received and another query is being issued
-for the <name, class, type> tuple.
-
-% LONGCHAIN CNAME received in response to query for <%1>: CNAME chain length exceeded
-A debug message recording that a CNAME response has been received to an upstream
-query for the specified question (Previous debug messages will have indicated
-the server to which the question was sent). However, receipt of this CNAME
-has meant that the resolver has exceeded the CNAME chain limit (a CNAME chain
-is where on CNAME points to another) and so an error is being returned.
-
-% NONSRRSET no NS RRSet in referral response received to query for <%1>
-A debug message, this indicates that a response was received for the specified
-query and was categorised as a referral. However, the received message did
-not contain any NS RRsets. This may indicate a programming error in the
-response classification code.
-
-% NSASLOOK looking up nameserver for zone %1 in the NSAS
-A debug message, the RunningQuery object is querying the NSAS for the
-nameservers for the specified zone.
-
-% NXDOMRR NXDOMAIN/NXRRSET received in response to query for <%1>
-A debug message recording that either a NXDOMAIN or an NXRRSET response has
-been received to an upstream query for the specified question. Previous debug
-messages will have indicated the server to which the question was sent.
-
-% PROTOCOL protocol error in answer for %1: %3
-A debug message indicating that a protocol error was received. As there
-are no retries left, an error will be reported.
-
-% PROTOCOLRTRY protocol error in answer for %1: %2 (retries left: %3)
-A debug message indicating that a protocol error was received and that
-the resolver is repeating the query to the same nameserver. After this
-repeated query, there will be the indicated number of retries left.
-
-% RCODERR RCODE indicates error in response to query for <%1>
-A debug message, the response to the specified query indicated an error
-that is not covered by a specific code path. A SERVFAIL will be returned.
-
-% REFERRAL referral received in response to query for <%1>
-A debug message recording that a referral response has been received to an
-upstream query for the specified question. Previous debug messages will
-have indicated the server to which the question was sent.
-
-% REFERZONE referred to zone %1
-A debug message indicating that the last referral message was to the specified
-zone.
-
-% RESCAFND found <%1> in the cache (resolve() instance %2)
-This is a debug message and indicates that a RecursiveQuery object found the
-the specified <name, class, type> tuple in the cache. The instance number
-at the end of the message indicates which of the two resolve() methods has
-been called.
-
-% RESCANOTFND did not find <%1> in the cache, starting RunningQuery (resolve() instance %2)
-This is a debug message and indicates that the look in the cache made by the
-RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery
-object has been created to resolve the question. The instance number at
-the end of the message indicates which of the two resolve() methods has
-been called.
-
-% RESOLVE asked to resolve <%1> (resolve() instance %2)
-A debug message, the RecursiveQuery::resolve method has been called to resolve
-the specified <name, class, type> tuple. The first action will be to lookup
-the specified tuple in the cache. The instance number at the end of the
-message indicates which of the two resolve() methods has been called.
-
-% RRSETFND found single RRset in the cache when querying for <%1> (resolve() instance %2)
-A debug message, indicating that when RecursiveQuery::resolve queried the
-cache, a single RRset was found which was put in the answer. The instance
-number at the end of the message indicates which of the two resolve()
-methods has been called.
-
-% RTT round-trip time of last query calculated as %1 ms
-A debug message giving the round-trip time of the last query and response.
-
-% RUNCAFND found <%1> in the cache
-This is a debug message and indicates that a RunningQuery object found
-the specified <name, class, type> tuple in the cache.
-
-% RUNCALOOK looking up up <%1> in the cache
-This is a debug message and indicates that a RunningQuery object has made
-a call to its doLookup() method to look up the specified <name, class, type>
-tuple, the first action of which will be to examine the cache.
-
-% RUNQUFAIL failure callback - nameservers are unreachable
-A debug message indicating that a RunningQuery's failure callback has been
-called because all nameservers for the zone in question are unreachable.
-
-% RUNQUSUCC success callback - sending query to %1
-A debug message indicating that a RunningQuery's success callback has been
-called because a nameserver has been found, and that a query is being sent
-to the specified nameserver.
-
-% TESTSERV setting test server to %1(%2)
-This is an internal debugging message and is only generated in unit tests.
-It indicates that all upstream queries from the resolver are being routed to
-the specified server, regardless of the address of the nameserver to which
-the query would normally be routed. As it should never be seen in normal
-operation, it is a warning message instead of a debug message.
-
-% TESTUPSTR sending upstream query for <%1> to test server at %2
-This is a debug message and should only be seen in unit tests. A query for
-the specified <name, class, type> tuple is being sent to a test nameserver
-whose address is given in the message.
-
-% TIMEOUT query <%1> to %2 timed out
-A debug message indicating that the specified query has timed out and as
-there are no retries left, an error will be reported.
-
-% TIMEOUTRTRY query <%1> to %2 timed out, re-trying (retries left: %3)
-A debug message indicating that the specified query has timed out and that
-the resolver is repeating the query to the same nameserver. After this
-repeated query, there will be the indicated number of retries left.
-
-% TRUNCATED response to query for <%1> was truncated, re-querying over TCP
-A debug message, this indicates that the response to the specified query was
-truncated and that the resolver will be re-querying over TCP. There are
-various reasons why responses may be truncated, so this message is normal and
-gives no cause for concern.
-
-% UPSTREAM sending upstream query for <%1> to %2
-A debug message indicating that a query for the specified <name, class, type>
-tuple is being sent to a nameserver whose address is given in the message.
More information about the bind10-changes
mailing list