[bind10-dev] #1217 doesn't work for some systems / adjust_ttl vs separate_rr?

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Thu Nov 10 18:47:26 UTC 2011


I noticed the new tests added in #1217 (already merged) didn't work on
my system, and I suspect the test assumes a specific ordering for
records returned by SQLite3 which is not held on all systems.

in datasrc_test.py:DataSrcClient.test_iterate, it sets up the expected
RRSIGs as follows:

        add_rrset(expected_rrset_list, name, rrclass,
                  isc.dns.RRType.RRSIG(), isc.dns.RRTTL(3600), None)
        add_rrset(expected_rrset_list, name, rrclass,
                  isc.dns.RRType.RRSIG(), isc.dns.RRTTL(7200), None)
        add_rrset(expected_rrset_list, name, rrclass,
                  isc.dns.RRType.RRSIG(), isc.dns.RRTTL(3600), None)

so the test expects the RRSIGs in the form of 3 separate RRsets from
the zone iterator (with adjust_ttl being False).  But on my system
they are given in 2 RRsets, so the test fails here:

        # Now check there are none left
        self.assertEqual(0, len(expected_rrset_list),

I've looked into the test sqlite3 database file and performs the
statement for iteration by hand.  The result is:

sqlite> SELECT rdtype, ttl, sigtype, rdata, name FROM records WHERE zone_id=2 order by rname, rdtype;
RRSIG|3600|DNSKEY|...
RRSIG|3600|DNSKEY|...
RRSIG|3600|NS|...
RRSIG|3600|SOA|...
RRSIG|7200|NSEC|...

I guess in your environment the RRSIG with the TTL of 7200 is in the
middle of the sequence, and so the underlying database.cc code builds
the three RRsets: the first set with TTL of 3600, the 7200 one, and
the second set with TTL of 3600.  As my example shows, this assumption
doesn't always seem to hold.

Tweaking the test to address this wouldn't be super hard, but I
couldn't come up with a 1-liner-ish fix, so for now I disabled the
entire test:

    @unittest.skip("This test may fail depending on sqlite3 library behavior")
    def test_iterate(self):

Could you check this at your earliest opportunity and make the test
workable without the assumption?

On a related note: while 'adjust_ttl' literally addresses the topic of
#1217, I personally don't think it's what the application really wants
(or cares).  IMO they would rather see RRs as separate RRsets.  At
least for AXFR-out, technically simply preserving TTLs is not correct,
because we should also keep the label case of owner names.  If the
underlying data source combines two or more RRs using different case
styles (example.com vs EXAMPLE.COM) into a single RRset, we break this
requirement (although it would be much harmless in practice than the
TTL issue).  I believe we should provide a more generic option, say,
"separate_rr", which would request the iterator return each RR in a
separate RRset.  If we do this, addressing the above test regression
will be much easier: we may still not rely on a specific order, but at
least we can assume the number of expected RRsets reliably.

---
JINMEI, Tatuya



More information about the bind10-dev mailing list