File: rfc3130.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (563 lines) | stat: -rw-r--r-- 22,291 bytes parent folder | download | duplicates (5)
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






Network Working Group                                           E. Lewis
Request for Comments: 3130                                      NAI Labs
Category: Informational                                        June 2001


             Notes from the State-Of-The-Technology: DNSSEC

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This is a memo of a DNSSEC (Domain Name System Security Extensions)
   status meeting.

1.0 Introduction

   A meeting of groups involved in the development of the DNS Security
   Extensions (DNSSEC) was held in conjunction with the 49th IETF.  The
   discussion covered the extent of current efforts, a discussion of
   what questions are being asked of DNSSEC, and what is needed by the
   IETF to progress the definition to the Draft Standard level.

   DNSSEC [RFC 2535] has been under consideration for quite a few years,
   with RFC 2535 being the core of the most recent definition.  DNSSEC
   is part of the charter of two working groups, DNSEXT and DNSOP.
   ISC's BIND v8.2 implemented part of the specification, BIND v9
   represents the first full implementation.  In 1999 and 2000, more
   than a half dozen workshops have been held to test the concepts and
   the earliest versions of implementations.  But to date, DNSSEC is not
   in common use.

   The current collective wisdom is that DNSSEC is 1) important, 2) a
   buzzword, 3) hard, 4) immature.  To capture the true state of the
   technology and identify where work is needed, an informal gathering
   of groups known to be involved in DNSSEC was held in conjunction with
   the 49th IETF.  The attendees represented NLnet Labs, The Foundation
   for Internet Infrastructure, RIPE NCC, ARIN, CAIRN (ISI and NAI
   Labs), NIST, DISA, RSSAC, Network Associates and Verisign
   (COM/NET/ORG TLDs).




Lewis                        Informational                      [Page 1]

RFC 3130              DNSSEC Status Meeting Report             June 2001


   The agenda of the meeting consisted of three items.  Reports from
   each group on their current research goals were followed by a
   discussion of questions being asked of DNSSEC.  Finally, with
   reaching Draft Standard status as a goal, what was needed to make
   this happen was considered.

   This report is not simply a transcript of the meeting, it is a
   summary.  Some of the information presented here was obtained in
   direct contact with participants after the meeting.

1.1 What does the term "DNSSEC" mean?

   One of the comments made during discussions is that DNSSEC does not
   refer to just one monolithic technology.  The term has come to refer
   to "toolbox" of techniques and methodologies, that when used properly
   can improve the integrity of the DNS.  Given this observation, it can
   be seen that some portions of DNSSEC are evolving much more rapidly
   than other portions.  In particular, TSIG [RFC 2845] has certainly
   reached a level "being deployable" for zone transfers.

   The following four components are considered to be part of DNSSEC.
   The concept of digital signature protection of DNS traffic as
   described in RFC 2535 and a few support documents (such as [RFC
   3008]), which is designed to protect the transfer of data on an
   Internet scale.  The concept of protecting queries and responses
   through the less-scalable but more efficient TSIG mechanism [RFC
   2845], which has applicability to zone transfers, DHCP registrations,
   and other resolver to name server traffic.  Secure dynamic updates
   [RFC 3007], by virtue of using TSIG, can be considered to be part of
   DNSSEC.  Finally, the definition of the CERT resource record [RFC
   2538] gives DNS the ability to become a distribution mechanism for
   security data.

   This definition of the components of DNSSEC is in no way definitive.
   To be honest, this is a somewhat artificial grouping.  DNSSEC does
   not encompass all of the security practiced in DNS today, for
   example, the redefinition of when and how data is cached [RFC 2181],
   plays a big role in hardening the DNS system.  The four elements of
   DNSSEC described in the previous paragraph are grouped together
   mostly because they do interrelate, but also they were developed at
   approximately the same time.

2.0 Group Reports

   The first part of the meeting consisted of reports of goals.  From
   this a taxonomy of efforts has been made to see if there are gaps in
   the work.




Lewis                        Informational                      [Page 2]

RFC 3130              DNSSEC Status Meeting Report             June 2001


