idnits 2.17.1 draft-hardaker-dnsops-name-server-management-reqs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 754. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2008) is 5821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 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 May 19, 2008 5 Expires: November 20, 2008 7 Requirements for Management of Name Servers for the DNS 8 draft-hardaker-dnsops-name-server-management-reqs-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 20, 2008. 35 Abstract 37 Management of name servers for the Domain Name Service (DNS) has 38 traditionally been done using vendor-specific monitoring, 39 configuration and control methods. Although some service monitoring 40 platforms can test the functionality of the DNS itself there is not a 41 interoperable way to manage (monitor, control and configure) the 42 internal aspects of a name server itself. 44 This document discusses the requirements of a management system for 45 DNS name servers. A management solution that is designed to manage 46 the DNS can use this document as a shopping list of needed features. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 52 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 53 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 54 2. Management Architecture Requirements . . . . . . . . . . . . . 5 55 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 56 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 57 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 58 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 59 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 60 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6 61 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7 62 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 63 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 64 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 65 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 66 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 67 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 68 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 69 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 70 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 71 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 72 3.2.5. DNS Protocol Authorization Management . . . . . . . . 10 73 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 74 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11 75 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 76 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 77 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 78 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 79 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 80 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 81 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 83 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 84 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 85 5.1.3. Namespace Collision Protection . . . . . . . . . . . . 13 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 14 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 93 Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 94 A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 95 A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 Intellectual Property and Copyright Statements . . . . . . . . . . 18 100 1. Introduction 102 Management of name servers for the Domain Name Service (DNS) 103 [RFC1034] [RFC1035] has traditionally been done using vendor-specific 104 monitoring, configuration and control methods. Although some service 105 monitoring platforms can test the functionality of the DNS itself 106 there is not a interoperable way to manage (monitor, control and 107 configure) the internal aspects of a name server itself. 109 Previous standardization work within the IETF resulted in the 110 creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed 111 to achieve significant implementation and deployment. The perceived 112 reasons behind the failure for the two MIB modules are further 113 documented in [RFC3197]. 115 This document discusses the requirements of a management system for 116 DNS name servers. A management solution that is designed to manage 117 the DNS can use this document as a shopping list of needed features. 119 Specifically out of scope for this document are requirements 120 associated with management of stub resolvers. It is not the intent 121 of this document to document stub resolver requirements, although 122 some of the requirements listed are applicable to stub resolvers as 123 well. 125 Also out of scope for this document is management of the host or 126 other components of the host upon which the name server software is 127 running. This document only discusses requirements for managing the 128 name server component of a system. 130 The task of creating a management system for managing DNS servers is 131 not expected to be a small one. It is likely that components of the 132 solution will need to be designed in parts over time and these 133 requirements take this into consideration. In particular, 134 Section 5.1 discusses the need for future extensibility of the base 135 management solution. This document is intended to be a road-map 136 towards a desired outcome and is not intended to define an "all-or- 137 nothing" system. Successful interoperable management of name servers 138 even in part is expected to be beneficial to network operators 139 compared to the entirely custom solutions that are used at the time 140 of this writing. 142 1.1. Requirements notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 1.1.1. Terminology 150 This document is consistent with the terminology defined in Section 2 151 of [RFC4033]. Additional terminology needed for this document are 152 described below: 154 Name Server: When we are discussing servers that don't fall into a 155 more specific type of server category defined in other documents, 156 this document will refer to them generically as "name servers". 157 In particular "name servers" can be considered to be any valid 158 combination of authoritative, recursive, validating, or security- 159 aware. The more specific name server labels will be used when 160 this document refers only to a specific type of server. However, 161 the term "name server", in this document, will not include stub 162 resolvers. 164 1.1.2. Document Layout and Requirements 166 The document is written so that each numbered section will contain 167 only a single requirement if it contains one at all. Each 168 requirement will contain needed wording from the terminology 169 described in Section 1.1. Subsections, however, might exist with 170 additional related requirements. The document is laid out in this 171 way so that a specific requirement can be uniquely referred to using 172 the section number itself and the document version from which it 173 came. 175 2. Management Architecture Requirements 177 This section discusses requirements that reflect the needs of the 178 expected deployment environments. 180 2.1. Expected Deployment Scenarios 182 DNS zones vary greatly in the type of content published within them. 183 Name Servers, too, are deployed with a wide variety of configurations 184 to support the diversity of the deployed content. It is important 185 that a management solution trying to meet the criteria specified in 186 this document consider supporting the largest number of potential 187 deployment cases as possible. Further deployment scenarios that are 188 not used as direct examples of specific requirements are listed in 189 Appendix A. 191 2.1.1. Zone Size Constraints 193 The management solution MUST support both name servers that are 194 serving a small number of potentially very large zones (e.g. Top 195 Level Domains (TLDs)) as well as name servers that are serving a very 196 large number of small zones. These scenarios are both commonly seen 197 deployments. 199 2.1.2. Name Server Discovery 201 Large enterprise network deployments may contain multiple name 202 servers operating within the boundaries of the enterprise network. 203 These name servers may each be serving multiple zones both in and out 204 of the parent enterprise's zone. Finding and managing large 205 quantities of name servers would be a useful feature of the resulting 206 management solution. The management solution MAY support the ability 207 to discover previously unknown instances of name servers operating 208 within a deployed network. 210 2.1.3. Configuration Data Volatility 212 Configuration data is defined as data that relates only to the 213 configuration of a server and the zones it serves. It specifically 214 does not include data from the zone contents that is served through 215 DNS itself. The solution MUST support servers that remain fairly 216 statically configured over time as well as servers that have numerous 217 zones being added and removed within an hour. Both of these 218 scenarios are also commonly seen deployments. 220 2.1.4. Protocol Selection 222 There are many requirements in this document for many different types 223 of management operations (see Section 3 for further details). It is 224 possible that no one protocol will ideally fill all the needs of the 225 requirements listed in this document and thus multiple protocols 226 might be needed to produce a completely functional management system. 227 Multiple protocols might be used to create the complete management 228 solution, but the number of protocols used SHOULD be reduced to a 229 reasonable minimum number. 231 2.1.5. Common Data Model 233 Defining a standardized protocol (or set of protocols) to use for 234 managing name servers would be a step forward in achieving an 235 interoperable management solution. However, just defining a protocol 236 to use by itself would not achieve the complete end goal of a 237 complete interoperable management solution. Devices also need to 238 represent their internal management interface using a common 239 management data model. The solution MUST create a common data model 240 that management stations can make use of when sending or collecting 241 data from a managed device so it can successfully manage equipment 242 from vendors as if they were generic DNS servers. This common data 243 model is needed for of the operations discussion in section 244 Section 3. Note that this does not preclude the fact that name 245 server vendors might provide additional management infrastructure 246 beyond a base management specification, as discussed further in 247 Section 5.1. 249 2.1.6. Operational Impact 251 It is impossible to add new features to an existing server (such as 252 the inclusion of a management infrastructure) and not impact the 253 existing service and/or server in some fashion. At a minimum, for 254 example, more memory, disk and/or CPU resources will be required to 255 implement a new management system. However, the impact to the 256 existing DNS service MUST be minimized since the DNS service itself 257 is still the primary service to be offered by the modified name 258 server. 260 2.2. Name Server Types 262 There are multiple ways in which name servers can be deployed. Name 263 servers can take on any of the following roles: 265 o Master Servers 267 o Slave Servers 269 o Recursive Servers 271 The management solution SHOULD support all of these types of name 272 servers as they are all equally important. Note that "Recursive 273 Servers" can be further broken down by the security sub-roles they 274 might implement, as defined in section 2 of [RFC4033]. These sub- 275 roles are also important to support within any management solution. 277 The requirements in this document explicitly exclude dealing with 278 management of stub resolvers. Management of stub resolvers is 279 considered specifically out of scope of this document. 281 3. Management Operation Types 283 Management operations can traditionally be broken into four 284 categories: 286 o Control 288 o Configuration 289 o Health and Monitoring 291 o Alarms and Events 293 This section discusses requirements for each of these for management 294 types in detail. 296 3.1. Control Requirements 298 The management solution MUST be capable of performing basic service 299 control operations. 301 3.1.1. Needed Control Operations 303 These operations SHOULD include, at a minimum, the following 304 operations: 306 o Starting the name server 308 o Reloading the service configuration 310 o Reloading zone data 312 o Restarting the name server 314 o Stopping the name server 316 Note that no restriction is placed on how the management system 317 implements these operations. In particular, at least "starting the 318 name server" will require a minimal management system component to 319 exist independently of the name server itself. 321 3.1.2. Asynchronous Status Notifications 323 Some control operations might take a long time to complete. As an 324 example, some name servers take a long time to perform reloads of 325 large zones. Because of these timing issues, the management solution 326 SHOULD take this into consideration and offer a mechanism to ease the 327 burden associated with awaiting the status of a long-running command. 328 This could, for example, result in the use of asynchronous 329 notifications for returning the status of a long-running task or it 330 might require the management station to poll for the status of a 331 given task using monitoring commands. These and other potential 332 solutions need to be evaluated carefully to select one that balances 333 the result delivery needs with the perceived implementation costs. 335 Also, see the related discussion in Section 3.4 which discusses 336 notification messages for supporting delivery of alarm and event 337 messages. 339 3.2. Configuration Requirements 341 Many features of name servers need to be configured before the server 342 can be considered functional. The management solution MUST be able 343 to provide name servers with configuration data. The most important 344 data to be configured, for example, is the served zone data itself. 346 3.2.1. Served Zone Modification 348 The ability to add, modify and delete zones being served by name 349 servers is needed. Although there are already solutions for zone 350 content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], 351 AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that 352 might be used as part of the final management solution, the 353 management system SHOULD still be able to natively create a new zone 354 (with enough minimal data to allow the other mechanisms to function 355 as well) as well as delete a zone. This might be, for example, a 356 management operation that at least allows for the creation of the 357 initial SOA record for a new zone as that's the minimum amount of 358 zone data needed for the other operations to function. 360 3.2.2. Trust Anchor Management 362 The solution SHOULD support the ability to add, modify and delete 363 trust anchors that are used by DNS Security (DNSSEC) [RFC4033] 364 [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust 365 anchors might be configured using the data from the DNSKEY Resource 366 Records (RRs) themselves or by using Delegation Signer (DS) 367 fingerprints. 369 3.2.3. Security Expectations 371 DNSSEC Validating resolvers need to make policy decisions about the 372 requests being processed. For example, They need to be configured 373 with a list of zones expected to be secured by DNSSEC. The 374 management solution SHOULD be able to add, modify and delete 375 attributes of DNSSEC security policies. 377 3.2.4. TSIG Key Management 379 TSIG [RFC2845] allows transaction level authentication of DNS 380 traffic. The management solution SHOULD be able to add, modify and 381 delete TSIG keys known to the name server. 383 3.2.5. DNS Protocol Authorization Management 385 The management solution SHOULD have the ability to add, modify and 386 delete authorization settings for the DNS protocols itself. Do not 387 confuse this with the ability to manage the authorization associated 388 with the management protocol itself, which is discussed later in 389 Section 4.4. There are a number of authorization settings that are 390 used by a name server. Example authorization settings that the 391 solution might need to cover are: 393 o Access to operations on zone data (e.g. DDNS) 395 o Access to certain zone data from certain sources (e.g. from 396 particular network subnets) 398 o Access to specific DNS protocol services (e.g. recursive service) 400 Note: the above list is expected to be used as examples and is not a 401 complete list of needed authorization protections. 403 3.3. Monitoring Requirements 405 Monitoring is the process of collecting aspects of the internal state 406 of a name server at a given moment in time. The solution MUST be 407 able to monitor the health of a name server to determine its 408 operational status, load and other internal attributes. Example 409 management tasks that the solution might need to cover are: 411 o Number of requests sent, responses sent, average response latency 412 and other performance counters 414 o Server status (e.g. "serving data", "starting up", "shutting 415 down", ...) 417 o Access control violations 419 o List of zones being served 421 o Detailed statistics about clients interacting with the name server 422 (e.g. top 10 clients requesting data). 424 Note: the above list is expected to be used as examples and is not a 425 complete list of needed monitoring operations. In particular, some 426 monitoring statistics are expected to be computationally or resource 427 expensive and are considered to be "nice to haves" as opposed to 428 "necessary to have". 430 3.4. Alarm and Event Requirements 432 Events occurring at the name server that trigger alarm notifications 433 can quickly inform a management station about critical issues. A 434 management solution SHOULD include support for delivery of alarm 435 conditions. 437 Example alarm conditions might include: 439 o The server's status is changing. (e.g it is starting up, reloading 440 configuration, restarting or shutting down) 442 o A needed resource (e.g. memory or disk space) is exhausted or 443 nearing exhaustion 445 o An authorization violation was detected 447 o The server has not received any data traffic (e.g. DNS requests 448 or NOTIFYs) recently (AKA the "lonely warning"). This condition 449 might indicate a problem with its deployment. 451 4. Security Requirements 453 The management solution will need to be appropriately secured against 454 attacks on the management infrastructure. 456 4.1. Authentication 458 The solution MUST support mutual authentication. The management 459 client needs to be assured that the management operations are being 460 transferred to and from the correct name server. The managed name 461 server needs to authenticate the system that is accessing the 462 management infrastructure within itself. 464 4.2. Integrity Protection 466 Management operations MUST be protected from modification while in 467 transit from the management client to the server. 469 4.3. Confidentiality 471 The management solution MUST support message confidentiality. The 472 potential transfer of sensitive configuration is expected (such as 473 TSIG keys or security policies). The solution does not, however, 474 necessarily need to provide confidentiality to data that would 475 normally be carried without confidentiality by the DNS system itself. 477 4.4. Authorization 479 The solution SHOULD be capable of providing a fine-grained 480 authorization model for any management protocols it introduces to the 481 completed system. This authorization differs from the authorization 482 previously discussed in Section 3.2.5 in that this requirement is 483 concerned solely with authorization of the management system itself. 485 There are a number of authorization settings that might be used by a 486 managed system to determine whether the managing entity has 487 authorization to perform the given management task. Example 488 authorization settings that the solution might need to cover are: 490 o Access to the configuration that specifies which zones are to be 491 served 493 o Access to the management system infrastructure 495 o Access to other control operations 497 o Access to other configuration operations 499 o Access to monitoring operations 501 Note: the above list is expected to be used as examples and is not a 502 complete list of needed authorization protections. 504 4.5. Solution Impacts on Security 506 The solution MUST minimize the security risks introduced to the 507 complete name server system. It is impossible to add new 508 infrastructure to a server and not impact the security in some 509 fashion as the introduction of a management protocol alone will 510 provide a new avenue for potential attack. Although the added 511 management benefits will be worth the increased risks, the solution 512 still needs to minimize this impact as much as possible. 514 5. Other Requirements 516 5.1. Extensibility 518 The management solution is expected to change and expand over time as 519 lessons are learned and new DNS features are deployed. Thus, the 520 solution MUST be flexible and be able to accommodate new future 521 management operations. The solution might, for example, make use of 522 protocol versioning or capability description exchanges to ensure 523 that management stations and name servers that weren't written to the 524 same specification version can still interoperate to the best of 525 their combined ability. 527 5.1.1. Vendor Extensions 529 It MUST be possible for vendors to extend the standardized management 530 model with vendor-specific extensions to support additional features 531 offered by their products. 533 5.1.2. Extension Identification 535 It MUST be possible for a management station to understand which 536 parts of returned data are specific to a given vendor or other 537 standardized extension. The data returned needs to be appropriately 538 marked through the use of name spaces or similar mechanisms to ensure 539 that the base management model data can be logically separated from 540 extension data without needing to understand the extension data 541 itself. 543 5.1.3. Namespace Collision Protection 545 It MUST be possible to protect against multiple extensions 546 conflicting with each other. The use of name-space protection 547 mechanisms for communicated management variables is common practice 548 to protect against problems. Name-space identification techniques 549 also frequently solve the "Extension Identification" requirement 550 discussed in Section 5.1.2 as well. 552 6. Security Considerations 554 Any management protocol that meets the criteria discussed in this 555 document needs to support the criteria discussed in Section 4 in 556 order to protect the management infrastructure itself. The DNS is a 557 core Internet service and management traffic that protects it could 558 be the target of attacks designed to subvert that service. Because 559 the management infrastructure will be adding additional interfaces to 560 that service, it is critical that the management infrastructure 561 support adequate protections against network attacks. 563 7. IANA Considerations 565 No action is required from IANA for this document. 567 8. Document History 569 A requirement gathering discussion was held at the December 2007 IETF 570 meeting in Vancouver, BC, Canada and a follow up meeting was held at 571 the March 2008 IETF meeting in Philadelphia. This document is a 572 compilation of the results of those discussions as well as 573 discussions on the DCOMA mailing list. 575 9. Acknowledgments 577 This draft is the result of discussions within the DCOMA design team 578 chaired by Jaap Akkerhuis. This team consisted of a large number of 579 people all of whom provided valuable insight and input into the 580 discussions surrounding name server management. The text of this 581 document was written from notes taken during meetings as well as from 582 contributions sent to the DCOMA mailing list. This work documents 583 the consensus of the DCOMA design team. 585 In particular, the following team members contributed significantly 586 to the text in the document: 588 Stephane Bortzmeyer 590 Stephen Morris 592 Phil Regnauld 594 10. References 596 10.1. Normative References 598 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 599 STD 13, RFC 1034, November 1987. 601 [RFC1035] Mockapetris, P., "Domain names - implementation and 602 specification", STD 13, RFC 1035, November 1987. 604 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 605 August 1996. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 611 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 612 RFC 2136, April 1997. 614 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 615 Wellington, "Secret Key Transaction Authentication for DNS 616 (TSIG)", RFC 2845, May 2000. 618 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 619 Update", RFC 3007, November 2000. 621 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 622 Rose, "DNS Security Introduction and Requirements", 623 RFC 4033, March 2005. 625 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 626 Rose, "Resource Records for the DNS Security Extensions", 627 RFC 4034, March 2005. 629 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 630 Rose, "Protocol Modifications for the DNS Security 631 Extensions", RFC 4035, March 2005. 633 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 634 (DS) Resource Records (RRs)", RFC 4509, May 2006. 636 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 637 Trust Anchors", RFC 5011, September 2007. 639 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 640 Security (DNSSEC) Hashed Authenticated Denial of 641 Existence", RFC 5155, March 2008. 643 10.2. Informative References 645 [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", 646 RFC 1611, May 1994. 648 [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", 649 RFC 1612, May 1994. 651 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 652 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 653 July 1997. 655 [RFC3197] Austein, R., "Applicability Statement for DNS MIB 656 Extensions", RFC 3197, November 2001. 658 Appendix A. Deployment Scenarios 660 This appendix documents some additional deployment scenarios that 661 have been traditionally difficult to manage. They are provided as 662 guidance to protocol developers as data points of real-world name 663 server management problems. 665 A.1. Non-Standard Zones 667 If an organization uses non-standard zones (for example a purely- 668 local TLD), synchronizing all the nameservers for these zones is 669 usually a time-consuming task. It is made worse when two 670 organizations with conflicting zones merge. This situation is not a 671 recommended deployment scenario (and is even heavily discouraged) but 672 it is, unfortunately, seen in the wild. 674 It is typically implemented using "forwarding" zones. But there is 675 no way to ensure automatically that all the resolvers have the same 676 set of zones to forward at any given time. New zones might be added 677 to a local forwarding recursive server, for example, without 678 modifying the rest of the deployed forwarding servers. It is hoped 679 that a management solution which could handle the configuration of 680 zone forwarding would finally allow management of servers deployed in 681 this fashion. 683 A.2. Redundancy Sharing 685 For reliability reasons it is recommended that zone operators follow 686 the guidelines documented in [RFC2182] which recommends that multiple 687 name servers be configured for each zone and that the name servers 688 are separated both physically and via connectivity routes. A common 689 solution is to establish DNS-serving partnerships: "I'll host your 690 zones and you'll host mine". Both entities benefit from increased 691 DNS reliability via the wider service distribution. This frequently 692 occurs between cooperating but otherwise unrelated entities (such as 693 between two distinct companies) as well as between affiliated 694 organizations (such as between branch offices within a single 695 company). 697 The configuration of these relationships are currently required to be 698 manually configured and maintained. Changes to the list of zones 699 that are cross-hosted are manually negotiated between the cooperating 700 network administrators and configured by hand. A management protocol 701 with the ability to provide selective authorization, as discussed in 702 Section 4.4, would solve many of the management difficulties between 703 cooperating organizations. 705 Author's Address 707 Wes Hardaker 708 Sparta, Inc. 709 P.O. Box 382 710 Davis, CA 95617 711 US 713 Phone: +1 530 792 1913 714 Email: ietf@hardakers.net 716 Full Copyright Statement 718 Copyright (C) The IETF Trust (2008). 720 This document is subject to the rights, licenses and restrictions 721 contained in BCP 78, and except as set forth therein, the authors 722 retain all their rights. 724 This document and the information contained herein are provided on an 725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 727 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 728 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 729 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 732 Intellectual Property 734 The IETF takes no position regarding the validity or scope of any 735 Intellectual Property Rights or other rights that might be claimed to 736 pertain to the implementation or use of the technology described in 737 this document or the extent to which any license under such rights 738 might or might not be available; nor does it represent that it has 739 made any independent effort to identify any such rights. Information 740 on the procedures with respect to rights in RFC documents can be 741 found in BCP 78 and BCP 79. 743 Copies of IPR disclosures made to the IETF Secretariat and any 744 assurances of licenses to be made available, or the result of an 745 attempt made to obtain a general license or permission for the use of 746 such proprietary rights by implementers or users of this 747 specification can be obtained from the IETF on-line IPR repository at 748 http://www.ietf.org/ipr. 750 The IETF invites any interested party to bring to its attention any 751 copyrights, patents or patent applications, or other proprietary 752 rights that may cover technology that may be required to implement 753 this standard. Please address the information to the IETF at 754 ietf-ipr@ietf.org.