idnits 2.17.00 (12 Aug 2021) /tmp/idnits11218/draft-ietf-dnsop-edns-key-tag-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2016) is 2054 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 225, but not defined == Missing Reference: 'TBA' is mentioned on line 425, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Wessels 3 Internet-Draft Verisign 4 Intended status: Standards Track W. Kumari 5 Expires: April 8, 2017 Google 6 P. Hoffman 7 ICANN 8 October 5, 2016 10 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) 11 draft-ietf-dnsop-edns-key-tag-03 13 Abstract 15 The DNS Security Extensions (DNSSEC) were developed to provide origin 16 authentication and integrity protection for DNS data by using digital 17 signatures. These digital signatures can be verified by building a 18 chain-of-trust starting from a trust anchor and proceeding down to a 19 particular node in the DNS. This document specifies two different 20 ways for validating resolvers to signal to a server which keys are 21 referenced in their chain-of-trust. The data from such signaling 22 allow zone administrators to monitor the progress of rollovers in a 23 DNSSEC-signed zone. 25 This document describes two independent methods for validating 26 resolvers to publish their referenced keys: an EDNS option and a 27 different DNS query. The reason there are two methods instead of one 28 is some people see significant problems with each method. Having two 29 methods is clearly worse than having just one, but it is probably 30 better for the Internet than having no way to gain the information 31 from the resolvers. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 8, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3 69 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5 72 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5 74 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6 75 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6 76 4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6 77 4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 7 78 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7 79 4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7 80 4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7 81 5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8 82 5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8 83 5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8 84 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 9 85 5.3.1. Interaction With Aggressive Negative Caching . . . . 9 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 10.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 96 1. Introduction 98 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 99 [RFC4035] were developed to provide origin authentication and 100 integrity protection for DNS data by using digital signatures. 101 DNSSEC uses Key Tags to efficiently match signatures to the keys from 102 which they are generated. The Key Tag is a 16-bit value computed 103 from the RDATA portion of a DNSKEY RR using a formula not unlike a 104 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 105 value is equal to the Key Tag of the DNSKEY RR that validates the 106 signature. 108 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 109 whose value is equal to the Key Tag of the DNSKEY RR to which it 110 refers. 112 This draft sets out to specify a way for validating resolvers to tell 113 a server in a DNS query which DNSSEC key(s) they would use to 114 validate responses from that zone. This is done in two ways: using 115 an EDNS option for use in the OPT meta-RR [RFC6891] that contains the 116 key tags (described in Section 4), and by periodically sending 117 special "key tag queries" to a server authoritative for the zone 118 (described in Section 5). 120 Each of these new signaling mechanisms is OPTIONAL to implement and 121 use. These mechanisms serve to measure the acceptance and use of new 122 DNSSEC trust anchors and key signing keys (KSKs). This signaling 123 data can be used by zone administrators as a gauge to measure the 124 successful deployment of new keys. This is of particular interest 125 for the DNS root zone in the event of key and/or algorithm rollovers 126 that rely on [RFC5011] to automatically update a validating DNS 127 resolver's trust anchor. 129 This document does not introduce new processes for rolling keys or 130 updating trust anchors. Rather, it specifies a means by which a DNS 131 query can signal the set of keys that a client uses for DNSSEC 132 validation. 134 1.1. Design Evolution 136 Initially this document was named draft-edns-key-tag and proposed 137 including Key Tag values in a new EDNS(0) option code. It was 138 modeled after [RFC6975], which provides DNSSEC algorithm signaling. 140 The authors received feedback from Working Group participants that it 141 might be better to convey Key Tags in QNAME of a separate DNS query, 142 rather than as an EDNS(0) option. Mostly this is because forwarding 143 (e.g. from stub to recursive to authoritative) could be problematic. 144 Reasons include: 146 1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not 147 be forwarded by default, as per [RFC6891]. 149 2. Middleboxes might block entire queries containing unknown EDNS(0) 150 option codes. 152 3. A recursive might need to remember Key Tag values (i.e., keep 153 state) received from its stub clients and then forward them at a 154 later opportunity. 156 One advantage of the EDNS(0) option code is that it is possible to 157 see that a stub client has a different Key Tag list than its 158 forwarder. In the QNAME-based approach, this is not possible because 159 queries originated by a stub and a forwarder are indistinguishable. 160 The authors feel this advantage is not sufficient to justify the 161 EDNS(0) approach. 163 One downside to the QNAME approach is that it uses a separate query, 164 whereas with EDNS(0) the Key Tag values are "piggy-backed" on to an 165 existing DNSKEY query. For this reason, this document recommends 166 only sending QNAME-based key tag queries for configured trust 167 anchors, although EDNS-based key tags can be sent with any DNSKEY 168 query. 170 Another downside to the QNAME-based approach is that since the trust 171 anchor zone might not contain labels matching the QNAME, these 172 queries could be subject to aggressive negative caching features now 173 in development by the Working Group. This could affect the amount of 174 signaling sent by some clients compared to others. 176 A probably minor downside to the QNAME-based approach is that it 177 cannot be used with extremely long query names if the addition of the 178 prefix would cause the name to be longer than 255 octets. 180 2. Requirements Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Terminology 188 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 189 A validating security-aware resolver uses this public key or hash 190 as a starting point for building the authentication chain to a 191 signed DNS response. In general, a validating resolver will have 192 to obtain the initial values of its trust anchors via some secure 193 or trusted means outside the DNS protocol. Presence of a trust 194 anchor also implies that the resolver should expect the zone to 195 which the trust anchor points to be signed. (quoted from [RFC4033] 196 Section 2) 198 Key Tag: A 16-bit integer that identifies and enables efficient 199 selection of DNSSEC public keys. A Key Tag value can be computed 200 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 201 DS records can be used to help select the corresponding DNSKEY RR 202 efficiently when more than one candidate DNSKEY RR is available. 203 For most algorithms the Key Tag is a simple 16-bit modular sum of 204 the DNSKEY RDATA. See [RFC4034] Appendix B. 206 4. Using the edns-key-tag Option 208 4.1. Option Format 210 The edns-key-tag option is encoded as follows: 212 0 8 16 213 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 214 | OPTION-CODE | 215 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 216 | OPTION-LENGTH | 217 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 218 | KEY-TAG | 219 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 220 | ... / 221 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 223 where: 225 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. 227 OPTION-LENGTH: The value 2 x number of key-tag values present. 229 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 231 4.2. Use By Queriers 233 A validating resolver sets the edns-key-tag option in the OPT meta-RR 234 when sending a DNSKEY query. The validating resolver SHOULD also set 235 the DNSSEC OK bit [RFC4034] to indicate that it wishes to receive 236 DNSSEC RRs in the response. 238 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 239 queries. 241 The KEY-TAG value(s) included in the edns-key-tag option represent 242 the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 243 validate the expected response. When the client sends a DNSKEY 244 query, the edns-key-tag option represents the Key Tag(s) of the 245 KSK(s) of the zone for which the server is authoritative. A 246 validating resolver learns the Key Tag(s) of the KSK(s) from the 247 zone's DS record(s) (found in the parent), or from a configured trust 248 anchor. 250 A DNS client SHOULD include the edns-key-tag option when issuing a 251 DNSKEY query for a zone corresponding to a configured Trust Anchor. 253 A DNS client MAY include the edns-key-tag option when issuing a 254 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via 255 DS records). Since some DNSSEC validators implement bottom-up 256 validation, non-Trust Anchor Key Tags zone might not be known at the 257 time of the query. Such a validator can include the edns-key-tag 258 option based on previously cached data. 260 A DNS client MUST NOT include Key Tag(s) for keys which are not 261 learned via either configured Trust Anchor or DS records. 263 Since the edns-key-tag option is only set in the query, if a client 264 sees these options in the response, no action needs to be taken and 265 the client MUST ignore the option values. 267 4.2.1. Stub Resolvers 269 Typically, stub resolvers rely on an upstream recursive server (or 270 cache) to provide a response. Optimal setting of the edns-key-tag 271 option depends on whether the stub resolver elects to perform its own 272 validation. 274 4.2.1.1. Validating Stub Resolvers 276 A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to 277 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 278 RRs) in the response. Such validating resolvers SHOULD include the 279 edns-key-tag option in the OPT RR when sending a DNSKEY query. 281 4.2.1.2. Non-validating Stub Resolvers 283 The edns-key-tag option MUST NOT be included by non-validating stub 284 resolvers. 286 4.2.2. Recursive Resolvers 288 4.2.2.1. Validating Recursive Resolvers 290 A validating recursive resolver is, by definition, configured with at 291 least one trust anchor. Thus, a recursive resolver SHOULD include 292 the edns-key-tag option in its DNSKEY queries as described above. 294 In addition, the clients of a validating recursive resolver might be 295 configured to do their own validation, with their own trust 296 anchor(s). When a validating recursive resolver receives a query 297 that includes the edns-key-tag option with a Key Tag list that 298 differs from its own, it SHOULD forward both the client's Key Tag 299 list as well as its own. When doing so, the recursive resolver 300 SHOULD transmit the two Key Tag lists using separate instances of the 301 edns-key-tag option code in the OPT meta-RR. For example, if the 302 recursive resolver's Key Tag list is (19036, 12345) and the stub/ 303 client's list is (19036, 34567), the recursive would include the 304 edns-key-tag option twice: Once with values (19036, 12345) and once 305 with values (19036, 34567). 307 A validating recursive resolver MAY combine stub/client Key Tag 308 values from multiple incoming queries into a single outgoing query. 309 It is RECOMMENDED that implementations place reasonable limits on the 310 number of Key Tags to include in the outgoing edns-key-tag option. 312 If the client included the DO and Checking Disabled (CD) bits, but 313 did not include the edns-key-tag option in the query, the validating 314 recursive resolver MAY include the option with its own Key Tag values 315 in full. 317 Validating recursive resolvers MUST NOT set the edns-key-tag option 318 in the final response to the stub client. 320 4.2.2.2. Non-validating Recursive Resolvers 322 Recursive resolvers that do not validate responses SHOULD copy the 323 edns-key-tag option seen in received queries, as they represent the 324 wishes of the validating downstream resolver that issued the original 325 query. 327 4.3. Use By Responders 329 An authoritative name server receiving queries with the edns-key-tag 330 option MAY log or otherwise collect the Key Tag values to provide 331 information to the zone operator. 333 A responder MUST NOT include the edns-key-tag option in any DNS 334 response. 336 5. Using the Key Tag Query 338 5.1. Query Format 340 A key tag query consists of a standard DNS query of type NULL and of 341 class IN [RFC1035]. 343 The first component of the query name is the string "_ta-" followed 344 by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag 345 values. The zone name corresponding to the trust anchor is appended 346 to this first component. 348 For example, a validating DNS resolver that has a single root zone 349 trust anchor with key tag 17476 (decimal) would originate a query of 350 the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444. 352 Hexadecimal values MUST be zero-padded. For example, if the key tag 353 is 999 (decimal), it is represented in hexadecimal as 03e7. 355 When representing multiple key tag values, they MUST be sorted in 356 order from smallest to largest. For example, A validating DNS 357 resolver that has a three trust anchors for the example.com zone with 358 key tags 1589, 43547, 31406 (decimal) would originate a query of the 359 form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com. 361 5.2. Use By Queriers 363 A validating DNS resolver (stub or recursive) SHOULD originate a key 364 tag query whenever it also originates a DNSKEY query for a configured 365 Trust Anchor zone. In other words, the need to issue a DNSKEY query 366 is also the trigger to issue a key tag query. 368 The value(s) included in the key tag query represent the Key Tag(s) 369 of the Trust Anchor that will be used to validate the expected DNSKEY 370 response. 372 A DNS validating resolver SHOULD NOT originate key tag queries when 373 also originating DNSKEY queries for non-Trust Anchor zones. 375 A non-validating DNS resolver MUST NOT originate key tag queries. 377 DNS resolvers with caches SHOULD cache and reuse the response to a 378 key tag query just as it would any other response. 380 5.3. Use By Responders 382 An authoritative name server receiving key tag queries MAY log or 383 otherwise collect the Key Tag values to provide information to the 384 zone operator. 386 An authoritative name server MUST generate an appropriate response to 387 the key tag query. A server does not need to have built-in logic 388 that determines the response to key tag queries: the response code is 389 determined by whether the data is in the zone file or covered by 390 wildcard. The zone operator might want to add specific key tag 391 records to its zone, perhaps with specific TTLs, to affect the 392 frequency of key tag queries from clients. [ Note RFC1035 says NULL 393 RRs are not allowed in master files, but I believe that to be 394 incorrect ] 396 5.3.1. Interaction With Aggressive Negative Caching 398 Aggressive NSEC/NSEC3 negative caching 399 [draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of 400 key tag signaling. When the response code for a key tag query is 401 NXDOMAIN, DNS resolvers that implement aggressive negative caching 402 will send fewer key tag queries than resolvers that do not implement 403 it. 405 For this reason, zone operators might choose to create records 406 corresponding to expected key tag queries. During a rollover from 407 key tag 1111 (hex) to key tag 2222 (hex), the zone could include the 408 following records: 410 _ta-1111 IN NULL \# 0 411 _ta-2222 IN NULL \# 0 412 _ta-1111-2222 IN NULL \# 0 414 Recall that when multiple key tags are present, the originating 415 client MUST sort them from smallest to largest in the query name. 417 6. IANA Considerations 419 The IANA is directed to assign an EDNS0 option code for the edns-key- 420 tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: 422 +-------+--------------+----------+-----------------+ 423 | Value | Name | Status | Reference | 424 +-------+--------------+----------+-----------------+ 425 | [TBA] | edns-key-tag | Optional | [This document] | 426 +-------+--------------+----------+-----------------+ 428 7. Security Considerations 430 This document specifies a way for a client to signal its trust anchor 431 knowledge to a cache or server. The goal of these optional 432 mechanisms is to signal new trust anchor uptake in clients to allow 433 zone administrators to know when it is possible to complete a key 434 rollover in a DNSSEC-signed zone. 436 There is a possibility that an eavesdropper or server could infer the 437 validator in use by a client by the Key Tag list seen. This may 438 allow an attacker to find validators using old, possibly broken, 439 keys. It could also be used to identify the validator or narrow down 440 the possible validator implementations in use by a client, which 441 could have a known vulnerability that could be exploited by the 442 attacker. 444 Consumers of data collected from the mechanisms are advised that 445 provided Key Tag values might be "made up" by some DNS clients with 446 malicious or at least mischievous intentions. For example, an 447 attacker with sufficient resources might try to generate large 448 numbers of queries including only old Key Tag values, with the 449 intention of delaying the completion of a key rollover. 451 DNSSEC does not require keys in a zone to have unique Key Tags. 452 During a rollover there is a small possibility that an old key and a 453 new key will have identical Key Tag values. Zone operators relying 454 on the edns-key-tag mechanism SHOULD take care to ensure that new 455 keys have unique Key Tag values. 457 8. Privacy Considerations 459 This proposal adds additional, optional "signaling" to DNS queries in 460 the form of Key Tag values. While Key Tag values themselves are not 461 considered private information, it may be possible for an 462 eavesdropper to use Key Tag values as a fingerprinting technique to 463 identify particular DNS validating clients. This may be especially 464 true if the validator is configured with trust anchor for zones in 465 addition to the root zone. 467 A validating resolver need not transmit the key tags in every 468 applicable query. Due to privacy concerns, such a resolver MAY 469 choose to transmit the key tags for a subset of queries (e.g., every 470 25th time), or by random chance with a certain probability (e.g., 471 5%). 473 Implementations of this specification MAY be administratively 474 configured to only transmit the key tags for certain zones. For 475 example, the software's configuration file may specify a list of 476 zones for which use of the mechanisms described here is allowed or 477 denied. Since the primary motivation for this specification is to 478 provide operational measurement data for root zone key rollovers, it 479 is RECOMMENDED that implementations at least include the edns-key-tag 480 option for root zone DNSKEY queries. 482 9. Acknowledgments 484 This document was inspired by and borrows heavily from [RFC6975] by 485 Scott Rose and Steve Crocker. The authors would like to thank Mark 486 Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim 487 Wicinski, Suzanne Woolf, and other members of the dnsop working group 488 for their input. 490 10. References 492 10.1. Normative References 494 [RFC1035] Mockapetris, P., "Domain names - implementation and 495 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 496 November 1987, . 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 504 Rose, "DNS Security Introduction and Requirements", 505 RFC 4033, DOI 10.17487/RFC4033, March 2005, 506 . 508 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 509 Rose, "Resource Records for the DNS Security Extensions", 510 RFC 4034, DOI 10.17487/RFC4034, March 2005, 511 . 513 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 514 Rose, "Protocol Modifications for the DNS Security 515 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 516 . 518 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 519 for DNS (EDNS(0))", STD 75, RFC 6891, 520 DOI 10.17487/RFC6891, April 2013, 521 . 523 10.2. Informative References 525 [draft-ietf-dnsop-nsec-aggressiveuse] 526 Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016. 528 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 529 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 530 September 2007, . 532 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 533 Algorithm Understanding in DNS Security Extensions 534 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 535 . 537 Appendix A. Changes / Author Notes. 539 [RFC Editor: Please remove this section before publication] 541 From -01 to -02: 543 o Added QNAME-based method of signaling key tags. 545 o Added Paul Hoffman as coauthor. 547 From -00 to -01: 549 o Changed how a recursive should combine a stub's key tag values 550 with its own. Previously it was to be a union of key tag values. 551 Now it is a separate instance of the option code for recursive and 552 stub. 554 o Added Warren as coauthor. 556 Authors' Addresses 558 Duane Wessels 559 Verisign 560 12061 Bluemont Way 561 Reston, VA 20190 562 United States 564 Phone: +1 703 948-3200 565 Email: dwessels@verisign.com 566 URI: http://verisigninc.com 567 Warren Kumari 568 Google 569 1600 Amphitheatre Parkway 570 Mountain View, CA 94043 571 United States 573 Email: warren@kumari.net 575 Paul Hoffman 576 ICANN 578 Email: paul.hoffman@icann.org