forked from shuque/ns-revalidation
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-dnsop-ns-revalidation.xml
364 lines (338 loc) · 16.9 KB
/
draft-ietf-dnsop-ns-revalidation.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
352
353
354
355
356
357
358
359
360
361
362
363
364
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http:https://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http:https://www.w3.org/2001/XInclude"
category="std" consensus="true"
docName="draft-ietf-dnsop-ns-revalidation-02"
ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en"
tocInclude="true" tocDepth="4"
symRefs="true" sortRefs="true" version="3">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="DNS Delegation Revalidation">
Delegation Revalidation by DNS Resolvers
</title>
<seriesInfo name="Internet-Draft"
value="draft-ietf-dnsop-ns-revalidation-02"/>
<author fullname="Shumon Huque" initials="S." surname="Huque">
<organization>Salesforce</organization>
<address>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Farsight Security</organization>
<address>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ralph Dolmans" initials="R." surname="Dolmans">
<organization>NLnet Labs</organization>
<address>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="07" month="3" year="2022"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>DNS</keyword>
<keyword>Resolver</keyword>
<keyword>Delegation</keyword>
<keyword>Revalidation</keyword>
<keyword>Authoritative</keyword>
<keyword>Name Server Record</keyword>
<keyword>NS</keyword>
<keyword>Parent</keyword>
<keyword>Child</keyword>
<keyword>Resource Record Set</keyword>
<abstract>
<t>
This document recommends improved DNS <xref target="RFC1034" format="default"/>
<xref target="RFC1035" format="default"/> resolver behavior with
respect to the processing of Name Server (NS) resource record
sets (RRset) during iterative resolution. When following a referral
response from an authoritative server to a child zone, DNS resolvers
should explicitly query the authoritative NS RRset at the apex of
the child zone and cache this in preference to the NS RRset on the
parent side of the zone cut. Resolvers should also periodically
revalidate the child delegation by re-quering the parent zone at the
expiration of the TTL of the parent side NS RRset.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>
RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH BEFORE PUBLISHING: The
source for this draft is maintained in GitHub at:
https://github.com/shuque/ns-revalidation
</t>
<t>
This document recommends improved DNS resolver behavior with
respect to the processing of NS record sets during iterative
resolution. The first recommendation is that resolvers, when
following a referral response from an authoritative server to
a child zone, should explicitly query the authoritative NS RRset
at the apex of the child zone and cache this in preference to
the NS RRset on the parent side of the zone cut. The second
recommendation is to revalidate the delegation by re-quering
the parent zone at the expiration of the TTL of the parent side
NS RRset.
</t>
</section>
<section anchor="motivation" numbered="true" toc="default">
<name>Motivation</name>
<t>
There is wide variability in the behavior of deployed DNS resolvers
today with respect to how they process delegation records. Some of
them prefer the parent NS set, some prefer the child, and for others,
what they preferentially cache depends on the dynamic state of
queries and responses they have processed. This document aims to
bring more commonality and predictability by standardizing the
behavior in a way that comports with the DNS protocol.
</t>
<t>
The delegation NS RRset at the bottom of the parent zone and the
apex NS RRset in the child zone are unsynchronized in the DNS
protocol. <xref target="RFC1034" format="default"/> Section 4.2.2 says
"The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain
so.". But for a variety of
reasons they could not be. Officially, a child zone's apex NS RRset
is authoritative and thus has a higher cache credibility than the
parent's delegation NS RRset, which is non-authoritative glue
(<xref target="RFC2181" format="default"/>, Section 5.4.1. "Ranking
data", and Section 6.1. "Zone authority"). Hence the
NS RRset "below the zone cut" should immediately replace the parent's
delegating NS RRset in cache when an iterative caching DNS resolver
crosses a zone boundary. However, this can only happen if (1) the
resolver receives the authoritative NS RRset in the Authority section
of a response from the child zone, which is not mandatory, or (2) if
the resolver explicitly issues an NS RRset query to the child zone as
part of its iterative resolution algorithm. In the absence of this,
it is possible for an iterative caching resolver to never learn the
authoritative NS RRset for a zone, unless a downstream client of the
resolver explicitly issues such an NS query, which is not something
that normal enduser applications do, and thus cannot be relied upon
to occur with any regularity.
</t>
<t>
Increasingly, there is a trend towards minimizing unnecessary data
in DNS responses. Several popular DNS implementations default to such
a configuration (see "minimal-responses" in BIND and NSD). So,
they may never include the authoritative NS RRset in the Authority
section of their responses.
</t>
<t>
A common reason that zone owners want to ensure that resolvers
place the authoritative NS RRset preferentially in their cache is
that the TTLs may differ between the parent and child side of the
zone cut. Some DNS Top Level Domains (TLDs) only support long fixed
TTLs in their delegation NS sets. In fact, the
<xref target="RFC5731" format="default">Extensible Provisioning
Protocol (EPP)</xref>, that is often used by TLDs to configure
delegation parameters has no provision to set the TTL. This inhibits
a child zone owner's ability to make more rapid changes to their
nameserver configuration using a shorter TTL, if resolvers have no
systematic mechanism to observe and cache the child NS RRset.
</t>
<t>
A child zone's delegation still needs to be periodically
revalidated at the parent to make sure that the parent zone
has not legitimately re-delegated the zone to a different set
of nameservers, or even removed the delegation. Otherwise, resolvers
that refresh the TTL of a child NS RRset on subsequent queries or
due to pre-fetching, may cling to those nameservers long after they
have been re-delegated elsewhere. This leads to the second
recommendation in this document, "Delegation Revalidation" - Resolvers
should record the TTL of the parent's delegating NS RRset, and use it
to trigger a revalidation action.
</t>
</section>
<section anchor="upgrade-ns" numbered="true" toc="default">
<name>Upgrading NS RRset Credibility</name>
<ul spacing="normal">
<li>
When a delegation response is received during iteration, a
validation query should be sent in parallel with the resolution of
the triggering query, to the delegated nameservers for the newly
discovered zone cut. Note that validating resolvers today,
when following a secure referral, already need to dispatch a query
to the delegated nameservers for the DNSKEY RRset, so this validation
query could be sent in parallel with that DNSKEY query.
</li>
<li>
A validation query consists of a query for the child's apex NS
RRset, sent to the newly discovered delegation's nameservers. Normal
iterative logic applies to the processing of responses to validation
queries, including storing the results in cache, trying the next
server on SERVFAIL or timeout, and so on. Positive answers to this
validation query will be cached with an authoritative data ranking.
Successive queries directed to the same zone will be directed to the
nameservers listed in the child's apex, due to the ranking of this
answer. If the validation query fails, the parent NS RRset will remain
the one with the highest ranking and will be used for successive
queries.
</li>
<!-- Ralph: fwiw, I'm ok with completely dropping the next items. Let's
keep this simple. -->
<li>
Some resolvers may choose to delay the response to the triggering
query until both the triggering query and the validation query have
been answered. In practice, we expect many implementations may
answer the triggering query in advance of the validation query for
performance reasons. An additional reason is that there are number
of nameservers in the field that (incorrectly) fail to answer explicit
queries for NS records, and thus the revalidation logic may need to
be applied lazily and opportunistically to deal with them.
</li>
<li>
If the resolver chooses to delay the response, and there are no
nameserver names in common between the child's apex NS RRset and the
parent's delegation NS RRset, then the responses received from
forwarding the triggering query to the parent's delegated nameservers
should be discarded after validation, and this query should be
forwarded again to the child's apex nameservers.
</li>
</ul>
</section>
<section anchor="revalidation" numbered="true" toc="default">
<name>Delegation Revalidation</name>
<t>
The essence of this mechanism is re-validation of all delegation
metadata that directly or indirectly supports an owner name in cache.
This requires a cache to remember the delegated name server names for
each zone cut as received from the parent (delegating) zone's name
servers, and also the TTL of that NS RRset, and the TTL of the
associated DS RRset (if seen).
</t>
<t>
A delegation under re-validation is called a "re-validation point" and
is "still valid" if its parent zone's servers still respond to an
in-zone question with a referral to the re-validation point, and if that
referral overlaps with the previously cached referral by at least one
name server name, and the DS RRset (if seen) overlaps the previously
cached DS RRset (if also seen) by at least one delegated signer.
</t>
<t>
If the response is not a referral or refers to a different zone than
before, then the shape of the delegation hierarchy has changed. If the
response is a referral to the re-validation point but to a wholly novel
NS RRset or a wholly novel DS RRset, then the authority for that zone
has changed. For clarity, this includes transitions between empty and
non-empty DS RRsets.
</t>
<t>
If the shape of the delegation hierarchy or the authority for a zone
has been found to change, then no currently cached data whose owner
names are at or below that re-validation point can be used. Such non-use
can be by directed garbage collection or lazy generational garbage
collection or some other method befitting the architecture of the cache.
What matters is that the cache behave as though this data was removed.
</t>
<t>
Since re-validation can discover changes in the shape of the
delegation hierarchy it is more efficient to re-validate from the top
(root) downward (to the owner name) since an upper level re-validation
may obviate lower level re-validations. What matters is that the
supporting chain of delegations from the root to the owner name be
demonstrably valid; further specifics are implementation details.
</t>
<t>
Re-validation is triggered when delegation meta-data has been cached
for a period at most exceeding the delegating NS or DS (if seen) RRset
TTL. If the corresponding child zone's apex NS RRset TTL is smaller
than the delegating NS RRset TTL, revalidation should happen at that
interval instead. However, resolvers should impose a sensitive minimum
TTL floor they are willing to endure to avoid potential computational
DoS attacks inflicted by zones with very short TTLs.
</t>
<t>
In normal operations this meta-data can be quickly re-validated with
no further work. However, when re-delegation or take-down occurs, a
re-validating cache will discover this within one delegation TTL
period, allowing the rapid expulsion of old data from the cache.
</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
<xref target="upgrade-ns" format="default">Upgrading NS RRset Credibility</xref>
allows resolvers to cache and utilize the authoritative child
apex NS RRset in preference to the non-authoriative parent NS
RRset. However, it is important to implement the steps described in
<xref target="revalidation" format="default">Delegation Revalidation</xref> at
the expiration of the parent's delegating TTL. Otherwise, the
operator of a malicious child zone, originally delegated to, but
subsequently delegated away from, can cause resolvers that refresh
TTLs on subsequent NS set queries, or that pre-fetch NS queries, to
never learn of the redelegated zone. This problem has been
seen in the wild [include reference to Ghost Domains paper here].
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-vixie-dnsext-resimprove-00.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-wijngaards-dnsext-resolver-side-mitigation-01.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Wouter Wijngaards proposed explicitly obtaining authoritative child
NS data in <xref target="I-D.wijngaards-dnsext-resolver-side-mitigation" format="default"/>. This behavior has been implemented in the Unbound DNS resolver via the
"harden-referral-path" option. The combination of child NS fetch and
revalidating the child delegation was originally proposed
in <xref target="I-D.vixie-dnsext-resimprove" format="default"/>, by Vixie, Joffe,
and Neves.
</t>
</section>
</back>
</rfc>