blob: 4c87c66242bd2c899f51fa5fa836dc6d0fa097af (
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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 2001 Internet Software Consortium.
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
$Id: rfc-compliance,v 1.4 2004/03/05 05:04:53 marka Exp $
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.
RFC1034
RFC1035 [1] [2]
RFC1123
RFC1183
RFC1535
RFC1536
RFC1706
RFC1712
RFC1750
RFC1876
RFC1982
RFC1995
RFC1996
RFC2136
RFC2163
RFC2181
RFC2230
RFC2308
RFC2535 [3] [4]
RFC2536
RFC2537
RFC2538
RFC2539
RFC2671
RFC2672
RFC2673
RFC2782
RFC2915
RFC2930
RFC2931 [5]
RFC3007
[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.
[3] Wildcard records are not supported in DNSSEC secure zones.
[4] Servers authoritative for secure zones being resolved by BIND 9
must support EDNS0 (RFC2671), and must return all relevant SIGs and
NXTs in responses rather than relying on the resolving server to
perform separate queries for missing SIGs and NXTs.
[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.
|
