[bind10-dev] Behaviour with Duplicate RRs in Zone File

[Stephen Morris]

What should be the behaviour of BIND 10 when a zone file is loaded
that contains a duplicate record?

If the following zone file is loaded into BIND 10:

$ORIGIN example.
$TTL 3600
@	IN	SOA	ns2.example. hostmaster.example. 100 3600 900 7200 300
	IN	NS	ns2.example.
	IN	NS	ns3.example.

ns2 	IN 	A   192.0.2.254
ns3	IN 	A   192.0.2.253

identical	IN	A	192.0.2.1
identical	IN	A	192.0.2.1

... querying for identical.example. returns a response with the answer
section containing two A records.  In contrast, BIND 9.8.1 ignores
identical records; when loaded with the above zone file, it returns an
answer section containing one A record.

I think the BIND 10 should follow BIND 9.  If nothing else, we would
have problems were the BIND 9 server to be a slave to BIND 10; it
would be possible for the master and slave to issue different answers
to the same query.

BIND 10 is merely reflecting what is in the SQLite database, so the
issue is in b10-loadzone.  But even if we change b10-loadzone, there
is still the question of how to prevent the database holding identical
RRs.  One way would be to use the hash of the RR as the primary key of
the table, instead of the auto-incrementing integer we presently use.
However, this would rely on a captive interface to the database to
ensure that insertions or modifications update the hash correctly, and
the pros and cons of that have been discussed in another thread.

This issue came up in the context of IXFR system tests.  RFC 1995
states that the modification of an RR is performed first by removing
the original RR then adding the modified one.  This seems to imply
that the order of that sequence is important - performing the
operations in the reverse order (adding the new RR and removing the
original one) may give different results.  However, I'm struggling to
find a case (other than one involving identical RRs in a zone and
contrived assumptions about the handling of RR deletion) where the
order of operations is important.  Can anyone offer an example?

Stephen