Differences of Bind 10 to other software
========================================

BIND 9
------

TODO: There are definitely more differences than just this.

DNS zone transfer:
* When an incoming zone transfer fails, for example because the
  received zone doesn't contain a NS record, bind 9 stops serving the
  zone and returns SERVFAIL to queries for that zone. Bind 10 still
  uses the previous version of zone.

RDATA implementations:
* IN/A: BIND 10 does not accept abbreviated forms of textual IPv4
  addresses for class-IN, type-A RDATA.  BIND 9 warns about it but
  still accepts it as the standard inet_aton() function.  Such forms
  should actually be NOT accepted per RFC 1035, but BIND 9 accepts them
  probably because of compatibility reasons.  Until our strict
  (and more correct) behavior causes operations issues, we'll keep it.

DNS data sources:
* In-memory data source does not sort RDATA of each RRset (in the
  DNSSEC order) while BIND 9 normally sorts them internally.  The main
  purpose of the BIND 9's behavior is to make the ordering
  predictable, but if the RDATA are rotated in DNS responses (which
  BIND 9 also does by default) the predictability wouldn't be that
  useful for the clients.  So we skip the sorting in the BIND 10
  implementation to simplify the implementation (and possibly make it
  a bit more efficient).

* If different RRs of the same RRset and their RRSIGs have different
  TTL when loaded to the in-memory data source, the lowest TTL among
  all RRs (whether it's the covered RRset or RRSIGs) will be used.
  BIND 9 shows some inconsistent policy on this point for unknown
  reason (sometimes the TTL of the first RR is used, sometimes the
  latest one is used).  We differ here firstly for consistency, and
  because it seems to be more compliant to the sense of RFC2181.
  In any case, the administrator should make the TTLs same, especially
  if the zone is signed, as described in RFC4034 (and, that will be
  normally ensured by zone signing tools).