-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-momoka-dnsop-3901bis.xml
351 lines (348 loc) · 23 KB
/
draft-momoka-dnsop-3901bis.xml
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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
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
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.1.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" consensus="true" docName="draft-momoka-dnsop-3901bis-latest" category="bcp" submissionType="IETF" tocInclude="true" obsoletes="3901" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front>
<title abbrev="3901bis">DNS IPv6 Transport Operational Guidelines</title>
<seriesInfo name="Internet-Draft" status="standard" value="draft-momoka-dnsop-3901bis-latest"/>
<author fullname="山本 桃歌" asciiFullname="Momoka Yamamoto" initials="Momoka" surname="Y">
<organization>WIDE Project</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Tobias Fiebig" initials="T." surname="Fiebig">
<organization abbrev="MPI-INF">Max-Planck-Institut fuer Informatik</organization>
<address>
<postal>
<street>Campus E14</street>
<city>Saarbruecken</city>
<code>66123</code>
<country>Germany</country>
</postal>
<phone>+49 681 9325 3527</phone>
<email>[email protected]</email>
</address>
</author>
<area>Ops</area>
<workgroup>dnsop</workgroup>
<keyword>DNS</keyword>
<keyword>IPv6</keyword>
<abstract>
<t indent="0" pn="section-abstract-1">
This memo provides guidelines and documents Best Current Practice for operating authoritative and recursive DNS servers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks.
This document expands on RFC 3901 by recommending that authoritative and recursive resolvers support both IPv4 and IPv6.</t>
<t indent="0" pn="section-abstract-2">This document obsoletes RFC3901. (if approved)</t>
</abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/momoka0122y/draft-dnsop-3901bis"/>.</t>
</note>
</front>
<middle>
<section anchor="introduction">
<name>Introduction</name>
<t>
Despite IPv6 being first discussed in the mid-1990s <xref target="RFC1883" format="default"/>, consistent deployment throughout the whole Internet has not yet been accomplished <xref target="RFC9386" format="default"/>.
Hence, today, the Internet is a mixture of IPv4, dual-stack (networks connected via both IP versions), and IPv6 networks.
</t>
<t>
This creates a complex landscape where authoritative name servers might be accessible only via specific network protocols <xref target="V6DNSRDY-23" format="default"/>.
At the same time, DNS resolvers may only be able to access the Internet via either IPv4 or IPv6. This poses a challenge for such resolvers because they may encounter names for which queries must be directed to authoritative name servers with which they do not share an IP version during the name resolution process.
</t>
<t>
<xref target="RFC3901" format="default"/> was initially written at a time when IPv6 deployment was not widespread, focusing primarily on maintaining namespace continuity within the IPv4 landscape.
Now, nearly two decades later, with IPv6 not only widely deployed but also becoming the de facto standard in many areas,
this document seeks to expand the scope of RFC3901 by recommending IPv6 compatibility for authoritative and recursive DNS resolvers.
</t>
<t>In this document, we discuss:</t>
<ul spacing="normal">
<li>
<t>IP version related namespace fragmentation and best-practices for avoiding it.</t>
</li>
<li>
<t>Guidelines for configuring authoritative name servers for zones.</t>
</li>
<li>
<t>Guidelines for operating recursive DNS resolvers.</t>
</li>
</ul>
<t>
While transitional technologies and dual-stack setups may mitigate some of the issues of DNS resolution in a mixed protocol-version Internet, making DNS data accessible over both IPv4 and IPv6 is the most robust and flexible approach, as it allows resolvers to reach the information they need without requiring intermediary translation or forwarding services which may introduce additional failure cases.
</t>
<section anchor="requirements-language">
<name>Requirements Language</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</section>
</section>
<section anchor="terminology">
<name>Terminology</name>
<t>
This document uses DNS terminology as described in <xref target="RFC9499" format="default"/>.
Furthermore, the following terms are used with a defined meaning:
</t>
<dl newline="true" spacing="normal">
<dt>
IPv4 name server:
</dt>
<dd>
A name server providing DNS services reachable via IPv4. It does not imply anything about what DNS data is served, but requires DNS queries to be received and answered over IPv4.
</dd>
<dt>
IPv6 name server:
</dt>
<dd>
A name server providing DNS services reachable via IPv6. It does not imply anything about what DNS data is served, but requires DNS queries to be received and answered over IPv6.
</dd>
<dt>
Dual-stack name server:
</dt>
<dd>
A name server that is both an "IPv4 name server" and also an "IPv6 name server".
</dd>
</dl>
</section>
<section anchor="name-space-fragmentation">
<name>Name Space Fragmentation</name>
<t>
A resolver that tries to look up a name starts out at the root, and follows referrals until it is referred to a name server that is authoritative for the name.
If somewhere down the chain of referrals it is referred to a name server that is, based on the referral, only accessible over a transport which the resolver cannot use, the resolver is unable to continue DNS resolution.
</t>
<t>
If this occurs, the DNS has, effectively, fragmented based on the resolver's and authoritative's mismatching IP version support.
</t>
<t>
In a mixed IP Internet, fragmentation can occur for different reasons. One reason is that DNS zones are consistently configured to support only either IPv4 or IPv6. Another reason is due to misconfigurations that make a zone unresolvable by either IPv4 or IPv6-only resolvers.
The latter cases are often hard to identify, as the impact of misconfigurations for only one IP version (IPv4 or IPv6) may be hidden in a dual-stack setting.
In the worst case, a specific name may only be resolvable via dual-stack enabled resolvers.
</t>
<section anchor="misconfigurations-causing-ip-version-related-name-space-fragmentation">
<name>Misconfigurations Causing IP Version Related Name Space Fragmentation</name>
<t>
Even when an administrator thinks they have enabled support for a specific IP version on their authoritative name server, various misconfigurations may break the DNS delegation chain of a zone for that protocol and prevent any of its records from resolving for clients only supporting that IP version.
These misconfigurations can be kept hidden if most clients can successfully fall back to the other IP version.
</t>
<t>
The following name related misconfigurations can cause broken delegation for one IP version:
</t>
<dl newline="true" spacing="normal">
<dt>
No A/AAAA records for NS names:
</dt>
<dd>
If all of the NS records for a zone in their parent zone have either only A records or only AAAA records, then resolution via the other IP version is not possible.
</dd>
<dt>
Missing GLUE:
</dt>
<dd>
If the name from an NS record for a zone is in-domain, i.e., the name is within the zone or below, a parent zone must contain both IPv4 and IPv6 GLUE records, i.e., a parent must serve the corresponding A and AAAA records as ADDITIONAL data when returning the NS record(s) as the referral response.
</dd>
<dt>
No A/AAAA record for in-domain NS:
</dt>
<dd>
If an NS record of a child zone, either provided by the parent or from the child zone's apex, points to a name in the NS RDATA that is in-domain but the name does not contain corresponding A or AAAA record(s) in the child zone,
name resolution via the concerned IP version will fail even if the parent provides GLUE, when the recursive server revalidates the delegation path <xref target="I-D.ietf-dnsop-ns-revalidation" format="default"/>.
</dd>
<dt>
Zone of sibling domain NSes not resolving:
</dt>
<dd>
If the name from an NS record for a zone is sibling domain, the corresponding zone must be resolvable via the IP version in question as well. It is insufficient if the name pointed to by the NS record has an associated A or AAAA record correspondingly.
</dd>
<dt>
Parent zone not resolvable via one IP version:
</dt>
<dd>
For a zone to be resolvable via an IP version the parent zones up to the root zone must be resolvable via that IP version as well. Any zone not resolvable via the concerned IP version breaks the delegation chain for all its children.
</dd>
</dl>
<t>
The above misconfigurations are not mutually exclusive.
</t>
<t>
Furthermore, any of the misconfigurations above may not only materialize via a missing Resource Record (RR) but also via an RR providing the IP address of a nameserver that is not configured to answer queries via that IP version <xref target="V6DNSRDY-23" format="default"/>.
</t>
</section>
<section anchor="reasons-for-intentional-ip-version-related-name-space-fragmentation">
<name>Reasons for Intentional IP Version Related Name Space Fragmentation</name>
<t>
Intentional IP related name space fragmentation occurs if an operator consciously decides not to deploy IPv4 or IPv6 for a part of the resolution chain.
Most commonly, this is realized by intentionally not listing A/AAAA records for NS names.
At the time of writing, the share of zones not resolvable via IPv4 is negligible, while a little less than 40% of zones are not resolvable via IPv6 <xref target="V6DNSRDY-23" format="default"/>.
However, as IPv4 exhaustion progresses, IPv6 adoption will have to increase.
</t>
</section>
</section>
<section anchor="policy-based-avoidance-of-name-space-fragmentation">
<name>Policy Based Avoidance of Name Space Fragmentation</name>
<t>
With the final exhaustion of IPv4 pools in RIRs, e.g., <xref target="RIPEV4" format="default"/>, and the progressing deployment of IPv6, there no longer is a "preferred" IP version.
Yet, while we now observe the first zones becoming exclusively IPv6 resolvable, we also still see a major portion of zones solely relying on IPv4 <xref target="V6DNSRDY-23" format="default"/>.
Hence, at the moment, dual stack connectivity is instrumental to be able to resolve zones and avoid name space fragmentation.
</t>
<t>
Having zones served only by name servers reachable via one IP version would fragment the DNS.
Hence, we need to find a way to avoid this fragmentation.
</t>
<t>
The recommended approach to maintain name space continuity is to use administrative policies, as described in this section.
</t>
<section anchor="guidelines-for-authoritative-dns-configuration">
<name>Guidelines for Authoritative DNS Server Configuration</name>
<t>
It is usually recommended that DNS zones contain at least two name servers, which are geographically diverse and operate under different routing policies <xref target="IANANS" format="default"/>.
To reduce the chance of DNS name space fragmentation, it is <bcp14>RECOMMENDED</bcp14> that at least two name servers for a zone are dual stack name servers.
Specifically, this means that the following minimal requirements <bcp14>SHOULD</bcp14> be implemented for a zone:
</t>
<dl newline="true" spacing="normal">
<dt>
IPv4 adoption:
</dt>
<dd>
Every authoritative DNS zone <bcp14>SHOULD</bcp14> be served by at least one IPv4-reachable authoritative name server to maintain name space continuity.
The delegation configuration (Resolution of the parent, resolution of sibling domain names, GLUE) <bcp14>MUST NOT</bcp14> rely on IPv6 connectivity being available.
As we acknowledge IPv4 scarcity, operators <bcp14>MAY</bcp14> opt not to provide DNS services via IPv4, if they can ensure that all clients expected to resolve this zone do support DNS resolution via IPv6.
</dd>
<dt>
IPv6 adoption:
</dt>
<dd>
Every authoritative DNS zone <bcp14>SHOULD</bcp14> be served by at least one IPv6-reachable authoritative name server to maintain name space continuity.
The delegation configuration (Resolution of the parent, resolution of sibling domain names, GLUE) <bcp14>MUST NOT</bcp14> rely on IPv4 connectivity being available.
</dd>
<dt>
Consistency:
</dt>
<dd>
Both IPv4 and IPv6 transports should serve identical DNS data to ensure a consistent resolution experience across different network types.
</dd>
<dt>
Avoiding IP Fragmentation:
</dt>
<dd>
IP fragmentation has been reported to be fragile <xref target="RFC8900" format="default"/>.
Furthermore, IPv6 transition technologies can introduce unexpected MTU breaks, e.g., when NAT64 is used <xref target="RFC7269" format="default"/>.
Therefore, IP fragmentation <bcp14>SHOULD</bcp14> be avoided by following guidance on maximum DNS payload sizes <xref target="RFC9715" format="default"/> and providing TCP fall-back options <xref target="RFC7766" format="default"/>.
</dd>
</dl>
<t>
Note: zone validation processes <bcp14>SHOULD</bcp14> ensure that there is at least one IPv4 address record and one IPv6 address record available for the name servers of any child delegation within the zone.
</t>
</section>
<section anchor="guidelines-for-dns-resolvers">
<name>Guidelines for DNS Resolvers</name>
<t>
Every recursive DNS resolver <bcp14>SHOULD</bcp14> be dual stack.
</t>
<t>
While the zones that IPv6-only recursive DNS resolvers can resolve are growing but do not yet cover all zones, they cannot fully resolve all zones.
Hence, a recursive resolver <bcp14>MAY</bcp14> be IPv6-only, if it uses a transition mechanism that allows it to also query IPv4 authoritative NS or uses a configuration where it forward queries failing IPv6-only DNS resolution to a set of dual-stack recursive name servers that perform the actual recursive queries.
</t>
<t>
Similarly, a recursive resolver <bcp14>MAY</bcp14> be IPv4-only, if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a set of dual-stack recursive name servers that perform the actual recursive queries.
</t>
</section>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>
The guidelines described in this memo introduce no new security considerations into the DNS protocol or associated operational scenarios.
</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>
This document requests IANA to update its technical requirements for authoritative name servers to require both IPv4 and IPv6 addresses for each authoritative server <xref target="IANANS" format="default"/>.
</t>
</section>
<section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name>
<t>
Valuable input for this draft was provided by: Bob Harold, Andreas Schulze, Tommy Jensen, Nick Buraglio, Jen Linkova
</t>
<t>
Thank you for reading this draft.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1883.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3901.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7766.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-ns-revalidation.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9715.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7269.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9386.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-only-resolver.xml"/>
<reference anchor="V6DNSRDY-23" target="https://link.springer.com/chapter/10.1007/978-3-031-28486-1_22">
<front>
<title>How Ready is DNS for an IPv6-Only World?</title>
<author initials="F" surname="Streibelt" fullname="Florian">
<organization/>
</author>
<author initials="P" surname="Sattler" fullname="Patrick">
<organization/>
</author>
<author initials="F" surname="Lichtblau" fullname="Franziska">
<organization/>
</author>
<author initials="C" surname="Hernandez-Gañán" fullname="Carlos">
<organization/>
</author>
<author initials="O" surname="Gasser" fullname="Oliver">
<organization/>
</author>
<author initials="T" surname="Fiebig" fullname="Tobias">
<organization/>
</author>
<date month="March" year="2023"/>
</front>
</reference>
<reference anchor="RIPEV4" target="https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/the-ripe-ncc-has-run-out-of-ipv4-addresses">
<front>
<title>The RIPE NCC has run out of IPv4 Addresses</title>
<author>
<organization>RIPE NCC</organization>
</author>
<date month="November" year="2019"/>
</front>
</reference>
<reference anchor="IANANS" target="https://www.iana.org/help/nameserver-requirements">
<front>
<title>Technical requirements for authoritative name servers</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references>
</back>
</rfc>