BIND 10 #1938: why ZONEMGR_UNKNOWN_ZONE_NOTIFIED ?

BIND 10 Development do-not-reply at isc.org
Wed Mar 20 07:49:46 UTC 2013


#1938: why ZONEMGR_UNKNOWN_ZONE_NOTIFIED ?
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |  jinmei
            Priority:  high          |                       Status:
           Component:  secondary     |  accepted
  manager                            |                    Milestone:
            Keywords:                |  Sprint-20130402
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  5             |              Defect Severity:
         Total Hours:  0             |  Medium
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac1938 is ready for review.

 There are several points to be fixed/improved, and each is mostly
 independent.

 - b10-auth should have checked if it has authority for the zone in the
   NOTIFY (there was actually a TODO).  This branch does that.  And,
   I believe it suppresses most of the noisy logs reported in this
   ticket.  BTW, this check could also be done in zonemgr, but I chose
   to do it in auth, because such bogus NOTIFY seems to be not so
   uncommon (as was reported in this ticket), and so it'd be better to
   deal with them without involving expensive inter-module
   communication.  Changes up to af2ca1d (and b058641) address this
   issue.

 - still, zonemgr's behavior doesn't make sense.  It's completely
   possible that a primary server receives a NOTIFY.  So calling it
   "unknown" at the error level is obviously wrong.  I've lowered log
   level, revised the log message and description to explain the
   situation more accurately, and made sure it doesn't trigger another
   error log at b10-auth.  These changes are up to 0b8dd6b.

 - Finally, I tried to add some lettuce tests that cover these cases,
   and then I noticed existing notify related tests have something that
   doesn't make sense in waiting for log messages:
 {{{
     Then wait 5 times for new master stderr message
 NOTIFY_OUT_SENDING_NOTIFY
     Then wait for new master stderr message NOTIFY_OUT_RETRY_EXCEEDED
 }}}
   In these cases the notify should have been responded, so counting
   timeouts doesn't make sense.  It actually seems to be a bug of
   notify_out, but instead of fixing it in this ticket, I've added one
   small log message to notify_out when it receives a valid response to
   NOTIFY, and used it for the newly added tests.  Last few commits are
   for these tests.

 I believe the branch now addresses all issues discussed in this
 ticket.

 Proposed changelog:
 {{{
 592.?   [bug]           jinmei
         b10-auth and zonemgr now handle some uncommon NOTIFY messages more
         gracefully: auth immediately returns a NOTAUTH response if the
         server does not have authority for the zone (the behavior
         compatible with BIND 9) without bothering zonemgr; zonemgr now
         simply skips retransfer if the specified zone is not in its
         secondary zone list, instead of producing noisy error logs.
         (Trac #1938, git TBD)
 }}}

-- 
Ticket URL: <http://bind10.isc.org/ticket/1938#comment:15>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list