forked from songlinjian/ietf-draft-ixfr-ps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-song-dnsop-ixfr-fallback-01.txt
280 lines (184 loc) · 10.9 KB
/
draft-song-dnsop-ixfr-fallback-01.txt
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
Internet Engineering Task Force L. Song
Internet-Draft Beijing Internet Institute
Intended status: Informational May 18, 2016
Expires: November 19, 2016
An IXFR Fallback to AXFR Case
draft-song-dnsop-ixfr-fallback-01
Abstract
This memo introduces an IXFR issue observed during a multiple signers
experiment conducted in Yeti DNS project. In the experiment IXFR
client is designed to pull the zone from three IXFR servers who used
their own key to sign the zone and produce different RRSIG records
intentionally. The configuration of multiple signers causes the
failure of IXFR in client side.
REMOVE BEFORE PUBLICATION: The source of the document is currently
placed at GitHub [xml-file]. Comments and pull request are welcome.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Song Expires November 19, 2016 [Page 1]
Internet-Draft An IXFR Fallback to AXFR Case May 2016
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The IXFR issues observed in MZSK experiment . . . . . . . . . 3
3. Possible solution . . . . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
In DNS specifications authoritative name server uses full zone
transfer (AXFR) [RFC5936], incremental Zone Transfer (IXFR)[RFC1995],
and NOTIFY [RFC1996] to achieve coherency of the zone contents. IXFR
is an optimization for large DNS zone transfer, which allows server
only transfer the changed portion(s) to client.
AXFR fallback usually happens at server side by simply returning IXFR
client the entire new zone in condition that IXFR server cannot
fulfill the given delta-update request. It is because an IXFR client
may have multiple IXFR servers for a single zone. It is not a
protocol defect but does stimulate people to find optimization avoiding
full zone transfer [I-D.kerr-ixfr-only] and trying to make a new IXFR
protocol [I-D.ietf-dnsext-rfc1995bis-ixfr].
[RFC5936] suggests that if its upstream servers have different ideas
of the zone contents with the same (zone, serial) pair, the client
can stop adding records that already exist or deleting records that
do not exist. However, if an IXFR incoherence error is spotted by
that client, it is not clear whether the client should stop IXFR
process and ask for AXFR as a fallback. To the author's knowledge,
there is such recommendation so far for AXFR fallback initiated by
client in formal document.
This memo introduces an IXFR problem observed during a DNS root
experiment in Yeti project[Yeti-DNS-Project] which involves multiple
root zone distribution masters (DM). It is designed that three DMs do
have different "ideas" on how their keys are managed and produce
different RRSIG records. In this scenario, it is observed that
different DNS implementations have different behaviors due to the
ambiguity in understanding of IXFR and fallback to AXFR.
Song Expires November 19, 2016 [Page 2]
Internet-Draft An IXFR Fallback to AXFR Case May 2016
REMOVE BEFORE Publication: The motivation of this memo is to ask for
discussion in the community whether this specific fallback or non-
fallback is viewed as a problem. Is it worthwhile developing IXFR
protocol further towards rfc1996bis? Or this memo can serve
providing some information and guidance to operators who do run
authoritative servers in similar situation as it is done in Yeti
experiment.
2. The IXFR issues observed in MZSK experiment
As a background for this memo, the introduction of Yeti testbed and
experiments can be found in [I-D.song-yeti-testbed-experience], and
section 3.1 and 4.2 are relevant. Conceptually, Yeti DNS intends to
break one signer/DM role into three which buy some properties in
loosely cooperative environment, such as resilience to single point
of failure, more independent choice for slave server, and certain
degree of transparency and management coordination for important zone
(root zone in Yeti's case).
One experiment in Yeti is designed to test multiple signers with
Multiple ZSKs (MZSK). It is required that all public ZSKs used by
DMs are included in the zone as a key set; and resolver can validate
the message by picking one key from the key set. From DNSSEC point
of view, it is technically workable. However, different signers do
produce different RRSIG RR which introduces zone inconsistency from
beginning in this case. In current setting of Yeti experiment, it is
possible that one client does AXFR/IXFR from one server and later
asks for IXFR from another server.
It is observed that when the IXFR client switched from one IXFR
server to another, it received an IXFR response deleting RRSIG record
that does not exist. One IXFR client running NSD 4.1.7 rejected IXFR
response, made a log indicating a bad data and then asked for full
zone transfer. Luckily, Yeti root zone is relatively small (691K),
so the fallback to AXFR does not cause significant performance
degeneration. But if operator does host big zone with MZSK model, it
will cause problem based on current IXFR.
Another observation is that another IXFR client running Knot 2.1.0 in
similar situation just accepts the IXFR response, ignores the
differences and generates a merged zone with two RRSIG RRs. It not
only produces larger response, but also causes DNSSEC failure when a
new zone is generated given that old RRSIG is the signature of old
zone RRs.
Song Expires November 19, 2016 [Page 3]
Internet-Draft An IXFR Fallback to AXFR Case May 2016
3. Possible solution
Generally, there are three considerations to this issue.
o Asking for development of RRSIG-aware IXFR format in which the
RRSIG is treated as a special and RRSIG RR should always be
transferred in full (like it does in AXFR). In the case of MZSK
experiment, the old RRSIG record(s) is replaced by the new RRSIG
record(s) and no specific deleted RRSIG is sent. Compared to the
first case in NSD 4.1.7, it is helpful to reduce the cost for full
zone transfer if the zone is fairly large.
o Adopting the behavior of NSD 4.1.7 as an improvement for IXFR
protocol in which an IXFR client should fall back to AXFR
automatically in the event of an IXFR incoherence error. To avoid
unnecessary full zone transfer, it is desirable that the IXFR
client is more "sticky" to the server who transfers the zone to
the client last time.
o Without modification of IXFR protocol, asking each IXFR client
(root slave in Yeti case) to be tied to a specific IXFR
server (Yeti DM). This would decrease redundancy and resiliency
but would allow normal IXFR, and may make debugging easier. But
the MZSK operation introduces regional DM which is not desirable
for Yeti case.
4. Acknowledgments
Specially thanks to Stephane Bortzmeyer who first spotted the IXFR
issues from his NSD and Knot authoritative servers. Acknowledgment
to Paul Vixie and Shane Kerr who contributed a lot to this technical
finding and possible solutions in this memo. Thanks to Antonio Prado
who helped to make the language more readable.
5. References
[I-D.ietf-dnsext-rfc1995bis-ixfr]
Hoenes, A., Sury, O., and S. Kerr, "DNS Incremental Zone
Transfer Protocol (IXFR)", draft-ietf-dnsext-rfc1995bis-
ixfr-01 (work in progress), April 2012.
[I-D.kerr-ixfr-only]
Sury, O. and S. Kerr, "IXFR-ONLY to Prevent IXFR Fallback
to AXFR", draft-kerr-ixfr-only-01 (work in progress),
February 2010.
Song Expires November 19, 2016 [Page 4]
Internet-Draft An IXFR Fallback to AXFR Case May 2016
[I-D.song-yeti-testbed-experience]
Song, D., Kerr, S., and D. Liu, "Experiences from Root
Testbed in the Yeti DNS Project", draft-song-yeti-testbed-
experience-01 (work in progress), December 2015.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<http://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>.
[xml-file]
"XML source file of IXFR Case draft", 2016,
<https://github.com/songlinjian/ietf-draft-ixfr-ps>.
[Yeti-DNS-Project]
"Website of Yeti DNS Project", <http://www.yeti-dns.org>.
Author's Address
Linjian Song
Beijing Internet Institute
2508 Room, 25th Floor, Tower A, Time Fortune
Beijing 100028
P. R. China
Email: songlinjian@gmail.com
URI: http://www.biigroup.com/
Song Expires November 19, 2016 [Page 5]