2.1 NLnet Labs

   Efforts by NLnet Labs are directed towards yielding an understanding
   of the impact of DNSSEC on ccTLDs, specifically .de (Germany), .nl
   (The Netherlands), and .se (Sweden).  Work to date has studied the
   problem of applying digital signatures and NXT records to a zone.
   The conclusion drawn is that there are no real problems regarding
   memory or CPU speed when signing large zones, not even for ".com."
   NLnet Labs has offered to work with Verisign to examine this further.

   NLnet Labs is trying to define and document procedures for TLD
   registries, registrars and registrants to properly handle actions
   like zone-resigning and key-rollover at the root, TLD, and lower
   levels.  The outcome so far is that the DNSOP Roll Over proposal
   seems impractical or possibly even impossible to implement at large
   TLDs.  NLnet Labs will produce a draft on an alternative KEY+SIG
   handling scheme where SIGs are only kept in the zone where the
   corresponding zone-KEY is located.  This scheme reduces the necessary
   actions for resigning zones from 2 levels (current zone and all
   children) to 1 level (current zone), and for key-rollover from 3
   levels (parent, current zone and all children) to 2 levels (parent
   and current zone).

2.2 Verisign

   Verisign's registry operations and corporate components have been
   investigating what DNSSEC means to very large zones, not just from a
   hardware point of view, but from an institutional point of view.
   With the service of providing delegations already commercialized,
   they are attempting to define what it would take to provide a DNSSEC
   service.  An important issue is the parent validation of each
   delegated zone's keys.

2.3 The Foundation for Internet Infrastructure

   The Foundation for Internet Infrastructure, an organization in
   Sweden, is running a project with two parts.  One part is directed at
   the "topology" of the participants in DNSSEC, the other part of the
   project is directed towards general development of tools.

   The study is examining the administrative issues of running DNSSEC.
   One issue is the possible 4-party interaction in the use of DNSSEC.
   The four parties are the registry, the registrar, the registrant, and
   the DNS operator.  Of these four parties, any combination may occur
   within one entity, such as a registrant that operates their own DNS
   as part of their information technology department.





Lewis                        Informational                      [Page 3]

RFC 3130              DNSSEC Status Meeting Report             June 2001


   The other part of the study is looking at what happens in the
   resolver.  Goals include DNSSEC-enabling tools such as ISAKMPd (an
   IPSEC key negotiation software) secure NTP4, and e-mail.  Part of
   this effort is implemented in the sigz.net experiment, information on
   this exists at www.sigz.net.

2.4 RSSAC

   The RSSAC (Root Server System Advisory Committee) has come to the
   conclusion that TSIG is worthwhile and should be deployed.  There is
   no schedule for deployment, however.

   As for the rest of DNSSEC, there is a need to better understand the
   impact of the new features before being introduced into production.
   Currently issues regarding potential testbeds are being documented.
   Two fundamental assumptions are that a DNSSEC testbed involving the
   root servers is desirable and that such a testbed would allow for
   long term testing.  The latter assumption is based upon the need to
   understand how repeated zone key validations can occur at multiple
   independent levels of the DNS hierarchy.

2.5 CAIRN

   CAIRN (Collaborative Advanced Interagency Research Network) is a
   DARPA-sponsored network for collaborative research.  A funded
   activity that involves DNSSEC is FMESHD, shorthand for Fault-Tolerant
   Mesh of Trust in DNSSEC.  The effort of this activity is to determine
   a means of building a resolver's chain of trust when some of the DNS
   tree is unavailable or unsecured.  An early deliverable of this is an
   extension of secure shell to retrieve keys from DNSSEC.  As part of
   this activity, the use of DNSSEC in a non-major provider zone is
   being implemented and studied.

2.6 NIST

   NIST is collecting performance information regarding DNSSEC.  One of
   the fears in adopting DNSSEC is the workload it adds to existing DNS
   machine workload.  The hopes of this effort is to quantify the fear,
   to see if it is real or imagined.

   If time permits, there may be an effort to implement a zone integrity
   checking program (implemented in Java) that will look for missteps in
   the use of DNSSEC.  Base code exists, but needs work (beyond the
   current baseline).







Lewis                        Informational                      [Page 4]

RFC 3130              DNSSEC Status Meeting Report             June 2001


