Browse Source

[2440] noted some differences from BIND 9

JINMEI Tatuya 12 years ago
parent
commit
896dd15f4a
1 changed files with 20 additions and 0 deletions
  1. 20 0
      doc/differences.txt

+ 20 - 0
doc/differences.txt

@@ -10,3 +10,23 @@ TODO: There are definitely more differences than just this.
   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.
+
+* 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).