blob: 41cf3cd98cc35b0b5ba75fa68ce1df9095e39cbf (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
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).
|