2.7 DISA

   The U.S. Defense Information Systems Agency is providing funds to
   have DNSSEC implemented in BIND.  Of particular interest is making
   sure that the DNSSEC specifications are correct, that BIND adheres to
   the specifications, and that BIND is available on the operating
   systems in use by the US Department of Defense.  DISA expects that
   every line of code developed through this effort be made publicly
   available as part of stock BIND releases.

2.8 RIPE NCC

   The RIPE NCC is looking at the impact of DNSSEC on IP-registries.
   The RIPE NCC is planning to coordinate and assist in the deployment
   of DNSSEC.  Because the RIPE NCC is the Regional Internet Registry
   for Europe the focus will be on the deployment of DNSSEC on the
   reverse map tree (in-addr.arpa for IPv4).

2.9 ARIN

   ARIN is investigating DNSSEC for use in signing its delegated zones
   under in-addr.arpa.  It participated in a dnssec workshop following
   NANOG 20 held in Washington, DC in October, 2000.  It also
   participated in an ipv6-dnssec workshop that followed IETF 49 in San
   Diego, California.  Additionally, ARIN has stood up a server
   dedicated to testing various dns experimentation, including dnssec
   and carrying out limited testing.

2.10 Network Associates

   NAI is pressing to get the tislabs.com zone running in accordance
   with DNSSEC.  This is an example of a non-Internet service provider
   (neither an IP transit, IP address allocation, nor a domain name
   managing entity) making use of DNSSEC within the normal operations of
   the Information Technology department.

2.11 ip6.int. domain

   The name servers authoritative for the ip6.int. domain are mostly
   upgraded to be able to support CERT records and TSIG.  Once this is
   fully accomplished and proposals are approved, TSIG and CERT records
   will be used.  Further DNSSEC work is unknown.

2.12 Topology Based Domain Search

   Topology Based Domain Search (TBDS), is a DARPA funded activity
   investigating how DNS may continue to run in disconnected parts of
   the Internet.  Topics of interest (either covered by this project, or



Lewis                        Informational                      [Page 5]

RFC 3130              DNSSEC Status Meeting Report             June 2001


   associated with the project) are the use of split keys, self-signed
   zone (keys), and multiple signing algorithms.  A goal is the
   establishment of signed infrastructure zones, facilitating the
   creation of a distributed CA for activities like IPSEC and FreeSwan.

3.0 Taxonomy of efforts and What is missing

   The efforts being undertaken appear to cover a broad range of work
   areas, from large domain registries to domain name consumers.  Work
   has been progressing in the production of zones (signing, key
   management), and is starting in the use (resolver) of DNSSEC secured
   data.

   From the discussion, there were no apparent areas lacking attention.
   Additional input in some areas is needed however, particularly in
   making use (applications and IT department) of DNSSEC.

4.0 Questions facing DNSSEC

   By the 49th IETF meeting, the most pressing question on DNSSEC is "is
   it deployable?"  From just the emphasis placed on this question, the
   meeting generated a list of questions and made sure that either the
   answer was known, or work was being done to address the question.

4.1 Is it deployable?  When?

   The usual answer to this has been "not now."  When is always off into
   the future - "about a year."  To get to a deployable point, a series
   of workshops have been held since the spring of 1999.

   At this point, it is becoming clearer that longer term workshops are
   needed.  In going through the motions of any workshop, the number of
   issues raised that impact the protocol's specification is
   diminishing, as well as implementation issues.  As such, one or two
   day workshops have been helping less and less in reaching deployment.

   What is needed is to run longer term test configurations, possibly
   workshops that are help in conjunction with other events and that
   assume continuity.  This will allow a better assessment of the issues
   that involve the passage of time - expirations on key validations,
   etc.

   As was noted in section 1.1, and touched on in section 2, one
   component of DNSSEC, TSIG, is more advanced that the others.  Use of
   TSIG to protect zone transfers is already matured to the "really good
   idea to do stage" even if other elements of DNSSEC are not.  Using
   TSIG to protect traffic between local resolver and their "default"
   recursive name server still needs more work, however.



Lewis                        Informational                      [Page 6]

RFC 3130              DNSSEC Status Meeting Report             June 2001


