| 1234567891011121314151617181920212223242526272829303132 |
- Differences of Bind 10 to other software
- ========================================
- Bind 9
- ------
- TODO: There are definitely more differences than just this.
- * 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.
- * 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).
|
