|
@@ -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).
|