BIND 10 #816: TSIG: update XFROUT to use TSIG
BIND 10 Development
do-not-reply at isc.org
Fri Jun 3 04:13:39 UTC 2011
#816: TSIG: update XFROUT to use TSIG
-------------------------------------+-------------------------------------
Reporter: | Owner: stephen
stephen | Status: reviewing
Type: | Milestone:
enhancement | Sprint-20110614
Priority: minor | Resolution:
Component: | Sensitive: 0
xfrout | Sub-Project: DNS
Keywords: | Estimated Difficulty: 5.0
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: tsig |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by zzchen_pku):
* owner: zzchen_pku => stephen
Comment:
Replying to [comment:7 stephen]:
> '''src/bin/xfrout/xfrout.py.in'''
> dns_xfrout_start()
> the check on rcode_ returned from _parse_query_message will not cope
with errors other than FORMERR or NOTAUTH. The logic should be:
> {{{
> if rcode_ == Rcode.NOTAUTH():
> return self._reply_query_with_error_rcode(msg, sock_fd, rcode_)
> elif rcode_ != Rcode.NOERROR():
> return self._reply_query_with_format_error(msg, sock_fd)
> }}}
Good suggestion, updated.
> _reply_xfrout_query()
> Within _send_message_with_last_soa(), the length of the TSIG RR is added
to the message_upper_len argument when checking against
XFROUT_MAX_MESSAGE_SIZE. However, if the main loop ends when the next
packet to be sent should include a signature, on exit from the loop,
message_upper_len will include the length of the TSIG RR. In this case,
the TSIG RR length is being included in the calculation twice.
Yeah, I have update the handling logic.
> set_tsig_key_ring()
> Is the comment for this method correct? It appears to apply to setting
the TSIG key for a zone, not populating the key ring.
Update the comment, and add a TODO item, which will be done in #943
>
> '''src/bin/xfrout/tests/xfrout_test.py.in'''
> create_request_data_with_tsig()
> There appears to be some line of code (starting
'self.create_mock_tsig_ctx...') temporarily commented out.
Removed it.
> The "magic number" 655020 seems to be related to the variable
XFROUT_MAX_MESSAGE_SIZE in the main code. As it is the relationship
between the two - rather than the absolute value - that appears to be
important, I suggest it be defined as a variable equal to
(XFROUT_MAX_MESSAGE_SIZE - 15) (together with a comment explaining why
there is the relationship).
Done.
Please check , thanks for your review.
--
Ticket URL: <http://bind10.isc.org/ticket/816#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list