Commit e51d6fd3 authored by JINMEI Tatuya's avatar JINMEI Tatuya
Browse files

[2964] updated _get_zone_soa so it won't auto create a new zone anymore.

test cases were adjusted.  in particular, test_do_axfrin_nozone_sqlite3
was simply removed; it's okay as it only intended to the old behavior
parent edc1911c
......@@ -861,9 +861,11 @@ class TestXfrinConnection(unittest.TestCase):
self.conn._zone_name = zone_name
self.conn._zone_soa = xfrin._get_zone_soa(self.conn._datasrc_client,
self.conn._zone_soa = xfrin._get_zone_soa(
self.conn._datasrc_client, zone_name, self.conn._rrclass)
except XfrinException: # zone doesn't exist
self.conn._zone_soa = None
class TestAXFR(TestXfrinConnection):
def setUp(self):
......@@ -2116,32 +2118,6 @@ class TestXFRSessionWithSQLite3(TestXfrinConnection):
def test_do_axfrin_nozone_sqlite3(self):
'''AXFR test with an empty SQLite3 DB file, thus no target zone there.
For now, we provide backward compatible behavior: xfrin will create
the zone (after even setting up the entire schema) in the zone.
Note: a future version of this test will make it fail.
self.conn._db_file = self.empty_sqlite3db_obj
self.conn._datasrc_client = DataSourceClient(
"{ \"database_file\": \"" + self.empty_sqlite3db_obj + "\"}")
def create_response():
self.conn.reply_data = self.conn.create_response_data(
questions=[Question(TEST_ZONE_NAME, TEST_RRCLASS,
answers=[soa_rrset, self._create_ns(), soa_rrset])
self.conn.response_generator = create_response
self.assertEqual(XFRIN_OK, self.conn.do_xfrin(False, RRType.AXFR))
self.assertEqual(1234, self.get_zone_serial().get_value())
class TestStatisticsXfrinConn(TestXfrinConnection):
'''Test class based on TestXfrinConnection and including paramters
and methods related to statistics tests'''
......@@ -1773,6 +1773,10 @@ def _get_zone_soa(datasrc_client, zone_name, zone_class):
be called (or tweaked) from tests; no one else should use this
function directly.
The specified zone is expected to exist in the data source referenced
by the given datasrc_client at the point of the call to this function.
If this is not met XfrinException exception will be raised.
It will be used for various purposes in subsequent xfr protocol
processing. It is validly possible that the zone is currently
empty and therefore doesn't have an SOA, so this method doesn't
......@@ -1784,34 +1788,15 @@ def _get_zone_soa(datasrc_client, zone_name, zone_class):
valid, i.e., it has exactly one RDATA; if it is not the case
this method returns None.
If the underlying data source doesn't even know the zone, this method
tries to provide backward compatible behavior where xfrin is
responsible for creating zone in the corresponding DB table.
For a longer term we should deprecate this behavior by introducing
more generic zone management framework, but at the moment we try
to not surprise existing users.
# datasrc_client should never be None in production case (only tests could
# specify None)
if datasrc_client is None:
return None
# get the zone finder. this must be SUCCESS (not even
# PARTIALMATCH) because we are specifying the zone origin name.
result, finder = datasrc_client.find_zone(zone_name)
if result != DataSourceClient.SUCCESS:
# The data source doesn't know the zone. For now, we provide
# backward compatibility and creates a new one ourselves.
# For longer term, we should probably separate this level of zone
# management outside of xfrin.
logger.warn(XFRIN_ZONE_CREATED, format_zone_str(zone_name, zone_class))
# try again
result, finder = datasrc_client.find_zone(zone_name)
if result != DataSourceClient.SUCCESS:
return None
# The data source doesn't know the zone. In the context of this
# function is called, this shouldn't happen.
raise XfrinException("unexpected result: zone %s doesn't exist" %
format_zone_str(zone_name, zone_class))
result, soa_rrset, _ = finder.find(zone_name, RRType.SOA)
if result != ZoneFinder.SUCCESS:, format_zone_str(zone_name, zone_class))
......@@ -266,19 +266,6 @@ is recommended to check the primary server configuration.
A connection to the master server has been made, the serial value in
the SOA record has been checked, and a zone transfer has been started.
% XFRIN_ZONE_CREATED Zone %1 not found in the given data source, newly created
On starting an xfrin session, it is identified that the zone to be
transferred is not found in the data source. This can happen if a
secondary DNS server first tries to perform AXFR from a primary server
without creating the zone image beforehand (e.g. by b10-loadzone). As
of this writing the xfrin process provides backward compatible
behavior to previous versions: creating a new one in the data source
not to surprise existing users too much. This is probably not a good
idea, however, in terms of who should be responsible for managing
zones at a higher level. In future it is more likely that a separate
zone management framework is provided, and the situation where the
given zone isn't found in xfrout will be treated as an error.
% XFRIN_ZONE_INVALID Newly received zone %1/%2 fails validation: %3
The zone was received successfully, but it failed validation. The problem
is severe enough that the new version of zone is discarded and the old version,
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment