BIND 10 #2439: update xfrin so it performs post transfer checks
BIND 10 Development
do-not-reply at isc.org
Thu Jan 24 07:52:20 UTC 2013
#2439: update xfrin so it performs post transfer checks
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: task | jinmei
Priority: medium | Status:
Component: xfrin | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-20130205
Sub-Project: DNS | Resolution:
Estimated Difficulty: 3 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| loadzone-ng
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Comment (by jinmei):
'''changelog'''
I suspect there is actually no possibility of missing SOA (that would
be identified by this check) due to the protocol characteristics of
XFRs. Maybe a minor point and no one cares, but to be very accurate
we might say, e.g., just "such as missing NS (at zone origin)".
'''xfrin.py.in'''
- This comment seems to have to be updated:
{{{#!python
# The final part is there. Check all was signed
# and commit it to the database.
}}}
It may not necessarily be considered "incorrect", but due to the
change in the code that follows, I see some gap between the actual
code and the comment. (e.g., in the new code it's not immediately
clear why it mentions "signed" here).
- Same for the docstring for finish_message().
- I've noticed a slight gap from BIND 9 (based on code inspection, so
maybe I'm wrong): in case of IXFR, BIND 9 commits the diffs to
before post-xfr checks. So, even if it fails the persistent DB is
still updated. It still drops the in-memory DB, but doesn't revert
to the pre-xfr version. So queries to that zone will result in
SERVFAIL after that. I don't know the rationale about this behavior
(if I'm correct), but I suggest (1) check if my understanding is
correct yourself (2) (as usual) ask why BIND 9 behaves that way (3)
then, think about what we should do. (4) as a result of that, update
the implementation if necessary.
'''xfrin_test.py'''
I'd test some more cases:
- Confirm warnings (by themselves) don't result in rejection.
- IXFR case
- check at least one rejection case with sqlite3. it's redundant in
some sense, but sometimes we (I) find real-world cases have an issue
that aren't revealed just with mocks.
'''xfrin_messages.mes'''
I'm not sure if we call failure of post-transfer checks a "protocol
error". At least there was no protocol error in the xfr session. If
we keep reusing this message (and the exception), I'd clarify that in
the detailed description for XFRIN_XFR_TRANSFER_PROTOCOL_ERROR.
Also, wherever we note that, I'd also describe some more things:
- clarify that the new zone is dropped and won't be used (and if there
was an old version it will still be used)
- when mentioning the possibility of post-zone check failure, refer to
XFRIN_ZONE_INVALID (suggesting to check the log to see if there's
some of that).
- depending on what to do with the gap from BIND 9 discussed above,
explain the difference from BIND 9 and the rationale.
- related, although not directly related to this task: there's another
gap from BIND 9: we don't commit IXFR unless all IXFR responses are
processed. So there's another type of difference in the DB state
if IXFR is rejected in the middle of it. I'd explain the difference
and the rationale here, too.
'''diff.py'''
- This part of docstring is awkward:
{{{
[...] Then it creates
and returns an RRsetCollection on top of the corresponding zone
updater and returns it.
}}}
Maybe just remove "and returns it".
'''diff_tests.py'''
- the comment should be "it is applied"?
{{{#!python
# Check it is commited
self.assertEqual(1, len(self.__data_operations))
self.assertEqual('add', self.__data_operations[0][0])
}}}
- As for this:
{{{#!python
# Any idea why python doesn't agree with inheriting from
# dns.RRsetCollection?
}}}
I don't know what you wanted to do by inheriting from
`dns.RRsetCollection` (not from the base), but if it's really
necessary you should specify `Py_TPFLAGS_BASETYPE` in the `tp_flags`
field of the corresponding `PyTypeObject`. See the difference of
this member between `rrset_collection_base_type` and
`rrset_collection_type`. But in any event, in this particular case
I don't see the need for that trick: the current mock seems to be
sufficient.
--
Ticket URL: <http://bind10.isc.org/ticket/2439#comment:9>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list