1 Internet Engineering Task Force (IETF) M. Blanchet
2 Request for Comments: 7720 Viagenie
3 BCP: 40 L-J. Liman
4 Obsoletes: 2870 Netnod
5 Category: Best Current Practice December 2015
6 ISSN: 2070-1721
7
8
9 DNS Root Name Service Protocol and Deployment Requirements
10
11 Abstract
12
13 The DNS root name service is a critical part of the Internet
14 architecture. The protocol and deployment requirements for the DNS
15 root name service are defined in this document. Operational
16 requirements are out of scope.
17
18 Status of This Memo
19
20 This memo documents an Internet Best Current Practice.
21
22 This document is a product of the Internet Engineering Task Force
23 (IETF). It represents the consensus of the IETF community. It has
24 received public review and has been approved for publication by the
25 Internet Engineering Steering Group (IESG). Further information on
26 BCPs is available in Section 2 of RFC 5741.
27
28 Information about the current status of this document, any errata,
29 and how to provide feedback on it may be obtained at
30 http://www.rfc-editor.org/info/rfc7720.
31
32 Copyright Notice
33
34 Copyright (c) 2015 IETF Trust and the persons identified as the
35 document authors. All rights reserved.
36
37 This document is subject to BCP 78 and the IETF Trust's Legal
38 Provisions Relating to IETF Documents
39 (http://trustee.ietf.org/license-info) in effect on the date of
40 publication of this document. Please review these documents
41 carefully, as they describe your rights and restrictions with respect
42 to this document. Code Components extracted from this document must
43 include Simplified BSD License text as described in Section 4.e of
44 the Trust Legal Provisions and are provided without warranty as
45 described in the Simplified BSD License.
46
47
48
49
50
51
52 Blanchet & Liman Best Current Practice [Page 1]
53 RFC 7720 Root Name Service Requirements December 2015
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 1.1. Relationship to RFC 2870 . . . . . . . . . . . . . . . . 2
60 2. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 3
61 3. Deployment Requirements . . . . . . . . . . . . . . . . . . . 3
62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
63 5. Informative References . . . . . . . . . . . . . . . . . . . 4
64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
66
67 1. Introduction
68
69 [RFC2870] discusses protocol and operational requirements for root
70 name servers for the Internet's domain name system (DNS) protocol
71 [RFC1035]. Since its publication, both protocol and operational
72 requirements have evolved. It makes more sense now to separate the
73 two sets of requirements into two separate documents. This document
74 only defines the protocol requirements and some deployment
75 requirements. The operational requirements that were defined in RFC
76 2870 have been removed. Operational requirements are now defined by
77 the Root Server System Advisory Committee of ICANN and are documented
78 in [RSSAC-001].
79
80 The root servers are authoritative servers of the unique [RFC2826]
81 root zone (".") [ROOTZONE]. They currently also serve the root-
82 servers.net zone. Some also serve the zone for the .arpa top-level
83 domain [ARPAZONE] [RFC3172]. This document describes the external
84 interface of the root name servers from a protocol viewpoint of the
85 service. It specifies basic requirements for the Internet that DNS
86 clients meet when interacting with a root name service over the
87 public Internet.
88
89 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
90 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
91 document, are to be interpreted as described in BCP 14, [RFC2119].
92
93 1.1. Relationship to RFC 2870
94
95 This document obsoletes [RFC2870].
96
97 This document and [RSSAC-001] together functionally replace
98 [RFC2870].
99
100
101
102
103
104
105
106
107 Blanchet & Liman Best Current Practice [Page 2]
108 RFC 7720 Root Name Service Requirements December 2015
109
110
111 2. Protocol Requirements
112
113 This section describes the minimum high-level protocol requirements.
114 Operative details are documented in [RSSAC-001].
115
116 The root name service:
117
118 o MUST implement core DNS [RFC1035] and clarifications to the DNS
119 [RFC2181].
120
121 o MUST support IPv4 [RFC791] and IPv6 [RFC2460] transport of DNS
122 queries and responses.
123
124 o MUST support UDP [RFC768] and TCP [RFC793] transport of DNS
125 queries and responses.
126
127 o MUST generate checksums when sending UDP datagrams and MUST verify
128 checksums when receiving UDP datagrams containing a non-zero
129 checksum.
130
131 o MUST implement DNSSEC [RFC4035] as an authoritative name service.
132
133 o MUST implement extension mechanisms for DNS (EDNS(0)) [RFC6891].
134
135 3. Deployment Requirements
136
137 The root name service:
138
139 o MUST answer queries from any entity conforming to [RFC1122] with a
140 valid IP address.
141
142 o MUST serve the unique [RFC2826] root zone [ROOTZONE].
143
144 4. Security Considerations
145
146 This document does not specify a new protocol. However, the root
147 name service is a key component of the Internet architecture and play
148 a key role into the overall security of the Internet [RFC2826].
149 Specific security considerations on the DNS protocols are discussed
150 in their respective specifications. The security considerations on
151 the operational side of the root name servers are discussed in
152 [RSSAC-001].
153
154
155
156
157
158
159
160
161
162 Blanchet & Liman Best Current Practice [Page 3]
163 RFC 7720 Root Name Service Requirements December 2015
164
165
166 5. Informative References
167
168 [ARPAZONE] IANA, ".ARPA Zone Management",
169 <http://www.iana.org/domains/arpa>.
170
171 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
172 DOI 10.17487/RFC0768, August 1980,
173 <http://www.rfc-editor.org/info/rfc768>.
174
175 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
176 DOI 10.17487/RFC0791, September 1981,
177 <http://www.rfc-editor.org/info/rfc791>.
178
179 [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
180 RFC 793, DOI 10.17487/RFC0793, September 1981,
181 <http://www.rfc-editor.org/info/rfc793>.
182
183 [RFC1035] Mockapetris, P., "Domain names - implementation and
184 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
185 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
186
187 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
188 Communication Layers", STD 3, RFC 1122,
189 DOI 10.17487/RFC1122, October 1989,
190 <http://www.rfc-editor.org/info/rfc1122>.
191
192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
193 Requirement Levels", BCP 14, RFC 2119,
194 DOI 10.17487/RFC2119, March 1997,
195 <http://www.rfc-editor.org/info/rfc2119>.
196
197 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
198 Specification", RFC 2181, DOI 10.17487/RFC2181, July
199 1997, <http://www.rfc-editor.org/info/rfc2181>.
200
201 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
202 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
203 December 1998, <http://www.rfc-editor.org/info/rfc2460>.
204
205 [RFC2826] Internet Architecture Board, "IAB Technical Comment on
206 the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
207 2000, <http://www.rfc-editor.org/info/rfc2826>.
208
209 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak,
210 "Root Name Server Operational Requirements", BCP 40,
211 RFC 2870, DOI 10.17487/RFC2870, June 2000,
212 <http://www.rfc-editor.org/info/rfc2870>.
213
214
215
216
217 Blanchet & Liman Best Current Practice [Page 4]
218 RFC 7720 Root Name Service Requirements December 2015
219
220
221 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
222 Requirements for the Address and Routing Parameter Area
223 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
224 September 2001, <http://www.rfc-editor.org/info/rfc3172>.
225
226 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
227 Rose, "Protocol Modifications for the DNS Security
228 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
229 <http://www.rfc-editor.org/info/rfc4035>.
230
231 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
232 for DNS (EDNS(0))", STD 75, RFC 6891,
233 DOI 10.17487/RFC6891, April 2013,
234 <http://www.rfc-editor.org/info/rfc6891>.
235
236 [ROOTZONE] "Root Zone", <ftp://rs.internic.net/domain/root.zone>.
237
238 [RSSAC-001] Root Server System Advisory Committee (RSSAC), "Service
239 Expectations of Root Servers", November 2014,
240 <https://www.icann.org/en/system/files/files/
241 rssac-001-root-service-expectations-04dec15-en.pdf>.
242
243 Acknowledgements
244
245 Some text was taken from [RFC2870]. The editors of this document
246 would like to sincerely thank the following individuals for valuable
247 contributions to the text: Andrew Sullivan, Simon Perreault,
248 Jean-Philippe Dionne, Dave Thaler, Russ Housley, Alissa Cooper, Joe
249 Abley, Joao Damas, Daniel Karrenberg, Jacques Latour, Eliot Lear,
250 Bill Manning, David Conrad, Paul Hoffman, Terry Manderson, Jari
251 Arkko, and Mark Andrews.
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272 Blanchet & Liman Best Current Practice [Page 5]
273 RFC 7720 Root Name Service Requirements December 2015
274
275
276 Authors' Addresses
277
278 Marc Blanchet
279 Viagenie
280 246 Aberdeen
281 Quebec, QC G1R 2E1
282 Canada
283
284 Email: Marc.Blanchet@viagenie.ca
285 URI: http://viagenie.ca
286
287
288 Lars-Johan Liman
289 Netnod Internet Exchange
290 Box 30194
291 SE-104 25 Stockholm
292 Sweden
293
294 Email: liman@netnod.se
295 URI: http://www.netnod.se/
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Blanchet & Liman Best Current Practice [Page 6]
328
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.