4.2 Does DNSSEC work?  Is it the right approach?

   Currently there is a lot of effort into making the specification as
   proposed work.  There is some effort in assessing the specification
   at this point, particularly the value of the NXT records and possible
   replacements of it.

   There seems little question on value of the KEY and SIG records.
   There is some research still needed on KEY validation across zone
   boundaries.  Such work is at least scheduled.

4.3 How will client software make use of DNSSEC?

   There are a number of efforts to take existing applications and have
   them make direct use of DNSSEC to carry out their functions.  One
   such example is secure shell.

   When or whether DNSSEC will be understood in the (using POSIX-like
   terms) operating systems "gethostbyname" and similar routines has not
   been addressed.

4.4 What are the remaining issues?

   There are still a few protocol issues.  The NXT resource record is
   designed to provide a means to authentically deny data exists.  The
   problem is that the solution proposed may be worse than the problem,
   in the eyes of some.  There is an alternative proposal, the NO
   resource record, under consideration in the DNSEXT working group.  At
   the present time, the DNSEXT working is considering the following
   question: Is there a need to authentically deny existence of data, if
   so, which is better, NXT (being incumbent) or NO?

   Another less defined issue is the mechanism for parent validation of
   children signatures.  Although the protocol elements of this are
   becoming settled, the operational considerations are not, as
   evidenced by work mentioned in section 2.  DNSSEC interactions have
   also been referenced in discussions over a standard registry-
   registrar protocol.

5.0 Progressing to Draft Standard

   The IETF goal for DNSSEC is to progress the documents through the
   standards track [RFC 2026].  Currently, RFC 2535 is the second
   iteration at the Proposed standard level.  There is a need to cycle
   through Proposed once more.  Following this, the next goal is Draft.






Lewis                        Informational                      [Page 7]

RFC 3130              DNSSEC Status Meeting Report             June 2001


   To pass to the Draft Standard level, two main requirements must be
   met.  There must be two or more interoperable implementations.  There
   must also be sufficient successful operational experience.

5.1 Revision of RFC 2535 via DNSEXT

   DNSEXT will soon begin a rewrite of the RFC 2535 specification (and
   its support documents), rolling in updates and clarifications based
   upon implementation and testing experience.

5.2 Operations document(s) via DNSOP

   DNSOP will continue to be the forum for operations documents based
   upon DNSSEC activity.  There is a need for the community to provide
   more documents to this group.

5.3 Interoperability

   Demonstrating interoperability of DNSSEC, meaning the interaction of
   two different implementations when performing DNSSEC work, poses an
   issue because, to date, only BIND is seriously being fitted with
   DNSSEC.  There are other partial implementations of DNSSEC
   functionality, so the potential for partial interoperability
   demonstrations may exist.

   During the meeting, it was realized that given goals stated, a second
   DNSSEC implementation is needed in 18 months.  Various folks in the
   room mentioned that they would begin see what could be done about
   this.

6.0 Acknowledgements

   The following people attended the meeting and/or provided text for
   this report (in no particular order): Mark Kosters (Network
   Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek Gieben
   (NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC), Bill
   Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson and
   Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery and
   Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica),
   Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis and
   Olafur Gudmundsson (NAI Labs).

7.0 IANA Considerations

   This document does not involve assigned numbers in any way.






Lewis                        Informational                      [Page 8]

RFC 3130              DNSSEC Status Meeting Report             June 2001


8.0 Security Considerations

   This document, although a discussion of security enhancements to the
   DNS, does not itself impact security.  Where security issues arise,
   they will be discussed in the Security Considerations of the
   appropriate document.

9.0 References

   The text of any RFC may be retrieved by a web browser by requesting
   the URL: ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is
   the number of the RFC.

   [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", July 1997.

   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
              March 1999.

   [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
              the Domain Name System", March 1999.

   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", May 2000.

   [RFC 3007] Wellington, B., "Secure Domain Name System Dynamic
              Update", November 2000.

   [RFC 3008] Wellington, B., "Domain Name System Security Signing
              Authority", November 2000.

10.0 Editor's Address

   Edward Lewis
   3060 Washington Rd (Rte 97)
   Glenwood, MD 21738

   Phone: +1(443)259-2352
   EMail: lewis@tislabs.com








Lewis                        Informational                      [Page 9]

RFC 3130              DNSSEC Status Meeting Report             June 2001


11.0 Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Lewis                        Informational                     [Page 10]