idnits 2.17.1 draft-ietf-dnsop-name-server-management-reqs-05.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 5, 2011) is 4853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP W. Hardaker 3 Internet-Draft Sparta, Inc. 4 Intended status: Informational January 5, 2011 5 Expires: July 9, 2011 7 Requirements for Management of Name Servers for the DNS 8 draft-ietf-dnsop-name-server-management-reqs-05.txt 10 Abstract 12 Management of name servers for the Domain Name System (DNS) has 13 traditionally been done using vendor-specific monitoring, 14 configuration and control methods. Although some service monitoring 15 platforms can test the functionality of the DNS itself there is not 16 an interoperable way to manage (monitor, control and configure) the 17 internal aspects of a name server itself. 19 This document discusses the requirements of a management system for 20 name servers and can be used as a shopping list of needed features 21 for such a system. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 9, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 71 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 6 72 1.1.2. Document Layout and Requirements . . . . . . . . . . . 6 73 2. Management Architecture Requirements . . . . . . . . . . . . . 6 74 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 6 75 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6 76 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 7 77 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 7 78 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 7 79 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 7 80 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 8 81 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 8 82 3. Management Operation Types . . . . . . . . . . . . . . . . . . 8 83 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 9 84 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 9 85 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 9 86 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 10 87 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 10 88 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 10 89 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 10 90 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 10 91 3.2.5. DNS Protocol Authorization Management . . . . . . . . 11 92 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 11 93 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 12 94 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 95 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 96 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 12 97 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 98 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 99 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 13 100 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 13 101 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 102 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 14 103 5.1.2. Extension Identification . . . . . . . . . . . . . . . 14 104 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 14 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 107 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 15 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 112 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 17 113 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 17 114 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 17 115 A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 18 116 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 118 1. Introduction 120 Management of name servers for the Domain Name System (DNS) [RFC1034] 121 [RFC1035] has traditionally been done using vendor-specific 122 monitoring, configuration and control methods. Although some service 123 monitoring platforms can test the functionality of the DNS itself 124 there is not an interoperable way to manage (monitor, control and 125 configure) the internal aspects of a name server itself. 127 Previous standardization work within the IETF resulted in the 128 creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed 129 to achieve significant implementation and deployment. The perceived 130 reasons behind the failure for the two MIB modules are further 131 documented in [RFC3197]. 133 This document discusses the requirements of a management system for 134 name servers and can be used as a shopping list of needed features 135 for such a system. This document only discusses requirements for 136 managing the name server component of a system and not other elements 137 of the system itself. 139 Specifically out of scope for this document are requirements 140 associated with management of stub resolvers. It is not the intent 141 of this document to document stub resolver requirements, although 142 some of the requirements listed are applicable to stub resolvers as 143 well. 145 The task of creating a management system for managing DNS servers is 146 not expected to be a small one. It is likely that components of the 147 solution will need to be designed in parts over time and these 148 requirements take this into consideration. In particular, 149 Section 5.1 discusses the need for future extensibility of the base 150 management solution. This document is intended to be a road-map 151 towards a desired outcome and is not intended to define an "all-or- 152 nothing" system. Successful interoperable management of name servers 153 even in part is expected to be beneficial to network operators 154 compared to the entirely custom solutions that are used at the time 155 of this writing. 157 1.1. Requirements notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 1.1.1. Terminology 165 This document is consistent with the terminology defined in Section 2 166 of [RFC4033]. Additional terminology needed for this document is 167 described below: 169 Name Server: When we are discussing servers that don't fall into a 170 more specific type of server category defined in other documents, 171 this document will refer to them generically as "name servers". 172 In particular "name servers" can be considered to be any valid 173 combination of authoritative, recursive, validating, or security- 174 aware. The more specific name server labels will be used when 175 this document refers only to a specific type of server. However, 176 the term "name server", in this document, will not include stub 177 resolvers. 179 1.1.2. Document Layout and Requirements 181 The document is written so that each numbered section will contain 182 only a single requirement if it contains one at all. Each 183 requirement will contain needed wording from the terminology 184 described in Section 1.1. Subsections, however, might exist with 185 additional related requirements. The document is laid out in this 186 way so that a specific requirement can be uniquely referred to using 187 the section number itself and the document version from which it 188 came. 190 2. Management Architecture Requirements 192 This section discusses requirements that reflect the needs of the 193 expected deployment environments. 195 2.1. Expected Deployment Scenarios 197 DNS zones vary greatly in the type of content published within them. 198 Name Servers, too, are deployed with a wide variety of configurations 199 to support the diversity of the deployed content. It is important 200 that a management solution trying to meet the criteria specified in 201 this document consider supporting the largest number of potential 202 deployment cases as possible. Further deployment scenarios that are 203 not used as direct examples of specific requirements are listed in 204 Appendix A. 206 2.1.1. Zone Size Constraints 208 The management solution MUST support both name servers that are 209 serving a small number of potentially very large zones (e.g. Top 210 Level Domains (TLDs)) as well as name servers that are serving a very 211 large number of small zones. Both deployment scenarios are common. 213 2.1.2. Name Server Discovery 215 Large enterprise network deployments may contain multiple name 216 servers operating within the boundaries of the enterprise network. 217 These name servers may each be serving multiple zones both in and out 218 of the parent enterprise's zone. Finding and managing a large 219 numbers of name servers would be a useful feature of the resulting 220 management solution. The management solution MAY support the ability 221 to discover previously unknown instances of name servers operating 222 within a deployed network. 224 2.1.3. Configuration Data Volatility 226 Configuration data is defined as data that relates only to the 227 configuration of a server and the zones it serves. It specifically 228 does not include data from the zone contents that is served through 229 DNS itself. The solution MUST support servers that remain statically 230 configured over time as well as servers that have numerous zones 231 being added and removed within an hour. Both deployment scenarios 232 are common. 234 2.1.4. Protocol Selection 236 There are many requirements in this document for many different types 237 of management operations (see Section 3 for further details). It is 238 possible that no one protocol will ideally fill all the needs of the 239 requirements listed in this document and thus multiple protocols 240 might be needed to produce a completely functional management system. 241 Multiple protocols might be used to create the complete management 242 solution, but the solution SHOULD require only one. 244 2.1.5. Common Data Model 246 Defining a standardized protocol (or set of protocols) to use for 247 managing name servers would be a step forward in achieving an 248 interoperable management solution. However, just defining a protocol 249 to use by itself would not achieve the complete end goal of a 250 complete interoperable management solution. Devices also need to 251 represent their internal management interface using a common 252 management data model. The solution MUST create a common data model 253 that management stations can make use of when sending or collecting 254 data from a managed device so it can successfully manage equipment 255 from vendors as if they were generic DNS servers. This common data 256 model is needed for the operations discussion in Section 3. Note 257 that this does not preclude the fact that name server vendors might 258 provide additional management infrastructure beyond a base management 259 specification, as discussed further in Section 5.1. 261 2.1.6. Operational Impact 263 It is impossible to add new features to an existing server (such as 264 the inclusion of a management infrastructure) and not impact the 265 existing service and/or server in some fashion. At a minimum, for 266 example, more memory, disk and/or CPU resources will be required to 267 implement a new management system. However, the impact to the 268 existing DNS service MUST be minimized since the DNS service itself 269 is still the primary service to be offered by the modified name 270 server. The management solution MUST NOT result in an increase of 271 the number of unhandled DNS requests. 273 2.2. Name Server Types 275 There are multiple ways in which name servers can be deployed. Name 276 servers can take on any of the following roles: 278 o Master Servers 280 o Slave Servers 282 o Recursive Servers 284 The management solution SHOULD support all of these types of name 285 servers as they are all equally important. Note that "Recursive 286 Servers" can be further broken down by the security sub-roles they 287 might implement, as defined in section 2 of [RFC4033]. These sub- 288 roles are also important to support within any management solution. 290 As stated earlier, the management of stub resolvers is considered out 291 of scope for this documents. 293 3. Management Operation Types 295 Management operations can traditionally be broken into four 296 categories: 298 o Control 300 o Configuration 302 o Health and Monitoring 303 o Alarms and Events 305 This section discusses requirements for each of these four management 306 types in detail. 308 3.1. Control Requirements 310 The management solution MUST be capable of performing basic service 311 control operations. 313 3.1.1. Needed Control Operations 315 These operations SHOULD include, at a minimum, the following 316 operations: 318 o Starting the name server 320 o Reloading the service configuration 322 o Reloading of all of the zone data 324 o Reloading of individual zone data sets 326 o Restarting the name server 328 o Stopping the name server 330 Note that no restriction is placed on how the management system 331 implements these operations. In particular, at least "starting the 332 name server" will require a minimal management system component to 333 exist independently of the name server itself. 335 3.1.2. Asynchronous Status Notifications 337 Some control operations might take a long time to complete. As an 338 example, some name servers take a long time to perform reloads of 339 large zones. Because of these timing issues, the management solution 340 SHOULD take this into consideration and offer a mechanism to ease the 341 burden associated with awaiting the status of a long-running command. 342 This could, for example, result in the use of asynchronous 343 notifications for returning the status of a long-running task or it 344 might require the management station to poll for the status of a 345 given task using monitoring commands. These and other potential 346 solutions need to be evaluated carefully to select one that balances 347 the result delivery needs with the perceived implementation costs. 349 Also, see the related discussion in Section 3.4 on notification 350 messages for supporting delivery of alarm and event messages. 352 3.2. Configuration Requirements 354 Many features of name servers need to be configured before the server 355 can be considered functional. The management solution MUST be able 356 to provide name servers with configuration data. The most important 357 data to be configured, for example, is the served zone data itself. 359 3.2.1. Served Zone Modification 361 The ability to add, modify and delete zones being served by name 362 servers is needed. Although there are already solutions for zone 363 content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], 364 AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that 365 might be used as part of the final management solution, the 366 management system SHOULD still be able to create a new zone (with 367 enough minimal data to allow the other mechanisms to function as 368 well) as well as delete a zone. This might be, for example, a 369 management operation that at least allows for the creation of the 370 initial SOA (Start of a zone Of Authority) record for a new zone as 371 that's the minimum amount of zone data needed for the other 372 operations to function. 374 3.2.2. Trust Anchor Management 376 The solution SHOULD support the ability to add, modify and delete 377 trust anchors that are used by DNS Security (DNSSEC) [RFC4033] 378 [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust 379 anchors might be configured using the data from the DNSKEY Resource 380 Records (RRs) themselves or by using Delegation Signer (DS) 381 fingerprints. 383 3.2.3. Security Expectations 385 DNSSEC Validating resolvers need to make policy decisions about the 386 requests being processed. For example, they need to be configured 387 with a list of zones expected to be secured by DNSSEC. The 388 management solution SHOULD be able to add, modify and delete 389 attributes of DNSSEC security policies. 391 3.2.4. TSIG Key Management 393 TSIG [RFC2845] allows transaction level authentication of DNS 394 traffic. The management solution SHOULD be able to add, modify and 395 delete TSIG keys known to the name server. 397 3.2.5. DNS Protocol Authorization Management 399 The management solution SHOULD have the ability to add, modify and 400 delete authorization settings for the DNS protocols itself. Do not 401 confuse this with the ability to manage the authorization associated 402 with the management protocol itself, which is discussed later in 403 Section 4.4. There are a number of authorization settings that are 404 used by a name server. Example authorization settings that the 405 solution might need to cover are: 407 o Access to operations on zone data (e.g. DDNS) 409 o Access to certain zone data from certain sources (e.g. from 410 particular network subnets) 412 o Access to specific DNS protocol services (e.g. recursive service) 414 Note: the above list is expected to be used as a collection of 415 examples and is not a complete list of needed authorization 416 protections. 418 3.3. Monitoring Requirements 420 Monitoring is the process of collecting aspects of the internal state 421 of a name server at a given moment in time. The solution MUST be 422 able to monitor the health of a name server to determine its 423 operational status, load and other internal attributes. Example 424 management tasks that the solution might need to cover are: 426 o Number of requests sent, responses sent, number of errors, average 427 response latency and other performance counters 429 o Server status (e.g. "serving data", "starting up", "shutting 430 down", ...) 432 o Access control violations 434 o List of zones being served 436 o Detailed statistics about clients interacting with the name server 437 (e.g. top 10 clients requesting data). 439 Note: the above list is expected to be used as a collection of 440 examples and is not a complete list of needed monitoring operations. 441 In particular, some monitoring statistics are expected to be 442 computationally or resource expensive and are considered to be "nice 443 to haves" as opposed to "necessary to have". 445 3.4. Alarm and Event Requirements 447 Events occurring at the name server that trigger alarm notifications 448 can quickly inform a management station about critical issues. A 449 management solution SHOULD include support for delivery of alarm 450 conditions. 452 Example alarm conditions might include: 454 o The server's status is changing. (e.g it is starting up, reloading 455 configuration, restarting or shutting down) 457 o A needed resource (e.g. memory or disk space) is exhausted or 458 nearing exhaustion 460 o An authorization violation was detected 462 o The server has not received any data traffic (e.g. DNS requests 463 or NOTIFYs) recently (AKA the "lonely warning"). This condition 464 might indicate a problem with its deployment. 466 o The number of errors has exceeded a configured threshold 468 4. Security Requirements 470 The management solution will need to be appropriately secured against 471 attacks on the management infrastructure. 473 4.1. Authentication 475 The solution MUST support mutual authentication. The management 476 client needs to be assured that the management operations are being 477 transferred to and from the correct name server. The managed name 478 server needs to authenticate the system that is accessing the 479 management infrastructure within itself. 481 4.2. Integrity Protection 483 Management operations MUST be protected from modification while in 484 transit from the management client to the server. 486 4.3. Confidentiality 488 The management solution MUST support message confidentiality. The 489 potential transfer of sensitive configuration is expected (such as 490 TSIG keys or security policies). The solution does not, however, 491 necessarily need to provide confidentiality to data that would 492 normally be carried without confidentiality by the DNS system itself. 494 4.4. Authorization 496 The solution SHOULD provide an authorization model capable of 497 selectively authorizing individual management requests for any 498 management protocols it introduces to the completed system. This 499 authorization differs from the authorization previously discussed in 500 Section 3.2.5 in that this requirement is concerned solely with 501 authorization of the management system itself. 503 There are a number of authorization settings that might be used by a 504 managed system to determine whether the managing entity has 505 authorization to perform the given management task. Example 506 authorization settings that the solution might need to cover are: 508 o Access to the configuration that specifies which zones are to be 509 served 511 o Access to the management system infrastructure 513 o Access to other control operations 515 o Access to other configuration operations 517 o Access to monitoring operations 519 Note: the above list is expected to be used as a collection of 520 examples and is not a complete list of needed authorization 521 protections. 523 4.5. Solution Impacts on Security 525 The solution MUST minimize the security risks introduced to the 526 complete name server system. It is impossible to add new 527 infrastructure to a server and not impact the security in some 528 fashion as the introduction of a management protocol alone will 529 provide a new avenue for potential attack. Although the added 530 management benefits will be worth the increased risks, the solution 531 still needs to minimize this impact as much as possible. 533 5. Other Requirements 535 5.1. Extensibility 537 The management solution is expected to change and expand over time as 538 lessons are learned and new DNS features are deployed. Thus, the 539 solution MUST be flexible and be able to accommodate new future 540 management operations. The solution might, for example, make use of 541 protocol versioning or capability description exchanges to ensure 542 that management stations and name servers that weren't written to the 543 same specification version can still interoperate to the best of 544 their combined ability. 546 5.1.1. Vendor Extensions 548 It MUST be possible for vendors to extend the standardized management 549 model with vendor-specific extensions to support additional features 550 offered by their products. 552 5.1.2. Extension Identification 554 It MUST be possible for a management station to understand which 555 parts of returned data are specific to a given vendor or other 556 standardized extension. The data returned needs to be appropriately 557 marked through the use of name spaces or similar mechanisms to ensure 558 that the base management model data can be logically separated from 559 extension data without needing to understand the extension data 560 itself. 562 5.1.3. Name-Space Collision Protection 564 It MUST be possible to protect against multiple extensions 565 conflicting with each other. The use of name-space protection 566 mechanisms for communicated management variables is common practice 567 to protect against problems. Name-space identification techniques 568 also frequently solve the "Extension Identification" requirement 569 discussed in Section 5.1.2 as well. 571 6. Security Considerations 573 Any management protocol for which conformance to this document is 574 claimed needs to fully support the criteria discussed in Section 4 in 575 order to protect the management infrastructure itself. The DNS is a 576 core Internet service and management traffic that protects it could 577 be the target of attacks designed to subvert that service. Because 578 the management infrastructure will be adding additional interfaces to 579 that service, it is critical that the management infrastructure 580 support adequate protections against network attacks. 582 7. IANA Considerations 584 No action is required from IANA for this document. 586 8. Document History 588 A requirement gathering discussion was held at the December 2007 IETF 589 meeting in Vancouver, BC, Canada and a follow up meeting was held at 590 the March 2008 IETF meeting in Philadelphia. This document is a 591 compilation of the results of those discussions as well as 592 discussions on the DCOMA mailing list. 594 9. Acknowledgments 596 This draft is the result of discussions within the DCOMA design team 597 chaired by Jaap Akkerhuis. This team consisted of a large number of 598 people all of whom provided valuable insight and input into the 599 discussions surrounding name server management. The text of this 600 document was written from notes taken during meetings as well as from 601 contributions sent to the DCOMA mailing list. This work documents 602 the consensus of the DCOMA design team. 604 In particular, the following team members contributed significantly 605 to the text in the document: 607 Stephane Bortzmeyer 609 Stephen Morris 611 Phil Regnauld 613 Further editing contributions and wording suggestions were made by: 614 Alfred Hoenes, Doug Barton. 616 10. References 618 10.1. Normative References 620 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 621 STD 13, RFC 1034, November 1987. 623 [RFC1035] Mockapetris, P., "Domain names - implementation and 624 specification", STD 13, RFC 1035, November 1987. 626 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 627 August 1996. 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 633 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 634 RFC 2136, April 1997. 636 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 637 Wellington, "Secret Key Transaction Authentication for DNS 638 (TSIG)", RFC 2845, May 2000. 640 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 641 Update", RFC 3007, November 2000. 643 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 644 Rose, "DNS Security Introduction and Requirements", 645 RFC 4033, March 2005. 647 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 648 Rose, "Resource Records for the DNS Security Extensions", 649 RFC 4034, March 2005. 651 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 652 Rose, "Protocol Modifications for the DNS Security 653 Extensions", RFC 4035, March 2005. 655 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 656 (DS) Resource Records (RRs)", RFC 4509, May 2006. 658 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 659 Trust Anchors", RFC 5011, September 2007. 661 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 662 Security (DNSSEC) Hashed Authenticated Denial of 663 Existence", RFC 5155, March 2008. 665 10.2. Informative References 667 [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", 668 RFC 1611, May 1994. 670 [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", 671 RFC 1612, May 1994. 673 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 674 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 675 July 1997. 677 [RFC3197] Austein, R., "Applicability Statement for DNS MIB 678 Extensions", RFC 3197, November 2001. 680 Appendix A. Deployment Scenarios 682 This appendix documents some additional deployment scenarios that 683 have been traditionally difficult to manage. They are provided as 684 guidance to protocol developers as data points of real-world name 685 server management problems. 687 A.1. Non-Standard Zones 689 If an organization uses non-standard zones (for example a purely- 690 local TLD), synchronizing all the name servers for these zones is 691 usually a time-consuming task. It is made worse when two 692 organizations with conflicting zones merge. This situation is not a 693 recommended deployment scenario (and is even heavily discouraged) but 694 it is, unfortunately, seen in the wild. 696 It is typically implemented using "forwarding" zones. But there is 697 no way to ensure automatically that all the resolvers have the same 698 set of zones to forward at any given time. New zones might be added 699 to a local forwarding recursive server, for example, without 700 modifying the rest of the deployed forwarding servers. It is hoped 701 that a management solution which could handle the configuration of 702 zone forwarding would finally allow management of servers deployed in 703 this fashion. 705 A.2. Redundancy Sharing 707 For reliability reasons it is recommended that zone operators follow 708 the guidelines documented in [RFC2182] which recommends that multiple 709 name servers be configured for each zone and that the name servers 710 are separated both physically and via connectivity routes. A common 711 solution is to establish DNS-serving partnerships: "I'll host your 712 zones and you'll host mine". Both entities benefit from increased 713 DNS reliability via the wider service distribution. This frequently 714 occurs between cooperating but otherwise unrelated entities (such as 715 between two distinct companies) as well as between affiliated 716 organizations (such as between branch offices within a single 717 company). 719 The configuration of these relationships are currently required to be 720 manually configured and maintained. Changes to the list of zones 721 that are cross-hosted are manually negotiated between the cooperating 722 network administrators and configured by hand. A management protocol 723 with the ability to provide selective authorization, as discussed in 724 Section 4.4, would solve many of the management difficulties between 725 cooperating organizations. 727 A.3. DNSSEC Management 729 There are many different DNSSEC deployment strategies that may be 730 used for mission-critical zones. The following list describes some 731 example deployment scenarios that might warrant different management 732 strategies. 734 All contents and DNSSEC keying information controlled and operated 735 by a single organization 737 Zone contents controlled and operated by one organization, all 738 DNSSEC keying information controlled and operated by a second 739 organization. 741 Zone contents controlled and operated by one organization, zone 742 signing keys (ZSKs) controlled and operated by a second 743 organization, and key signing keys (KSKs) controlled and operated 744 by a third organization. 746 Although this list is not exhaustive in the potential ways that zone 747 data can be divided up, it should be sufficient to illustrate the 748 potential ways in which zone data can be controlled by multiple 749 entities. 751 The end result of all of these strategies, however, will be the same: 752 a live zone containing DNSSEC related resource records. Many of the 753 above strategies are merely different ways of preparing a zone for 754 serving. A management solution that includes support for managing 755 DNSSEC zone data may wish to take into account these potential 756 management scenarios. 758 Author's Address 760 Wes Hardaker 761 Sparta, Inc. 762 P.O. Box 382 763 Davis, CA 95617 764 US 766 Phone: +1 530 792 1913 767 Email: ietf@hardakers.net