Opened 9 years ago

Closed 9 years ago

#1078 closed enhancement (complete)

Update RESLIB/RESOLVER message descriptions

Reported by: stephen Owned by: stephen
Priority: low Milestone: Sprint-20110712
Component: logging Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 3.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

some string formating have brackets... use %1 or <%1> ? or is that for a "tuple" only?

RESLIB_TESTSERV says conflicting debugging and not debug and " As it should never be seen in normal operation, it is a warning message instead of a debug message." is too verbose, not needed here

RESLIB_TIMEOUT error will be reported where?

RESOLVER_AXFRTCP says "AXFR request" and "received a NOTIFY" and RESOLVER_AXFRUDP says "AXFR request" and "received a NOTIFY" -- well which is it? (a NOTIFY is a hint to do an SOA serial check)

RESOLVER_CLTMOSMALL does BIND 10 fail to start? then what is used? default? minimum?

RESOLVER_CLTMOSMALL is there a corresponding too large?

Can RESOLVER_CONFIGERR be separated into programmer error and user error with different log ID? Should it say to file a bug report?

style: some have incomplete / poor grammar for saying it is a debug message while some have complete separate sentence for that.

RESOLVER_DNSMSGSENT what details?

RESOLVER_FAILED does this means that b10-resolver process will end?

RESOLVER_FWDADDR why could it appear multiple times?

RESOLVER_FWDQUERY what checks?

RESOLVER_LKTMOSMALL does BIND 10 fail to start? Or what does it use? The default? minimum?

RESOLVER_LKTMOSMALL is there a too large too?

RESOLVER_NFYNOTAUTH how to correspond this to the sender of the message? (log that too?)

RESOLVER_NORMQUERY what checks?

