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