BIND 10 #1298: don't do xfrin upon notify when address is unknown

BIND 10 Development do-not-reply at isc.org
Wed Oct 12 16:15:45 UTC 2011


#1298: don't do xfrin upon notify when address is unknown
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  UnAssigned
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:  New Tasks
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jreed):

 It appears to work,  but the error message happened 29 seconds later. Why
 delayed?

 {{{

 2011-10-12 11:07:45.559 DEBUG [b10-auth.auth] AUTH_PACKET_RECEIVED message
 received:
 ;; ->>HEADER<<- opcode: NOTIFY, status: NOERROR, id: 22742
 ...

 2011-10-12 11:07:45.560 DEBUG [b10-auth.cc] CC_GROUP_SEND sending message
 '{ "command": [ "notify", { "master": "192.168.1.2", "zone_class": "IN",
 "zone_name": "foo." } ] }' to group 'Zonemgr'

 2011-10-12 11:07:45.560 DEBUG [b10-zonemgr.zonemgr] ZONEMGR_RECEIVE_NOTIFY
 received NOTIFY command for zone foo. (class IN)

 2011-10-12 11:07:45.565 DEBUG [b10-zonemgr.zonemgr]
 ZONEMGR_RECEIVE_XFRIN_FAILED received XFRIN FAILED command for zone foo.
 (class IN)

 2011-10-12 11:08:14.170 DEBUG [b10-zonemgr.zonemgr] ZONEMGR_REFRESH_ZONE
 refreshing zone foo. (class IN)

 2011-10-12 11:08:14.173 ERROR [b10-xfrin.xfrin]
 XFRIN_NOTIFY_UNKNOWN_MASTER got notification to retransfer zone foo. from
 192.168.1.2, expected 192.168.1.4

 }}}

 Also ERROR probably should not be used for issues out of our control.
 Maybe WARN?

 Also will this work with a list of acceptable master addresses?

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


More information about the bind10-tickets mailing list