RESOLVER_NOROOTADDR add more details? Should this really be a warning? (isn't it just informational and normal?)

RESOLVER_NOTIN why can't handle other classes in a query? (And description should say this is a query?)

RESOLVER_NOTONEQUES typo: "entires"? (entries?) (while I don't recall seeing it, where is it documented one question is limit? even RFC 1035 hints multiple questions could be asked.)

RESOLVER_QUTMOSMALL should it show the minimum? does BIND 10 fail to start? Or does it use default? or minimum?

RESOLVER_QUTMOSMALL is there a corresponding too large error? (but maybe the existing ID should be for both: out of range.)

RESOLVER_RECVMSG description say "DNS"?

RESOLVER_ROOTADDR why multiple times?

RESOLVER_SETPARAM "interval to resolver" and "continuing to resolver" should be "resolve"? Too many colons? "resolve gives up" should be "resolver"?

Maybe this description is way too long -- two paragraphs is too long?

RESOLVER_SHUTDOWN, RESOLVER_STARTED are too noisy for default logging? should be debug mode only?

RESOLVER_STARTING description should mention command line arguments?

RESOLVER_UNEXRESP not enough information? so response doesn't match up with an existing outbound query (wrong port, address, name, class)?

Subtickets

Change History (10)

comment:1 Changed 9 years ago by stephen

From this email sent to bind10-dev:

  • RESOLVER_SHUTDOWN, RESOLVER_STARTED are too noisy for default logging?

should be debug mode only?

I think that INFO is fine. These only appear once per session and provide a record of when it was running. In a production environment, these could be helpful in providing uptime statistics and tracking down service outages.

comment:2 Changed 9 years ago by stephen

  • Owner set to stephen
  • Status changed from new to assigned

comment:3 Changed 9 years ago by stephen

  • Owner changed from stephen to UnAssigned
  • Status changed from assigned to reviewing

Note that the message IDs were updated in a previous ticket: the updated message ID is given where relevant.

some string formating have brackets... use %1 or <%1> ? or is that for a "tuple" only?

Message have been altered so that the "<>" form is only used for a name/class/type tuple.

RESLIB_TESTSERV says conflicting debugging and not debug and " As it should never be seen in normal operation, it is a warning message instead of a debug message." is too verbose, not needed here

Altered.

RESLIB_TIMEOUT error will be reported where?

Altered. It now just says that the query has timed out.

RESOLVER_AXFRTCP says "AXFR request" and "received a NOTIFY" and RESOLVER_AXFRUDP says "AXFR request" and "received a NOTIFY" -- well which is it? (a NOTIFY is a hint to do an SOA serial check)

Now RESOLVER_AXFR_TCP and RESOLVER_AXFR_UDP, the description has been altered.

RESOLVER_CLTMOSMALL does BIND 10 fail to start? then what is used? default? minimum?

Now RESOLVER_CLIENT_TIME_SMALL, the check only occurs when the configuration is being updated. On error, the update is rejected. The description haas been changed and similar text changes have been applied to the messages "query timeout too small" and "lookup timeout too small".

RESOLVER_CLTMOSMALL is there a corresponding too large?

The code does not check for too large a value.

Can RESOLVER_CONFIGERR be separated into programmer error and user error with different log ID? Should it say to file a bug report?

Ticket #1094 has been raised for this.

style: some have incomplete / poor grammar for saying it is a debug message while some have complete separate sentence for that.

The text has been changed.

RESOLVER_DNSMSGSENT what details?

Now RESOLVER_DNS_MESSAGE_SENT, the description should indicate what is being sent.

RESOLVER_FAILED does this means that b10-resolver process will end?

Yes - this has been made clear in the message description.

RESOLVER_FWDADDR why could it appear multiple times?

Now RESOLVER_FORWARD_ADDRESS, the description has been changed to clarify the point.

RESOLVER_FWDQUERY what checks?

Now RESOLVER_FORWARD_QUERY, some of the checks are listed in the description.

RESOLVER_LKTMOSMALL does BIND 10 fail to start? Or what does it use? The default? minimum?
RESOLVER_LKTMOSMALL is there a too large too?

Now RESOLVER_LOOKUP_TIME_SMALL. See comments for RESOLVER_CLIENT_TIME_SMALL.

RESOLVER_NFYNOTAUTH how to correspond this to the sender of the message? (log that too?)

Now RESOLVER_NOTIFY_RECEIVED. Ticket #1095 has been created to cover this.

RESOLVER_NORMQUERY what checks?

Now RESOLVER_NORMAL_QUERY. Description has been updated.

RESOLVER_NOROOTADDR add more details? Should this really be a warning? (isn't it just informational and normal?)

Now RESOLVER_NO_ROOT_ADDRESS. Not certain about this; it appears to be generated if "root_addresses" appears in the configuration but there are no addresses associated with the item. In that case, if the resolver can proceed by getting the addresses from elsewhere, this is rightly a warning.

RESOLVER_NOTIN why can't handle other classes in a query? (And description should say this is a query?)

Now RESOLVER_NON_IN_PACKET. At present, the resolver only handles queries for the IN class (as well as the
CH query for version.bind).

RESOLVER_NOTONEQUES typo: "entires"? (entries?) (while I don't recall seeing it, where is it documented one question is limit? even RFC 1035 hints multiple questions could be asked.)

Typos corrected. As to multiple questions, I'm not sure that it is documented anywhere. I've looked and the closest I could get was a mention in http://www.ietf.org/proceedings/42/I-D/draft-ietf-dnsind-edns-03.txt

RESOLVER_QUTMOSMALL should it show the minimum? does BIND 10 fail to start? Or does it use default? or minimum?
RESOLVER_QUTMOSMALL is there a corresponding too large error? (but maybe the existing ID should be for both: out of range.)

Now RESOLVER_QUERY_TIME_SMALL, see comment for RESOLVER_CLIENT_TIME_SMALL.

RESOLVER_RECVMSG description say "DNS"?

Now RESOLVER_DNS_MESSAGE_RECEIVED.

RESOLVER_ROOTADDR why multiple times?

Issued once per root address. The message ID is now RESOLVER_SET_ROOT_ADDRESS and the description explains why it is issued multiple times.

RESOLVER_SETPARAM "interval to resolver" and "continuing to resolver" should be "resolve"? Too many colons? "resolve gives up" should be "resolver"?

Now RESOLVER_SET_PARAMS. Typos corrected.

Maybe this description is way too long -- two paragraphs is too long?

I don't think there is any lenght that is too long or too short - it depends on the message. In this case, unless the timeouts are documented elsewhere and we can refer to that documentation, the explanation is OK here.

RESOLVER_SHUTDOWN, RESOLVER_STARTED are too noisy for default logging? should be debug mode only?

See previous comment.

RESOLVER_STARTING description should mention command line arguments?

It does.

RESOLVER_UNEXRESP not enough information? so response doesn't match up with an existing outbound query (wrong port, address, name, class)?

Now RESOLVER_UNEXPECTED_RESPONSE. The description has been updated to explain that the resolver had received a response packet on the port on which it is listening for queries.

comment:4 Changed 9 years ago by stephen

  • Estimated Difficulty changed from 0.0 to 3

comment:5 Changed 9 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:6 Changed 9 years ago by vorner

  • Owner changed from vorner to stephen

Hello

I have only few comments:

  • RESOLVER_AXFR_UDP says it was received over TCP. Possibly a copy-paste leftover?
  • RESOLVER_SET_ROOT_ADDRESS Typo? (oncee)
  • RESLIB_TEST_SERVER please log a bug report. ‒ shouldn't that be file?

comment:7 Changed 9 years ago by stephen

  • Owner changed from stephen to vorner

RESOLVER_AXFR_UDP says it was received over TCP. Possibly a copy-paste leftover?

Yes - fixed.

RESOLVER_SET_ROOT_ADDRESS Typo? (oncee)

Fixed.

RESLIB_TEST_SERVER please log a bug report. ‒ shouldn't that be file?

I went for a third option - "Please submit a bug report".

comment:8 Changed 9 years ago by vorner

It looks OK, please merge.

comment:9 Changed 9 years ago by vorner

  • Owner changed from vorner to stephen

comment:10 Changed 9 years ago by stephen

  • Resolution set to complete
  • Status changed from reviewing to closed

Merged into master, commit a2a8094104e32ed8249c2811c94f74b876f78b3d

Note: See TracTickets for help on using tickets.