Remove rfc-compliance list in plaintext - ARM deduplication
The plaintext version is now fully replaced by the doc/arm/general.rst.
This commit is contained in:
Petr Špaček
@@ -1,170 +0,0 @@
|
||||
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
|
||||
|
||||
SPDX-License-Identifier: MPL-2.0
|
||||
|
||||
This Source Code Form is subject to the terms of the Mozilla Public
|
||||
License, v. 2.0. If a copy of the MPL was not distributed with this
|
||||
file, you can obtain one at https://mozilla.org/MPL/2.0/.
|
||||
|
||||
See the COPYRIGHT file distributed with this work for additional
|
||||
information regarding copyright ownership.
|
||||
|
||||
BIND 9 is striving for strict compliance with IETF standards. We
|
||||
believe this release of BIND 9 complies with the following RFCs, with
|
||||
the caveats and exceptions listed in the numbered notes below. Note
|
||||
that a number of these RFCs do not have the status of Internet
|
||||
standards but are proposed or draft standards, experimental RFCs,
|
||||
or Best Current Practice (BCP) documents. The list is non exhaustive.
|
||||
|
||||
RFC1034
|
||||
RFC1035 [1] [2]
|
||||
RFC1101
|
||||
RFC1123
|
||||
RFC1183
|
||||
RFC1521 [16]
|
||||
RFC1535
|
||||
RFC1536
|
||||
RFC1706
|
||||
RFC1712
|
||||
RFC1750
|
||||
RFC1876
|
||||
RFC1982
|
||||
RFC1995
|
||||
RFC1996
|
||||
RFC2136
|
||||
RFC2163
|
||||
RFC2181
|
||||
RFC2230
|
||||
RFC2308
|
||||
RFC2539
|
||||
RFC2606 [17]
|
||||
RFC2782
|
||||
RFC2874 [18]
|
||||
RFC2930
|
||||
RFC2931 [5]
|
||||
RFC3007
|
||||
RFC3110
|
||||
RFC3123
|
||||
RFC3225
|
||||
RFC3226
|
||||
RFC3363 [6]
|
||||
RFC3403
|
||||
RFC3493
|
||||
RFC3496
|
||||
RFC3597
|
||||
RFC3645
|
||||
RFC4025
|
||||
RFC4033
|
||||
RFC4034
|
||||
RFC4035
|
||||
RFC4074
|
||||
RFC4255
|
||||
RFC4294 - Section 5.1 [8]
|
||||
RFC4343
|
||||
RFC4398
|
||||
RFC4431 [22]
|
||||
RFC4470 [9]
|
||||
RFC4509
|
||||
RFC4592
|
||||
RFC4635
|
||||
RFC4701
|
||||
RFC4892
|
||||
RFC4955 [10]
|
||||
RFC5001
|
||||
RFC5011
|
||||
RFC5155
|
||||
RFC5205
|
||||
RFC5452 [11]
|
||||
RFC5702
|
||||
RFC5891 [7]
|
||||
RFC5936
|
||||
RFC5952
|
||||
RFC6052
|
||||
RFC6147 [12]
|
||||
RFC6303
|
||||
RFC6604
|
||||
RFC6605 [13]
|
||||
RFC6672
|
||||
RFC6698
|
||||
RFC6742
|
||||
RFC6725 [19]
|
||||
RFC6840 [14]
|
||||
RFC6891
|
||||
RFC7043
|
||||
RFC7050 [21]
|
||||
RFC7208
|
||||
RFC7314
|
||||
RFC7344 [20]
|
||||
RFC7477
|
||||
RFC7553
|
||||
RFC7766
|
||||
RFC7793
|
||||
RFC7830 [15]
|
||||
RFC7929
|
||||
RFC8078 [20]
|
||||
RFC8080
|
||||
RFC8624
|
||||
RFC8659
|
||||
RFC8880
|
||||
RFC8945
|
||||
|
||||
[1] Queries to zones that have failed to load return SERVFAIL rather
|
||||
than a non-authoritative response. This is considered a feature.
|
||||
|
||||
[2] CLASS ANY queries are not supported. This is considered a
|
||||
feature.
|
||||
|
||||
[5] When receiving a query signed with a SIG(0), the server will
|
||||
only be able to verify the signature if it has the key in its local
|
||||
authoritative data; it will not do recursion or validation to
|
||||
retrieve unknown keys.
|
||||
|
||||
[6] Section 4 is ignored.
|
||||
|
||||
[7] Requires --with-libidn2 to enable entry of IDN labels within dig,
|
||||
host and nslookup at compile time. ACE labels are supported
|
||||
everywhere with or without --with-libidn2.
|
||||
|
||||
[8] Section 5.1 - DNAME records are fully supported.
|
||||
|
||||
[9] Minimally Covering NSEC Record are accepted but not generated.
|
||||
|
||||
[10] Will interoperate with correctly designed experiments.
|
||||
|
||||
[11] Named only uses ports to extend the id space, address are not
|
||||
used.
|
||||
|
||||
[12] Section 5.5 does not match reality. Named uses the presence
|
||||
of DO=1 to detect if validation may be occurring. CD has no bearing
|
||||
on whether validation is occurring or not.
|
||||
|
||||
[13] Conditional on the OpenSSL library being linked against
|
||||
supporting ECDSA.
|
||||
|
||||
[14] Section 5.9 - Always set CD=1 on queries. This is *not* done as
|
||||
it prevents DNSSEC working correctly through another recursive server.
|
||||
|
||||
When talking to a recurive server the best algorithm to do is send
|
||||
CD=0 and then send CD=1 iff SERVFAIL is returned in case the recurive
|
||||
server has a bad clock and/or bad trust anchor. Alternatively one
|
||||
can send CD=1 then CD=0 on validation failure in case the recursive
|
||||
server is under attack or there is stale / bogus authoritative data.
|
||||
|
||||
[15] Named doesn't currently encrypt DNS requests so the PAD option
|
||||
is accepted but not returned in responses.
|
||||
|
||||
[16] Only the Base 64 encoding specification.
|
||||
|
||||
[17] Not applicable to DNS server implementations.
|
||||
|
||||
[18] Loading and serving of A6 records only. A6 records were moved
|
||||
to the experimental category by RFC3363.
|
||||
|
||||
[19] RSAMD5 support has been removed. See RFC 6944 and RFC 8624.
|
||||
|
||||
[20] Updating of parent zones is not yet implemented.
|
||||
|
||||
[21] RFC 7050 is updated by RFC 8880
|
||||
|
||||
[22] Compliance is with loading and serving of DLV records only.
|
||||
DLV records were moved to the historic category by RFC 8749.
|
||||
Reference in New Issue
Block a user