1 Internet Engineering Task Force (IETF) D. Wessels
2 Request for Comments: 8145 Verisign
3 Category: Standards Track W. Kumari
4 ISSN: 2070-1721 Google
5 P. Hoffman
6 ICANN
7 April 2017
8
9
10 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
11
12 Abstract
13
14 The DNS Security Extensions (DNSSEC) were developed to provide origin
15 authentication and integrity protection for DNS data by using digital
16 signatures. These digital signatures can be verified by building a
17 chain of trust starting from a trust anchor and proceeding down to a
18 particular node in the DNS. This document specifies two different
19 ways for validating resolvers to signal to a server which keys are
20 referenced in their chain of trust. The data from such signaling
21 allow zone administrators to monitor the progress of rollovers in a
22 DNSSEC-signed zone.
23
24 Status of This Memo
25
26 This is an Internet Standards Track document.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 7841.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc8145.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Wessels, et al. Standards Track [Page 1]
53 RFC 8145 DNSSEC Key Tag Signaling April 2017
54
55
56 Copyright Notice
57
58 Copyright (c) 2017 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction ....................................................3
74 1.1. Design Evolution ...........................................4
75 2. Requirements Terminology ........................................5
76 3. Terminology .....................................................5
77 4. Using the edns-key-tag Option ...................................5
78 4.1. Option Format ..............................................5
79 4.2. Use by Queriers ............................................6
80 4.2.1. Stub Resolvers ......................................7
81 4.2.1.1. Validating Stub Resolvers ..................7
82 4.2.1.2. Non-validating Stub Resolvers ..............7
83 4.2.2. Recursive Resolvers .................................7
84 4.2.2.1. Validating Recursive Resolvers .............7
85 4.2.2.2. Non-validating Recursive Resolvers .........8
86 4.3. Use by Responders ..........................................8
87 5. Using the Key Tag Query .........................................8
88 5.1. Query Format ...............................................8
89 5.2. Use by Queriers ............................................9
90 5.3. Use by Responders ..........................................9
91 5.3.1. Interaction with Aggressive Negative Caching ........9
92 6. IANA Considerations ............................................10
93 7. Security Considerations ........................................10
94 8. Privacy Considerations .........................................11
95 9. References .....................................................11
96 9.1. Normative References ......................................11
97 9.2. Informative References ....................................12
98 Acknowledgments ...................................................13
99 Authors' Addresses ................................................13
100
101
102
103
104
105
106
107 Wessels, et al. Standards Track [Page 2]
108 RFC 8145 DNSSEC Key Tag Signaling April 2017
109
110
111 1. Introduction
112
113 The DNS Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035]
114 were developed to provide origin authentication and integrity
115 protection for DNS data by using digital signatures. DNSSEC uses
116 Key Tags to efficiently match signatures to the keys from which they
117 are generated. The Key Tag is a 16-bit value computed from the RDATA
118 portion of a DNSKEY resource record (RR) using a formula not unlike a
119 ones-complement checksum. RRSIG RRs contain a Key Tag field whose
120 value is equal to the Key Tag of the DNSKEY RR that validates the
121 signature.
122
123 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field
124 whose value is equal to the Key Tag of the DNSKEY RR to which it
125 refers.
126
127 This document specifies how validating resolvers can tell a server,
128 in a DNS query, which DNSSEC key(s) they would use to validate the
129 server's responses. It describes two independent methods for
130 conveying Key Tag information between clients and servers:
131
132 1. placing an EDNS option in the OPT RR [RFC6891] that contains the
133 Key Tags (described in Section 4)
134
135 2. periodically sending special "Key Tag queries" to a server
136 authoritative for the zone (described in Section 5)
137
138 Each of these new signaling mechanisms is OPTIONAL to implement and
139 use. These mechanisms serve to measure the acceptance and use of new
140 DNSSEC trust anchors and key signing keys (KSKs). This signaling
141 data can be used by zone administrators as a gauge to measure the
142 successful deployment of new keys. This is of particular interest
143 for the DNS root zone in the event of key and/or algorithm rollovers
144 that rely on [RFC5011] to automatically update a validating DNS
145 resolver's trust anchor.
146
147 This document does not introduce new processes for rolling keys or
148 updating trust anchors. Rather, it specifies a means by which a DNS
149 query can signal the set of keys that a client uses for DNSSEC
150 validation.
151
152
153
154
155
156
157
158
159
160
161
162 Wessels, et al. Standards Track [Page 3]
163 RFC 8145 DNSSEC Key Tag Signaling April 2017
164
165
166 1.1. Design Evolution
167
168 Initially, when the work on this document started, it proposed
169 including Key Tag values in a new EDNS(0) option code. It was
170 modeled after [RFC6975], which provides DNSSEC algorithm signaling.
171
172 The authors received feedback from participants in the DNSOP Working
173 Group that it might be better to convey Key Tags in the QNAME of a
174 separate DNS query, rather than as an EDNS(0) option. Mostly, this
175 is because forwarding (e.g., from stub to recursive to authoritative)
176 could be problematic. Reasons include the following:
177
178 1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not
179 be forwarded by default, as per [RFC6891].
180
181 2. Middleboxes might block entire queries containing unknown EDNS(0)
182 option codes.
183
184 3. A recursive resolver might need to remember Key Tag values (i.e.,
185 keep state) received from its stub clients and then forward them
186 at a later opportunity.
187
188 One advantage of the EDNS(0) option code is that it is possible to
189 see that a stub client has a different Key Tag list than its
190 forwarder. In the QNAME-based approach, this is not possible because
191 queries originated by a stub and a forwarder are indistinguishable.
192 The authors feel that this advantage is not sufficient to justify the
193 EDNS(0) approach.
194
195 One downside to the QNAME approach is that it uses a separate query,
196 whereas with EDNS(0) the Key Tag values are "piggybacked" onto an
197 existing DNSKEY query. For this reason, this document recommends
198 only sending QNAME-based Key Tag queries for trust anchors, although
199 EDNS-based Key Tags can be sent with any DNSKEY query.
200
201 Another downside to the QNAME-based approach is that since the
202 trust anchor zone might not contain labels matching the QNAME, these
203 queries could be subject to aggressive negative caching features now
204 in development by the Working Group. This could affect the amount of
205 signaling sent by some clients compared to others.
206
207 A probably minor downside to the QNAME-based approach is that it
208 cannot be used with extremely long query names if the addition of the
209 prefix would cause the name to be longer than 255 octets.
210
211
212
213
214
215
216
217 Wessels, et al. Standards Track [Page 4]
218 RFC 8145 DNSSEC Key Tag Signaling April 2017
219
220
221 2. Requirements Terminology
222
223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
225 document are to be interpreted as described in [RFC2119].
226
227 3. Terminology
228
229 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
230 A validating security-aware resolver uses this public key or hash
231 as a starting point for building the authentication chain to a
232 signed DNS response. In general, a validating resolver will have
233 to obtain the initial values of its trust anchors via some secure
234 or trusted means outside the DNS protocol. Presence of a
235 trust anchor also implies that the resolver should expect the zone
236 to which the trust anchor points to be signed. (This paragraph is
237 quoted from Section 2 of [RFC4033].)
238
239 Key Tag: A 16-bit integer that identifies and enables efficient
240 selection of DNSSEC public keys. A Key Tag value can be computed
241 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and
242 DS records can be used to help select the corresponding DNSKEY RR
243 efficiently when more than one candidate DNSKEY RR is available.
244 For most algorithms, the Key Tag is a simple 16-bit modular sum of
245 the DNSKEY RDATA. See [RFC4034], Appendix B.
246
247 4. Using the edns-key-tag Option
248
249 4.1. Option Format
250
251 The edns-key-tag option is encoded as follows:
252
253 0 8 16
254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
255 | OPTION-CODE |
256 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
257 | OPTION-LENGTH |
258 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
259 | KEY-TAG |
260 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
261 | ... /
262 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
263
264
265
266
267
268
269
270
271
272 Wessels, et al. Standards Track [Page 5]
273 RFC 8145 DNSSEC Key Tag Signaling April 2017
274
275
276 where:
277
278 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag (14).
279
280 OPTION-LENGTH: The value 2 x number of key-tag values present.
281
282 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B).
283
284 4.2. Use by Queriers
285
286 A validating resolver sets the edns-key-tag option in the OPT RR when
287 sending a DNSKEY query. The validating resolver SHOULD also set the
288 DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that
289 it wishes to receive DNSSEC RRs in the response.
290
291 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY
292 queries.
293
294 The KEY-TAG value(s) included in the edns-key-tag option represents
295 the Key Tag of the trust anchor or DNSKEY RR that will be used to
296 validate the expected response. When the client sends a DNSKEY
297 query, the edns-key-tag option represents the Key Tag(s) of the
298 KSK(s) of the zone for which the server is authoritative. A
299 validating resolver learns the Key Tag(s) of the KSK(s) from the
300 zone's DS record(s) (found in the parent) or from a trust anchor.
301
302 A DNS client SHOULD include the edns-key-tag option when issuing a
303 DNSKEY query for a zone corresponding to a trust anchor.
304
305 A DNS client MAY include the edns-key-tag option when issuing a
306 DNSKEY query for a non-trust anchor zone (i.e., Key Tags learned via
307 DS records). Since some DNSSEC validators implement bottom-up
308 validation, a non-trust anchor Key Tags zone might not be known at
309 the time of the query. Such a validator can include the edns-key-tag
310 option based on previously cached data.
311
312 A DNS client MUST NOT include Key Tag(s) for keys that are not
313 learned via either a trust anchor or DS records.
314
315 Since the edns-key-tag option is only set in the query, if a client
316 sees these options in the response, no action needs to be taken and
317 the client MUST ignore the option values.
318
319
320
321
322
323
324
325
326
327 Wessels, et al. Standards Track [Page 6]
328 RFC 8145 DNSSEC Key Tag Signaling April 2017
329
330
331 4.2.1. Stub Resolvers
332
333 Typically, stub resolvers rely on an upstream recursive resolver (or
334 cache) to provide a response. Optimal setting of the edns-key-tag
335 option depends on whether the stub resolver elects to perform its own
336 validation.
337
338 4.2.1.1. Validating Stub Resolvers
339
340 A validating stub resolver sets the DNSSEC OK bit [RFC4035] to
341 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG
342 RRs) in the response. Such validating resolvers SHOULD include the
343 edns-key-tag option in the OPT RR when sending a DNSKEY query.
344
345 4.2.1.2. Non-validating Stub Resolvers
346
347 The edns-key-tag option MUST NOT be included by non-validating stub
348 resolvers.
349
350 4.2.2. Recursive Resolvers
351
352 4.2.2.1. Validating Recursive Resolvers
353
354 A validating recursive resolver is, by definition, configured with at
355 least one trust anchor. Thus, a recursive resolver SHOULD include
356 the edns-key-tag option in its DNSKEY queries as described above.
357
358 In addition, the clients of a validating recursive resolver might be
359 configured to do their own validation, with their own
360 trust anchor(s). When a validating recursive resolver receives a
361 query that includes the edns-key-tag option with a Key Tag list that
362 differs from its own, it SHOULD forward both the client's Key Tag
363 list and its own list. When doing so, the recursive resolver SHOULD
364 transmit the two Key Tag lists using separate instances of the
365 edns-key-tag option code in the OPT RR. For example, if the
366 recursive resolver's Key Tag list is (19036, 12345) and the
367 stub/client's list is (19036, 34567), the recursive resolver
368 would include the edns-key-tag option twice: once with values
369 (19036, 12345) and once with values (19036, 34567).
370
371 A validating recursive resolver MAY combine stub/client Key Tag
372 values from multiple incoming queries into a single outgoing query.
373 It is RECOMMENDED that implementations place reasonable limits on the
374 number of Key Tags to include in the outgoing edns-key-tag option.
375
376
377
378
379
380
381
382 Wessels, et al. Standards Track [Page 7]
383 RFC 8145 DNSSEC Key Tag Signaling April 2017
384
385
386 If the client included the DNSSEC OK and Checking Disabled (CD) bits
387 but did not include the edns-key-tag option in the query, the
388 validating recursive resolver MAY include the option with its own
389 Key Tag values in full.
390
391 Validating recursive resolvers MUST NOT set the edns-key-tag option
392 in the final response to the stub client.
393
394 4.2.2.2. Non-validating Recursive Resolvers
395
396 Recursive resolvers that do not validate responses SHOULD copy the
397 edns-key-tag option seen in received queries, as they represent the
398 wishes of the validating downstream resolver that issued the original
399 query.
400
401 4.3. Use by Responders
402
403 An authoritative name server receiving queries with the edns-key-tag
404 option MAY log or otherwise collect the Key Tag values to provide
405 information to the zone operator.
406
407 A responder MUST NOT include the edns-key-tag option in any DNS
408 response.
409
410 5. Using the Key Tag Query
411
412 5.1. Query Format
413
414 A Key Tag query consists of a standard DNS query of type NULL and of
415 class IN [RFC1035].
416
417 The first component of the query name is the string "_ta-" followed
418 by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
419 values. The zone name corresponding to the trust anchor is appended
420 to this first component.
421
422 For example, a validating DNS resolver that has a single root zone
423 trust anchor with Key Tag 17476 (decimal) would originate a query of
424 the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
425
426 Hexadecimal values MUST be zero-padded to four hexadecimal digits.
427 For example, if the Key Tag is 999 (decimal), it is represented in
428 hexadecimal as 03e7.
429
430
431
432
433
434
435
436
437 Wessels, et al. Standards Track [Page 8]
438 RFC 8145 DNSSEC Key Tag Signaling April 2017
439
440
441 When representing multiple Key Tag values, they MUST be sorted in
442 order from smallest to largest. For example, a validating DNS
443 resolver that has three trust anchors for the example.com zone with
444 Key Tags 1589, 43547, 31406 (decimal) would originate a query of the
445 form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com.
446
447 5.2. Use by Queriers
448
449 A validating DNS resolver (stub or recursive) SHOULD originate a
450 Key Tag query whenever it also originates a DNSKEY query for a
451 trust anchor zone. In other words, the need to issue a DNSKEY query
452 is also the trigger to issue a Key Tag query.
453
454 The value(s) included in the Key Tag query represents the Key Tag(s)
455 of the trust anchor that will be used to validate the expected DNSKEY
456 response.
457
458 A validating DNS resolver SHOULD NOT originate Key Tag queries when
459 also originating DNSKEY queries for non-trust anchor zones.
460
461 A non-validating DNS resolver MUST NOT originate Key Tag queries.
462
463 DNS resolvers with caches SHOULD cache and reuse the response to a
464 Key Tag query just as it would any other response.
465
466 5.3. Use by Responders
467
468 An authoritative name server receiving Key Tag queries MAY log or
469 otherwise collect the Key Tag values to provide information to the
470 zone operator.
471
472 An authoritative name server MUST generate an appropriate response to
473 the Key Tag query. A server does not need to have built-in logic
474 that determines the response to Key Tag queries: the response code is
475 determined by whether the data is in the zone file or covered by
476 wildcards. The zone operator might want to add specific Key Tag
477 records to its zone, perhaps with specific TTLs, to affect the
478 frequency of Key Tag queries from clients.
479
480 5.3.1. Interaction with Aggressive Negative Caching
481
482 Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also
483 affect the quality of Key Tag signaling. When the response code for
484 a Key Tag query is NXDOMAIN, DNS resolvers that implement aggressive
485 negative caching will send fewer Key Tag queries than resolvers that
486 do not implement it.
487
488
489
490
491
492 Wessels, et al. Standards Track [Page 9]
493 RFC 8145 DNSSEC Key Tag Signaling April 2017
494
495
496 For this reason, zone operators might choose to create records
497 corresponding to expected Key Tag queries. During a rollover from
498 Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include the
499 following records:
500
501 _ta-1111 IN NULL \# 0
502 _ta-2222 IN NULL \# 0
503 _ta-1111-2222 IN NULL \# 0
504
505 Recall that when multiple Key Tags are present, the originating
506 client MUST sort them from smallest to largest in the query name.
507
508 6. IANA Considerations
509
510 IANA has assigned an EDNS0 option code for the edns-key-tag option in
511 the "DNS EDNS0 Option Codes (OPT)" registry as follows:
512
513 +-------+--------------+----------+-----------+
514 | Value | Name | Status | Reference |
515 +-------+--------------+----------+-----------+
516 | 14 | edns-key-tag | Optional | RFC 8145 |
517 +-------+--------------+----------+-----------+
518
519 7. Security Considerations
520
521 This document specifies two ways for a client to signal its
522 trust anchor knowledge to a cache or server. The goal of these
523 optional mechanisms is to signal new trust anchor uptake in clients
524 to allow zone administrators to know when it is possible to complete
525 a key rollover in a DNSSEC-signed zone.
526
527 There is a possibility that an eavesdropper or server could infer the
528 validator in use by a client by the Key Tag list seen. This may
529 allow an attacker to find validators using old, possibly broken,
530 keys. It could also be used to identify the validator or to narrow
531 down the possible validator implementations in use by a client; the
532 validator used by the client could have a known vulnerability that
533 could be exploited by the attacker.
534
535 Consumers of data collected from the mechanisms described in this
536 document are advised that provided Key Tag values might be "made up"
537 by some DNS clients with malicious, or at least mischievous,
538 intentions. For example, an attacker with sufficient resources might
539 try to generate large numbers of queries including only old Key Tag
540 values, with the intention of delaying the completion of a key
541 rollover.
542
543
544
545
546
547 Wessels, et al. Standards Track [Page 10]
548 RFC 8145 DNSSEC Key Tag Signaling April 2017
549
550
551 DNSSEC does not require keys in a zone to have unique Key Tags.
552 During a rollover, there is a small possibility that an old key and a
553 new key will have identical Key Tag values. Zone operators relying
554 on the edns-key-tag mechanism SHOULD take care to ensure that new
555 keys have unique Key Tag values.
556
557 8. Privacy Considerations
558
559 This proposal provides additional, optional "signaling" to DNS
560 queries in the form of Key Tag values. While Key Tag values
561 themselves are not considered private information, it may be possible
562 for an eavesdropper to use Key Tag values as a fingerprinting
563 technique to identify particular validating DNS clients. This may be
564 especially true if the validator is configured with trust anchors for
565 zones in addition to the root zone.
566
567 A validating resolver need not transmit the Key Tags in every
568 applicable query. Due to privacy concerns, such a resolver MAY
569 choose to transmit the Key Tags for a subset of queries (e.g., every
570 25th time) or by random chance with a certain probability (e.g., 5%).
571
572 Implementations of this specification MAY be administratively
573 configured to only transmit the Key Tags for certain zones. For
574 example, the software's configuration file may specify a list of
575 zones for which the use of the mechanisms described here is allowed
576 or denied. Since the primary motivation for this specification is to
577 provide operational measurement data for root zone key rollovers, it
578 is RECOMMENDED that implementations at least include the edns-key-tag
579 option for root zone DNSKEY queries.
580
581 9. References
582
583 9.1. Normative References
584
585 [RFC1035] Mockapetris, P., "Domain names - implementation and
586 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
587 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
588
589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
590 Requirement Levels", BCP 14, RFC 2119,
591 DOI 10.17487/RFC2119, March 1997,
592 <http://www.rfc-editor.org/info/rfc2119>.
593
594 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
595 Rose, "DNS Security Introduction and Requirements",
596 RFC 4033, DOI 10.17487/RFC4033, March 2005,
597 <http://www.rfc-editor.org/info/rfc4033>.
598
599
600
601
602 Wessels, et al. Standards Track [Page 11]
603 RFC 8145 DNSSEC Key Tag Signaling April 2017
604
605
606 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
607 Rose, "Resource Records for the DNS Security Extensions",
608 RFC 4034, DOI 10.17487/RFC4034, March 2005,
609 <http://www.rfc-editor.org/info/rfc4034>.
610
611 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
612 Rose, "Protocol Modifications for the DNS Security
613 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
614 <http://www.rfc-editor.org/info/rfc4035>.
615
616 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
617 for DNS (EDNS(0))", STD 75, RFC 6891,
618 DOI 10.17487/RFC6891, April 2013,
619 <http://www.rfc-editor.org/info/rfc6891>.
620
621 9.2. Informative References
622
623 [NSEC-NSEC3-Usage]
624 Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
625 DNSSEC-validated Cache", Work in Progress,
626 draft-ietf-dnsop-nsec-aggressiveuse-09, March 2017.
627
628 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
629 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
630 September 2007, <http://www.rfc-editor.org/info/rfc5011>.
631
632 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
633 Algorithm Understanding in DNS Security Extensions
634 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
635 <http://www.rfc-editor.org/info/rfc6975>.
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657 Wessels, et al. Standards Track [Page 12]
658 RFC 8145 DNSSEC Key Tag Signaling April 2017
659
660
661 Acknowledgments
662
663 This document was inspired by and borrows heavily from [RFC6975] by
664 Scott Rose and Steve Crocker. The authors would like to thank Mark
665 Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim
666 Wicinski, Suzanne Woolf, and other members of the DNSOP Working Group
667 for their input.
668
669 Authors' Addresses
670
671 Duane Wessels
672 Verisign
673 12061 Bluemont Way
674 Reston, VA 20190
675 United States of America
676
677 Phone: +1 703 948-3200
678 Email: dwessels@verisign.com
679 URI: http://verisigninc.com
680
681
682 Warren Kumari
683 Google
684 1600 Amphitheatre Parkway
685 Mountain View, CA 94043
686 United States of America
687
688 Email: warren@kumari.net
689
690
691 Paul Hoffman
692 ICANN
693
694 Email: paul.hoffman@icann.org
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712 Wessels, et al. Standards Track [Page 13]
713
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.