Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#1102 closed enhancement (fixed)

Make message about out-of-bailiwick data less verbose

Reported by: shane Owned by: UnAssigned
Priority: low Milestone: Sprint-20120403
Component: b10-auth Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Low
Sub-Project: DNS Feature Depending on Ticket: none
Estimated Difficulty: 1 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

I have a zone with NS that are not in the zone. Every query results in this message:

2011-07-08 13:25:37.821 INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'madras.curryboys.net.' in class 'IN'

This is too verbose, and should probably be made DEBUG.

Subtickets

Change History (19)

comment:1 Changed 9 years ago by jreed

This problem continues. On our production n10, for every successful query, it logs four entries:

2011-08-18 23:46:12.q INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'ams.sns-pb.isc.org.' in class 'IN'
2011-08-18 23:46:12.q INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'n10.isc.org.' in class 'IN'
2011-08-18 23:46:12.q INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'ord.sns-pb.isc.org.' in class 'IN'
2011-08-18 23:46:12.q INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'sfba.sns-pb.isc.org.' in class 'IN'

comment:2 Changed 9 years ago by jreed

And since last release it was logged 73479 times.

comment:3 Changed 8 years ago by jreed

  • Milestone set to Next-Sprint-Proposed

comment:4 Changed 8 years ago by jreed

jinmei said in jabber: "it will be gone with the never ending "data source refactoring" work, so I'm not sure if we bother to fix it."

comment:5 Changed 8 years ago by shane

  • Feature Depending on Ticket set to none

comment:6 Changed 8 years ago by jelte

  • Estimated Difficulty changed from 0.0 to 1

comment:7 Changed 8 years ago by jreed

  • Milestone changed from Year 3 Task Backlog to Next-Sprint-Proposed

Let's just do the most trivial fix to use DEBUG for now.

comment:8 follow-up: Changed 8 years ago by jreed

Okay to commit this?

DBG_TRACE_BASIC seems wrong since number is for developers, but no good definition of what this should be.

diff --git a/src/lib/datasrc/data_source.cc b/src/lib/datasrc/data_source.cc
index 94dec89..a713b82 100644
--- a/src/lib/datasrc/data_source.cc
+++ b/src/lib/datasrc/data_source.cc
@@ -384,7 +384,8 @@ doQueryTask(QueryTask& task, ZoneInfo& zoneinfo, RRsetList& target) {
     const Name* const zonename = zoneinfo.getEnclosingZone();
     if (ds == NULL) {
         task.flags |= DataSrc::NO_SUCH_ZONE;
-        logger.info(DATASRC_QUERY_NO_ZONE).arg(task.qname).arg(task.qclass);
+        LOG_DEBUG(logger, DBG_TRACE_BASIC, DATASRC_QUERY_NO_ZONE).
+            arg(task.qname).arg(task.qclass);
         return (DataSrc::SUCCESS);
     }
 
diff --git a/src/lib/datasrc/datasrc_messages.mes b/src/lib/datasrc/datasrc_messages.mes
index f4ff213..025ca6c 100644
--- a/src/lib/datasrc/datasrc_messages.mes
+++ b/src/lib/datasrc/datasrc_messages.mes
@@ -569,8 +569,9 @@ An attempt to add a NSEC3 record into the message failed, because the zone does
 not have any DS record. This indicates problem with the provided data.
 
 % DATASRC_QUERY_NO_ZONE no zone containing '%1' in class '%2'
-Lookup of domain failed because the data have no zone that contain the
-domain. Maybe someone sent a query to the wrong server for some reason.
+Debug information. Lookup of domain failed because the datasource
+has no zone that contains the domain. Maybe someone sent a query
+to the wrong server for some reason.
 
 % DATASRC_QUERY_PROCESS processing query '%1/%2' in the '%3' class
 Debug information. A sure query is being processed now.

comment:9 Changed 8 years ago by jreed

  • Owner set to UnAssigned
  • Status changed from new to reviewing

comment:10 Changed 8 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Sprint-20120403

comment:11 in reply to: ↑ 8 Changed 8 years ago by jinmei

Replying to jreed:

Okay to commit this?

Yes, please.

comment:12 Changed 8 years ago by jinmei

  • Owner changed from UnAssigned to jreed

comment:13 follow-up: Changed 8 years ago by jreed

Committed it in commit 6784b5dbb0e599f370fb5965acf7038ab214b107

Added a little to the log description based on conversation in jabber.

No changelog entry added as discussed on jabber. Nobody reported it other than our developers. And not useful to have a changelog entry for every logging severity change.

I was thinking that the NS lookups for additional data should be logged differently... this log message happens due to outside queries for something not in the datasource AND also for lookups of addresses for NS records in the datasource (for additional section info). I was told in jabber: "i suspect that at the time it is logged, it does not know why it is looking for that data." and that the new datasource should improve this.

The original problem for the ticket is solved, but I am not closing this ticket unless others agree that the current single log ID for two different concepts is okay.

Another issue is that I am logging at log level 40. I didn't see other choice used for datasrc. Note that 30 and below is useful for admins, like this log id. But we plan to have a different task reviewing log entries, severities, debug levels, etc. So we can handle it then. (I made a ticket for this: #1822.)

comment:14 in reply to: ↑ 13 Changed 8 years ago by jinmei

Replying to jreed:

The original problem for the ticket is solved, but I am not closing this ticket unless others agree that the current single log ID for two different concepts is okay.

I don't understand this part...what does "the current single log ID
for two different concepts" mean?

And, in any case, I don't like to keep a basically-completed task in
the review queue too long. If the open issue is big, I'd close this
one and open a new ticket. If it's a minor one, I'd still close this
ticket maybe just ignoring it. If it's some open issue that really
needs to be addressed within this ticket, I'll change the status to
open (= non reviewing) and have someone solve that.

comment:15 Changed 8 years ago by jreed

  • Status changed from reviewing to accepted

comment:16 Changed 8 years ago by jreed

  • Owner changed from jreed to UnAssigned
  • Status changed from accepted to assigned

comment:17 Changed 8 years ago by jinmei

What's the current status of this ticket?

I, for one, don't understand what else needs to be done within this
ticket, and it's not assigned to anyone. Unless what to do is
clarified or at least someone who knows that picks it up, I'm afraid
this ticket will be hanging forever.

comment:18 follow-up: Changed 8 years ago by shane

  • Resolution set to fixed
  • Status changed from assigned to closed

I think Jeremy is concerned that this error occurs if someone makes an outside query for data not in a data source. I don't think that this log message occurs in that case. I think it only occurs when we have out-of-bailiwick RDATA that the server uses (NS, CNAME, and so on).

Even if this is not true, this should be enough to close a ticket:

The original problem for the ticket is solved

If there are additional issues we need to create another ticket. We need to be careful about tickets that expand, evolve, and end up in confusing states that can never be resolved.

Resolving this by Executive Order!

comment:19 in reply to: ↑ 18 Changed 8 years ago by jreed

Replying to shane:

I think Jeremy is concerned that this error occurs if someone makes an outside query for data not in a data source. I don't think that this log message occurs in that case. I think it only occurs when we have out-of-bailiwick RDATA that the server uses (NS, CNAME, and so on).

It is logged for outside queries too. I created a new ticket: #1838.

Note: See TracTickets for help on using tickets.