forked from ogud/3-DNS-Protocol
-
Notifications
You must be signed in to change notification settings - Fork 0
/
DNS3-RR-Protocol.txt
672 lines (414 loc) · 23.4 KB
/
DNS3-RR-Protocol.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
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
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
regext J. Latour
Internet-Draft CIRA
Intended status: Standards Track O. Gudmundsson
Expires: July 8, 2017 Cloudflare, Inc.
P. Wouters
Red Hat
M. Pounsett
Rightside Group, Ltd.
January 4, 2017
Third Party DNS operator to Registrars/Registries Protocol
draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt
Abstract
There are several problems that arise in the standard
Registrant/Registrar/Registry model when the operator of a zone is
neither the Registrant nor the Registrar for the delegation.
Historically the issues have been minor, and limited to difficulty
guiding the Registrant through the initial changes to the NS records
for the delegation. As this is usually a one time activity when the
operator first takes charge of the zone it has not been treated as a
serious issue.
When the domain on the other hand uses DNSSEC it necessary to make
regular (sometimes annual) changes to the delegation, in order to
track KSK rollover, by updating the delegation's DS record(s). Under
the current model this is prone to delays and errors. Even when the
Registrant has outsourced the operation of DNS to a third party the
registrant still has to be in the loop to update the DS record.
There is a need for a simple protocol that allows a third party DNS
operator to update DS and NS records in a trusted manner for a
delegation without involving the registrant for each operation. This
same protocol can be used by Registrants.
The protocol described in this draft is REST based, and when used
through an authenticated channel can be used to establish the DNSSEC
Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC
trust is established this channel can be used to trigger maintenance
of delegation records such as DS, NS, and glue records. The protocol
is kept as simple as possible.
Latour, et al. Expires July 8, 2017 [Page 1]
Internet-Draft 3-DNS-RRR January 2017
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 July 8, 2017.
Copyright Notice
Copyright (c) 2017 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notional Conventions . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . 4
3. What is the goal? . . . . . . . . . . . . . . . . . . . . . . 4
3.1. How does a child signal its parent it wants to establish
a secure chain of trust? . . . . . . . . . . . . . . . . 4
3.2. How does a parental agent detects maintenance activities 5
3.3. What checks are needed by parent? . . . . . . . . . . . . 5
4. Third Party DNS operator to Registrars/Registries RESTful API 6
4.1. API Authentication . . . . . . . . . . . . . . . . . . . 6
4.2. API Authorization . . . . . . . . . . . . . . . . . . . . 6
4.3. API Base URL Locator . . . . . . . . . . . . . . . . . . 7
4.4. CDS resource . . . . . . . . . . . . . . . . . . . . . . 7
Latour, et al. Expires July 8, 2017 [Page 2]
Internet-Draft 3-DNS-RRR January 2017
4.4.1. Initial Trust Establishment (Enable DNSSEC
validation) . . . . . . . . . . . . . . . . . . . . . 7
4.4.2. Removing a DS (turn off DNSSEC) . . . . . . . . . . . 7
4.4.3. DS Maintenance . . . . . . . . . . . . . . . . . . . 8
4.5. Tokens resource . . . . . . . . . . . . . . . . . . . . . 8
4.5.1. Setup Initial Trust Establishment with Challenge . . 9
4.6. Customized Error Messages . . . . . . . . . . . . . . . . 9
4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Internationalization Considerations . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Document History . . . . . . . . . . . . . . . . . . 11
A.1. Regex version 02 . . . . . . . . . . . . . . . . . . . . 11
A.2. Regex version 01 . . . . . . . . . . . . . . . . . . . . 11
A.3. Regex version 00 . . . . . . . . . . . . . . . . . . . . 11
A.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 11
A.5. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 11
A.6. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 11
A.7. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Why is this needed? DNS registration systems today are designed
around making registrations easy and fast. After the domain has been
registered there are really three options on who maintains the DNS
zone that is loaded on the "primary" DNS servers for the domain this
can be the Registrant, Registrar, or a third party DNS Operator.
Unfortunately the ease to make changes differs for each one of these
options. The Registrant needs to use the interface that the
registrar provides to update NS and DS records. The Registrar on the
other hand can make changes directly into the registration system.
The third party DNS Operator on the hand needs to go through the
Registrant to update any delegation information.
Current system does not work well, there are many types of failures
have been reported and they have been at all levels in the
registration model.
The failures result either inability to use DNSSEC or in validation
failures that cause the domain to become invalid and all users that
are behind validating resolvers will not be able to to access the
domain.
Latour, et al. Expires July 8, 2017 [Page 3]
Internet-Draft 3-DNS-RRR January 2017
The goal of this document is to create an automated interface that
will reduce the friction in maintaining DNSSEC delegations.
2. Notional Conventions
2.1. Definitions
For the purposes of this draft, a third-party DNS Operator is any DNS
Operator responsible for a zone where the operator is neither the
Registrant nor the Registrar of record for the delegation.
Uses of the word 'Registrar' in this document may also be applied to
resellers: an entity that sells delegations through a registrar with
whom the entity has a reseller agreement.
2.2. RFC2119 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. What is the goal?
The primary goal is to have a protocol to establish a secure chain of
trust that involves parties that are not in the traditional
Registrant/Registrar/Registry (RRR) model.
A DNS operator cannot easily and scalably identify the registrar (or
registration agent, or reseller) for a domain name it is operating.
Thus the DNS operator has to fallback to relying on the registrant
(as customer) of the services to establish a secure chain of trust.
In the general case there should be a way to find the right
Registrar/Registry entity to talk to, but it does not exist. Whois[]
is the natural protocol to carry such information but that protocol
but is unreliable and hard to parse. Its proposed successor RDAP
[RFC7480] has yet be deployed on most TLD's.
The preferred communication mechanism is to use is to use a REST
[RFC6690] call to start processing of the requested delegation
information.
3.1. How does a child signal its parent it wants to establish a secure
chain of trust?
The child needs first to sign the domain, then the child can "upload"
the DS record to its parent. The "normal" way to upload a DS record
is for the registrant to go through registration interface and submit
Latour, et al. Expires July 8, 2017 [Page 4]
Internet-Draft 3-DNS-RRR January 2017
a DS record (or DNSKEY or both), but a lack of registrar/reseller
DNSSEC support in sufficient frequency is a significant operational
problem to the detriment of DNSSEC adoption.
The DNS Operator may not have access to the interface thus the
registrant needs to relay the information. For large operations this
does not scale, as evident in lack of Trust Anchors for signed
deployments that are operated by third parties.
The child can signal its desire to have DNSSEC validation enabled by
publishing one of the special DNS records CDS and/or CDNSKEY[RFC7344]
and its proposed extension [I-D.ietf-dnsop-maintain-ds].
Once the "parent" "sees" these records it SHOULD start acceptance
processing. This document covers how to make the CDS records visible
to the right parental agent.
This document and [I-D.ogud-dnsop-maintain-ds] argue that the
publication of CDS/CDNSKEY record is sufficient for the parent to
start the acceptance processing. The main point is to provide
authentication thus if the child is in "good" state then the DS
upload should be simple to accept and publish. If there is any
problem the parent does not add the DS.
In the event this protocols and its associated authentication
mechanism does not address the Registrant's security requirements to
create a secure delegation then the Registrant always has recourse by
submitting its DS record via its registration interface.
3.2. How does a parental agent detects maintenance activities
One the secure chain of trust is established, the parent should
implement a system to automate domain polling for CDS maintenance
record changes. The maintenance activities includes adding or
removing DS record(s) [I-D.ogud-dnsop-maintain-ds].
Each parental agent is responsible to develop and implement and
communicate their DNSSEC maintenance policies.
3.3. What checks are needed by parent?
The parent upon receiving a signal or detecting through polling that
the child desires to have its DS record published. The basic tests
include,
Latour, et al. Expires July 8, 2017 [Page 5]
Internet-Draft 3-DNS-RRR January 2017
1. Is the zone is properly signed as per the parent DNSSEC policy
2. The zone has a CDS signed by a KSK referenced in the current CDS,
referring to a at least one key in the current DNSKEY RRset
3. All the name-servers for the zone agree on the CDS RRset contents
NOTE:(do we need a new section in the DPS for the CDS management
policy [RFC6841]?)
Parents can perform additional tests, defined delays, queries over
TCP, ensure zone delegation best practice as per
[I-D.wallstrom-dnsop-dns-delegation-requirements] and even ask the
DNS Operator to prove they can add data to the zone, or provide a
code that is tied to the affected zone. The protocol is partially-
synchronous, i.e. the server can elect to hold connection open until
the operation has concluded or it can return that it received the
request. It is up to the child to monitor the parent for completion
of the operation and issue possible follow-up calls.
The parent can have a policy to accept a CDS signed by a ZSK or a
CSK. The parent should not make any changes to DS RRset if the child
name-servers do not agree on content.
4. Third Party DNS operator to Registrars/Registries RESTful API
The specification of this API is minimalist, but a realistic one.
This API may be denied access to change the DS records for domains
that are Registry Locked (HTTP Status code 401). Registry Lock is a
mechanisms provided by certain registries or registrars that prevents
domain hijacking by ensuring no attributes of the domain are
changeable and no transfer or deletion transactions can be processed
against the domain name may prevents certain attributes in the
registry to be changed (locks).
4.1. API Authentication
The API does not impose any unique server authentication
requirements. The server authentication provided by TLS fully
addresses the needs. The API MUST be provided over TLS-protected
transport (e.g., HTTPS) or VPN.
4.2. API Authorization
Authorization to access the API is outside the scope of this
document. The publication of CDS record(s) in the child zone file
are indications of intention to perform DS records activities (add/
delete) for the domain in the parent zone. This means the proceeding
of the API action is not determined by who issued the API request but
Latour, et al. Expires July 8, 2017 [Page 6]
Internet-Draft 3-DNS-RRR January 2017
by the intention in the CDS publication. Therefore, authorization is
out of scope. Registries and registrars who plan to provide this
service can, however, implement their own policy to protect access to
the API such as IP white listing, API key, etc.
4.3. API Base URL Locator
The base URL for registries or registrars who want to provide this
service to DNS Operators can be made auto-discoverable as an RDAP
extension.
4.4. CDS resource
Path: /domains/{domain}/cds {domain}: is the domain name to be
operated on
4.4.1. Initial Trust Establishment (Enable DNSSEC validation)
4.4.1.1. Request
Syntax: POST /domains/{domain}/cds
A DS record based on the CDS record in the child zone file will be
inserted into the registry and the parent zone file upon the
successful completion of such request. If there are multiple CDS
records in the CDS RRset, multiple DS records will be added.
4.4.1.2. Response
o HTTP Status code 201 indicates a success.
o HTTP Status code 400 indicates a failure due to validation.
o HTTP Status code 401 indicates an unauthorized resource access.
o HTTP Status code 403 indicates a failure due to an invalid
challenge token.
o HTTP Status code 404 indicates the domain does not exist.
o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.
4.4.2. Removing a DS (turn off DNSSEC)
Latour, et al. Expires July 8, 2017 [Page 7]
Internet-Draft 3-DNS-RRR January 2017
4.4.2.1. Request
Syntax: DELETE /domains/{domain}/cds
A null CDS or CDNSKEY record mean the entire DS RRset must be
removed.
4.4.2.2. Response
o HTTP Status code 200 indicates a success.
o HTTP Status code 400 indicates a failure due to validation.
o HTTP Status code 401 indicates an unauthorized resource access.
o HTTP Status code 404 indicates the domain does not exist.
o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.
4.4.3. DS Maintenance
4.4.3.1. Request
Syntax: PUT /domains/{domain}/cds
Maintenance activities are performed based on the CDS available in
the child zone. DS records may be added, removed. But the entire DS
RRset must not be deleted.
4.4.3.2. Response
o HTTP Status code 200 indicates a success.
o HTTP Status code 400 indicates a failure due to validation.
o HTTP Status code 401 indicates an unauthorized resource access.
o HTTP Status code 404 indicates the domain does not exist.
o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.
4.5. Tokens resource
Path: /domains/{domain}/tokens {domain}: is the domain name to be
operated on
Latour, et al. Expires July 8, 2017 [Page 8]
Internet-Draft 3-DNS-RRR January 2017
4.5.1. Setup Initial Trust Establishment with Challenge
4.5.1.1. Request
Syntax: POST /domains/{domain}/tokens
The parent's DNSSEC policy may require proof the DNS Operator is in
control of the domain.
The token API call returns a random token to be included as a
_delegate TXT record prior establishing the DNSSEC initial trust.
This is an additional trust control mechanism to establish the
initial chain of trust. Note that the _delegate TXT record is
publicly available and not a secret token.
4.5.1.2. Response
o HTTP Status code 200 indicates a success. Token included in the
body of the response, as a valid TXT record
o HTTP Status code 404 indicates the domain does not exist.
o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.
4.6. Customized Error Messages
Service providers can provide a customized error message in the
response body in addition to the HTTP status code defined in the
previous section.
This can include an Identifying number/string that can be used to
track the requests.
#Using the definitions This section at the moment contains comments
from early implementers
4.7. How to react to 403 on POST cds
The basic reaction to a 403 on POST /domains/{domain}/cds is to issue
POST /domains/{domain}/tokens command to fetch the challenge to
insert into the zone.
5. Security considerations
When domains are provisioned with good Internet hygiene and zone
delegation follows best practice such as
[I-D.wallstrom-dnsop-dns-delegation-requirements], the registrar or
Latour, et al. Expires July 8, 2017 [Page 9]
Internet-Draft 3-DNS-RRR January 2017
registry can then trust the DNS information it queried over two
different ASN and over TCP to establish the initial chain of trust.
In addition, the registrar or registry can required the DNS Operator
to prove they control the zone by adding a challenge token a to the
zone.
This protocol should increase the adoption of DNSSEC and get more
zones to become validated thus overall the security gain outweighs
the possible drawbacks.
Registrant and DNS Operator always have the option to establish the
chain of trust in band via the standard Registrant/Registrar/Registry
model.
6. IANA Actions
URI ??? TBD
7. Internationalization Considerations
This protocol is designed for machine to machine communications
8. References
8.1. Normative References
[I-D.ietf-dnsop-maintain-ds]
Gudmundsson, O. and P. Wouters, "Managing DS records from
parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03
(work in progress), June 2016.
[I-D.wallstrom-dnsop-dns-delegation-requirements]
Wallstrom, P. and J. Schlyter, "DNS Delegation
Requirements", draft-wallstrom-dnsop-dns-delegation-
requirements-00 (work in progress), February 2016.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<http://www.rfc-editor.org/info/rfc7344>.
8.2. Informative References
[I-D.ogud-dnsop-maintain-ds]
Gu[eth]mundsson, O. and P. Wouters, "Managing DS records
from parent via CDS/CDNSKEY", draft-ogud-dnsop-maintain-
ds-00 (work in progress), October 2015.
Latour, et al. Expires July 8, 2017 [Page 10]
Internet-Draft 3-DNS-RRR January 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<http://www.rfc-editor.org/info/rfc6841>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", RFC 7480,
DOI 10.17487/RFC7480, March 2015,
<http://www.rfc-editor.org/info/rfc7480>.
Appendix A. Document History
A.1. Regex version 02
Clarified based on comments and questions from early implementors
(JL) Text edits and clarifications.
A.2. Regex version 01
Rewrote Abstract and Into (MP) Introduced code 401 when changes are
not allowed Text edits and clarifications.
A.3. Regex version 00
Working group document same as 03, just track changed to standard
A.4. Version 03
Clarified based on comments and questions from early implementors
A.5. Version 02
Reflected comments on mailing lists
A.6. Version 01
This version adds a full REST definition this is based on suggestions
from Jakob Schlyter.
Latour, et al. Expires July 8, 2017 [Page 11]
Internet-Draft 3-DNS-RRR January 2017
A.7. Version 00
First rough version
Authors' Addresses
Jacques Latour
CIRA
Email: jacques.latour@cira.ca
Olafur Gudmundsson
Cloudflare, Inc.
Email: olafur+ietf@cloudflare.com
Paul Wouters
Red Hat
Email: paul@nohats.ca
Matthew Pounsett
Rightside Group, Ltd.
Email: matt@conundrum.com
Latour, et al. Expires July 8, 2017 [Page 12]