]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
[v1_0_0] differences.txt file removed
authorWlodek Wencel <wlodek@isc.org>
Thu, 3 Dec 2015 14:41:59 +0000 (15:41 +0100)
committerWlodek Wencel <wlodek@isc.org>
Fri, 4 Dec 2015 12:15:11 +0000 (13:15 +0100)
doc/Makefile.am
doc/differences.txt [deleted file]

index dd0074430f7bec1225e3227489b0e00475f57f3a..dc9a389157591c45d37c11e6558abef2bc864358 100644 (file)
@@ -1,6 +1,6 @@
 SUBDIRS = guide design
 
-EXTRA_DIST  = version.ent.in differences.txt Doxyfile Doxyfile-xml
+EXTRA_DIST  = version.ent.in Doxyfile Doxyfile-xml
 EXTRA_DIST += devel/config-backend.dox
 EXTRA_DIST += devel/contribute.dox
 EXTRA_DIST += devel/mainpage.dox
diff --git a/doc/differences.txt b/doc/differences.txt
deleted file mode 100644 (file)
index 41cf3cd..0000000
+++ /dev/null
@@ -1,42 +0,0 @@
-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).