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
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
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]
RFC1123
RFC1183
RFC1535
RFC1536
RFC1706
RFC1712
RFC1750
RFC1876
RFC1982
RFC1995
RFC1996
RFC2136
RFC2163
RFC2181
RFC2230
RFC2308
RFC2536
RFC2539
RFC2782
RFC2915
RFC2930
RFC2931 [5]
RFC3007
RFC3110
RFC3123
RFC3225
RFC3226
RFC3363 [6]
RFC3490 [7]
RFC3491 (Obsoleted by 5890, 5891) [7]
RFC3493
RFC3496
RFC3597
RFC3645
RFC4025
RFC4034
RFC4035
RFC4074
RFC4255
RFC4294 - Section 5.1 [8]
RFC4343
RFC4398
RFC4408
RFC4431
RFC4470 [9]
RFC4509
RFC4635
RFC4701
RFC4892
RFC4955 [10]
RFC5001
RFC5011
RFC5155
RFC5205
RFC5452 [11]
RFC5702
RFC5933 [12]
RFC5936
RFC5952
RFC5966
RFC6052
RFC6147 [13]
RFC6303
RFC6605 [14]
RFC6672
RFC6698
RFC6742
RFC6840 [15]
RFC6844
RFC6891
RFC7043
RFC7314
RFC7477
RFC7793
RFC7830 [16]
The following DNS related RFC have been obsoleted
RFC2535 (Obsoleted by 4034, 4035) [3] [4]
RFC2537 (Obsoleted by 3110)
RFC2538 (Obsoleted by 4398)
RFC2671 (Obsoleted by 6891)
RFC2672 (Obsoleted by 6672)
RFC2673 (Obsoleted by 6891)
RFC3008 (Obsoleted by 4034, 4035)
RFC3152 (Obsoleted by 3596)
RFC3445 (Obsoleted by 4034, 4035)
RFC3655 (Obsoleted by 4034, 4035)
RFC3658 (Obsoleted by 4034, 4035)
RFC3755 (Obsoleted by 4034, 4035)
RFC3757 (Obsoleted by 4034, 4035)
RFC3845 (Obsoleted by 4034, 4035)
[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.
[6] Section 4 is ignored.
[7] Requires --with-idn to enable entry of IDN labels within dig,
host and nslookup at compile time. ACE labels are supported
everywhere with or without --with-idn.
[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] Conditional on the OpenSSL library being linked against
supporting GOST.
[13] Section 5.5 does not match reality. Named uses the presence
of DO=1 to detect if validation may be occuring. CD has no bearing
on whether validation is occuring or not.
[14] Conditional on the OpenSSL library being linked against
supporting ECDSA.
[15] 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.
[16] Named doesn't currently encrypt DNS requests so the PAD option
is accepted but not returned in responses.
|
