idnits 2.17.1 draft-dickinson-dnsop-nameserver-control-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: + NSEC Instruction to use the NSEC scheme for authenticated denial of existence, described in [RFC4034]. This element MUST not occur alongside an NSEC3 element. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: + NSEC3 Instruction to use the NSEC3 scheme for authenticated denial of existence, described in [RFC5155]. This element MUST not occur alongside an NSEC element -- 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 (March 14, 2011) is 4763 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) ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-name-server-management-reqs (ref. 'I-D.ietf-dnsop-name-server-management-reqs') Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dickinson 3 Internet-Draft S. Dickinson 4 Intended status: Standards Track Sinodun Internet Technologies 5 Expires: September 15, 2011 S. Morris 6 Internet Systems Consortium 7 R. Arends 8 Nominet UK 9 March 14, 2011 11 A name server Data Model 12 draft-dickinson-dnsop-nameserver-control-02.txt 14 Abstract 16 This document presents a data model for a name server, to be used in 17 the construction of a name server control protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 15, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. View . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2.2. Elements for the default CHAOS class . . . . . . . . . 7 63 2.3. Access Control List . . . . . . . . . . . . . . . . . . . 7 64 2.3.1. ACE . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.3.2. Default . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.4. Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 68 2.4.2. Elements . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.5. PeerGroup . . . . . . . . . . . . . . . . . . . . . . . . 9 70 2.5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.6. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.6.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.7. DNSSECPolicy . . . . . . . . . . . . . . . . . . . . . . . 11 74 2.7.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 11 75 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 5.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 In the -00 and -01 versions of this draft we discussed a data model 85 for NSCP, the potential use of NETCONF as the transport layer and 86 YANG as a modeling language. In this version, we have removed the 87 text on NETCONF and YANG for the time being so that we can 88 concentrate on the data model. In the future, discussion of possible 89 transports for the data and its transformations may be added to this 90 or a completely new draft on that subject. In addition, this version 91 of the draft concentrates on authoritative servers. Resolvers and 92 validators will be added in future versions. 94 1.1. Background 96 Management of DNS name servers is currently carried out via vendor- 97 specific control, configuration and monitoring methods. 98 Organizations run multiple name server implementations from a variety 99 of vendors. A common method of name server management can simplify 100 administration and reduce cost. 102 The requirements for the management of name servers have been 103 established and documented 104 [I-D.ietf-dnsop-name-server-management-reqs]. In essence, the 105 document describes a set of common operations that name servers are 106 known to implement. 108 1.2. Data Model 110 A key requirement of [I-D.ietf-dnsop-name-server-management-reqs] is 111 the standardisation of a data model representing name servers. With 112 such a model, a protocol can de designed to communicate between a 113 client and a name server. 115 1.3. Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Data Model 123 This diagram is a refinement on the one in previous versions of this 124 draft in that it shows the relationships between the major elements 125 of the server. 127 Server 128 |1 129 | 130 |2-* 131 +------View 132 |* |1 133 | | 134 |* |* 135 ACL Zone----------+ 136 |1 |1 |* 137 | | | 138 |* |* |0-1 139 ACE---PeerGroup DNSSECPolicy 140 |* 141 | 142 |1-* 143 Peer 145 (The numbers indicate the cardinality of the associations.) The 146 following sections describe each object in more detail. For every 147 object, the following information is provided: 149 o A discussion of the entity - what it represents and its purpose. 151 o A list of the object's elements - the name of each element and the 152 contents. 154 Every object may have associated statistics elements. These have not 155 been shown in the above diagram for clarity. Some are described in 156 this document but many more are likely to be added to later versions 157 of this draft. 159 In this data model it is expected that filenames and directory 160 structures will be fixed by the implementation. Therefore, for 161 example, a zone does not have a filename element and the server does 162 not have a working directory or pid file specified. 164 At this stage, this draft does not attempt to contain every 165 configuration element in all existing name servers. It is 166 anticipated that vendor specific extensions will be added to allow 167 full configuration of a specific implementation. However, this model 168 (when finished) should be sufficient to allow basic command and 169 control of most name servers. 171 2.1. Server 173 The server object is the root of the configuration tree and serves as 174 the focus for server-wide operations and repository for server-wide 175 information. 177 2.1.1. Elements 179 o Reference to 2 or more Views 181 o Statistics 182 It is assumed that the server is capable of generating the subset 183 of Bind 8 style statistics currently supported by both NSD [NSD] 184 and Bind 9 [BIND9ARM]. These are the statistics relevant at the 185 server level. Additional statistics will be added to other 186 elements in the model. 188 * SAns 189 Count of answers sent 191 * RAXFR 192 Count of AXFR initiated 194 * RQ 195 Count of requests received 197 * SNXD 198 Count of NXDomain sent 200 * RUQ 201 Count of non-recursive queries rejected 203 * RURQ 204 Count of recursive queries rejected 206 * RUXFR 207 Count of XFR rejected 209 * RUUpd 210 Count of updates rejected 212 2.2. View 214 The view object can be considered as a virtual server. It groups 215 zones with similar access characteristics. It is more than just the 216 association of a zone and an ACL: a view allows the server to send 217 different replies to clients according to the following properties of 218 the query packet 220 o Source address (and port). 222 o Destination address (and port). 224 o Whether or not the query requests recursion. (Not used in this 225 version of the draft) 227 In the authoritative server case currently being considered in this 228 draft, the replies can differ in terms of 230 o Which zones are available to a given client. 232 o The contents of those zones. 234 o Any configuration parameters of the server or zone. 236 To aid in the definition of a common object model, a view will always 237 exist in the NSCP data model, even if the name server concerned does 238 not implement views. All implementations of NSCP MUST implement a 239 view named _default" of class IN and a similarly-named view for class 240 CHAOS. (The latter view is required to serve the "version.bind" and 241 "server.id" RRs - see below.) 243 2.2.1. Elements 245 o Name 246 A name for the view. 248 o Class 249 Which class this view is for. Default is IN. 251 o Reference to 0 or 1 ACL for source address 253 o Reference to 0 or 1 ACL for destination address. 255 o References to 0 or more Zones. 257 o ListenOn 258 What IP address and port to bind this view to. This can occur 259 zero or more times. The IP address can be either IPV4 or IPV6. 261 The address/network is represented in standard form (e.g. 262 192.0.2.0/24 or 2001:0DB8::/32) 264 o Port 265 Optional port number. 267 2.2.2. Elements for the default CHAOS class 269 o Version 270 The version of the name server to report in response to a query 271 for the name version.bind, type TXT in the CHAOS class. If set to 272 "none" then the server will not respond. 274 o ServerId 275 The id a server should report in response to a query for 276 id.server, type TXT in the CHAOS class. If set to "none" then the 277 server will not respond. 279 2.3. Access Control List 281 Access to services on the name server are controlled by Access 282 Control Lists (ACL). Using common nomenclature, an ACL comprises one 283 or more Access Control Entries (ACEs). Each ACE links an attribute 284 of the accessor (an "identifier") to one or more access rights to the 285 resource being controlled. 287 An ACL is attached to a view. However, it may be useful for it to be 288 referenced by a zone. This will be considered further in a future 289 version of this draft. 291 An ACL contains the following elements: 293 o Name 294 Unique identifier used by a view to refer to the ACL 296 o ACE 297 Reference to zero or more access control entries, each entry 298 defining a match between an identifier and access modes. 300 o Default 301 Zero or one default ACE - the access check will stop on the first 302 match, and a default matches everything: once the default ACE is 303 reached, no more ACEs will be checked. 305 The order of ACEs within an ACL is important. When checking for 306 access, the system MUST attempt to match each ACE in turn. If none 307 match, the system MUST attempt to match a default ACE (a wildcard 308 that matches any accessor). If there is no default accessor, access 309 MUST be denied. 311 2.3.1. ACE 313 An ACE links an identifier with one or more access modes. An ACE has 314 the following sub-elements: 316 o Identifier 317 This element - of which there must be one and only one - defines 318 what is accessing the system. The element's value is the name of 319 a PeerGroup defining one or more external systems. 321 o Access 322 Access elements define what access rights the accessor has to the 323 server, such as operations they are able to undertake and data 324 they are able to see. There are one or more access elements in 325 each ACE. The value of this element is one of the following: 327 None No access. This overrides any other type of access, 328 and denies access to the accessor. 330 Notify Causes the server to take notice of NOTIFY messages 331 from the accessor. 333 NonRecursive Allows the accessor to make a non-recursive request 334 to the server. 336 Transfer Allows the accessor to transfer data from the server 337 (either AXFR or IXFR). 339 Update Causes the server to accept dynamic update messages 340 from the accessor. 342 2.3.2. Default 344 A default access control entry is consulted only if all explicit ACEs 345 fail to match. It does not contain an "identifier" clause (being 346 deemed to match all identifiers), only access elements as described 347 above. 349 2.4. Zone 351 2.4.1. Discussion 353 The zone object represents a zone served by the name server and 354 comprises a collection of resource records. It is anticipated that 355 the zone data will not be created via NSCP, instead being defined by 356 the contents of a zone file or an external database populated and 357 transported to the name server via a different method or in band to 358 DNS via dynamic updates or a zone transfer. If it is necessary to 359 transmit zone contents using NSCP then it is anticipated that this 360 can be defined using an extension to this data model. (This will be 361 the subject of a separate draft.) This means that with this basic 362 data model it will only be possible to provision zones via AXFR by 363 specifying a master server from which the secondary name server will 364 have to obtain the zone data or, in the case of a master name server 365 generation of a zone stub (SOA + 1 NS) to allow dynamic updates. 367 2.4.2. Elements 369 o Name 370 The name of the zone being served. The name of a zone MUST be 371 unique within a view, although different views may have zones with 372 the same name. 374 o Master 375 The identifier of a PeerGroup that can act as a master server for 376 this zones. This can occur zero or more times. 378 o Secondary 379 The identifier of a PeerGroup that can act as slave server for 380 this zones. This can occur zero or more times. Note: This says 381 nothing about whether or not those servers should be sent 382 notifies. Both master and secondary can appear for a single zone. 384 o Notify 385 The identifier of a PeerGroup to which notifies should be sent to 386 for this zone. This can occur zero or more times. 388 o SOA 389 An SOA RR that is sufficient to allow population of zone via 390 dynamic updates. 392 o NS 393 One or more NS RR that will be sufficient to allow population of 394 zone via dynamic updates. 396 o References to 0 or 1 DNSSECPolicies 398 2.5. PeerGroup 400 Named groups of peers. A group may consist of one or more peers. 401 All references to external systems will be by reference to a 402 PeerGroup. The components of a PeerGroup are: 404 2.5.1. Elements 406 o Name 407 A name for a PeerGroup. This name is unique, and is used 408 elsewhere in the model as a reference to external systems. 410 o References to 1 or more Peers. 412 2.6. Peer 414 A Peer is an object representing any external system or systems. It 415 either participates in the authoritative name server service by being 416 a master or a secondary, or is a system that uses the name server 417 service. A Peer can be identified by a combination of: 419 o As the holder of a particular TSIG key. 421 o By address range (including an address range indicating a single 422 address) and optional port. 424 Where only an address element is present, the identification is 425 clear. Should only a key element be present an external system 426 corresponds to the Peer if it presents a suitable signature. The 427 combination of address and key elements allows TSIG transactions to 428 be more discriminating; an external system corresponds to the Peer if 429 and only if it presents correct signatures and its address is correct 430 For maximum flexibility Peers do not exist in isolation. Instead, 431 they are members of at least one PeerGroup (even if that group 432 comprises only the Peer). 434 2.6.1. Elements 436 o Name 437 A name for this Peer. This name is unique. 439 o Address 440 Describes an IP address. There can be zero or more address 441 elements in the Peer although, if there are no address elements, a 442 key element MUST be present. The contents of the address element 443 are: 445 * IP 446 This is mandatory and holds the IP address of the Peer. The IP 447 address can be either IPV4 or IPV6. The address/network is 448 represented in standard form (e.g. 192.0.2.0/24 or 2001: 449 0DB8::/32). 451 * Port 452 Optional port number. 454 o Key 455 A TSIG key to be used when talking to this Peer. This is 456 optional. The contents of a key element are one of: 458 * HMAC-MD5 459 This holds the secret for HMAC-MD5. 461 * HMAC-SHA1 462 This holds the secret for HMAC-SHA1. 464 Use of an element per algorithm will allow easy augmentation with 465 future algorithms. 467 2.7. DNSSECPolicy 469 The DNSSEC policy defines a policy for any DNSSEC signing operations 470 performed by a name server. It is based on the kasp.xml file in 471 OpenDNSSEC [KASP]. 473 2.7.1. Elements 475 o Name 476 The name for this policy. This must be unique. It will be 477 referred to by zones to specify how the zone will be signed. 479 o Signatures 480 Parameters for the signatures created using the policy. 482 * Resign 483 The re-sign interval. 485 * Refresh 486 The refresh interval, detailing when a signature should be 487 refreshed. 489 * Validity 491 + Default 492 Validity interval for all RRSIG records except those related 493 to NSEC or NSEC3 records. 495 + Denial 496 Validity interval for all RRSIG records related to NSEC or 497 NSEC3 records. 499 * Jitter 500 Value added to or extracted from the expiration time of 501 signatures to ensure that not all signatures expire at the same 502 time. 504 * InceptionOffset 505 Duration subtracted from the time at which a record is signed 506 to give the start time of the record. 508 * Denial 509 This includes one element, either NSEC3 (as shown) or an empty 510 NSEC element. 512 + NSEC 513 Instruction to use the NSEC scheme for authenticated denial 514 of existence, described in [RFC4034]. This element MUST not 515 occur alongside an NSEC3 element. 517 + NSEC3 518 Instruction to use the NSEC3 scheme for authenticated denial 519 of existence, described in [RFC5155]. This element MUST not 520 occur alongside an NSEC element 522 - OptOut 523 If present, enable an "opt out" optimisation that means 524 that NSEC3 records are only created for authoritative 525 data or for secure delegations; insecure delegations have 526 no NSEC3 records. 528 - Resalt 529 The interval between generating new salt values for the 530 hashing algorithm. 532 - Hash 533 Values for parameters of the hashing algorithm, as 534 described in RFC 5155. 536 o Algorithm 537 Integer specifying the algorithm listed in the IANA 538 DNSSEC NSEC3 Hash Algorithms registry. 540 o Iteration 541 The number of additional times the hash function will 542 be performed. 544 o SaltLength 545 The length of the Salt field in octets, ranging in 546 value from 0 to 255 548 * Keys 550 + TTL 551 The time-to-live value for the DNSKEY resource records. 553 + RetireSafety 554 This interval is the safety margin added to calculated 555 timing values to ensure that keys are retired without there 556 being a chance of signatures created with the keys being 557 considered invalid. 559 + PublishSafety 560 This interval is the safety margin added to calculated 561 timing values to ensure that keys are published without 562 there being a chance of signatures created with the keys 563 being considered invalid. 565 + ShareKeys 566 If multiple zones are associated with a policy, the presence 567 of ShareKeys indicates that a key can be shared between 568 zones. 570 + Purge 571 If Purge is present, keys marked as dead will be 572 automatically purged from the database after this interval. 574 * KSK 576 + Algorithm 577 Determines the algorithm used for the key (the numbers 578 reserved for each algorithm can be found in the appropriate 579 IANA registry). 581 + Lifetime 582 Determines how long the key is used for before it is rolled. 584 + Respository 585 Determines the location of the keys. Keys are stored in 586 repositories which are either hardware or software security 587 modules that conform to the PKCS#11 standard [PKCS#11]. 589 + ManualRollover 590 If present, indicate thats the key rollover will only be 591 initiated on the command of the operator. 593 * ZSK 594 + Algorithm 595 Determines the algorithm used for the key (the numbers 596 reserved for each algorithm can be found in the appropriate 597 IANA registry). 599 + Lifetime 600 Determines how long the key is used for before it is rolled. 602 + Respository 603 Determines the location of the keys. Keys are stored in 604 repositories which are either hardware or software security 605 modules that conform to the PKCS#11 standard. 607 * Zone 609 + PropagationDelay 610 The amount of time needed for information changes at the 611 master server for the zone to work its way through to all 612 the secondary nameservers. 614 + SOA 615 Values of parameters for the SOA record in the signed zone. 617 - TTL 618 TTL of the SOA record. 620 - Minimum 621 Value for the SOA's "minimum" parameter. 623 - Serial 624 The format of the serial number in the signed zone 625 (either counter, datecounter, unixtime or keep). 627 * Parent 629 + PropagationDelay 630 The interval between the time a new KSK is published in the 631 zone and the time that the DS record appears in the parent 632 zone. 634 + DS 635 Information about the DS record in the parent. 637 - TTL 638 TTL of the DS record in the parent zone. 640 + SOA 641 Information about parameters of the parent's SOA record. 643 - TTL 644 TTL of the SOA record. 646 - Minimum 647 Value for the SOA's "minimum" parameter. 649 3. IANA Considerations 651 This memo includes no request to IANA. 653 4. Security Considerations 655 To be completed. 657 5. References 659 5.1. Normative References 661 [I-D.ietf-dnsop-name-server-management-reqs] 662 Hardaker, W., "Requirements for Management of Name Servers 663 for the DNS", 664 draft-ietf-dnsop-name-server-management-reqs-05 (work in 665 progress), January 2011. 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, March 1997. 670 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 671 Rose, "Resource Records for the DNS Security Extensions", 672 RFC 4034, March 2005. 674 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 675 Security (DNSSEC) Hashed Authenticated Denial of 676 Existence", RFC 5155, March 2008. 678 5.2. Informative References 680 [BIND9ARM] 681 "BIND 9 Administrator Reference Manual", 682 . 685 [KASP] "OpenDNSSEC Documentation: kasp.xml", . 688 [NSD] "NSD README file", 689 . 691 [PKCS#11] "PKCS #11: Cryptographic Token Interface Standard", 692 . 694 Authors' Addresses 696 John A Dickinson 697 Sinodun Internet Technologies 698 Stables 4 Suite 11 699 Howbery Park 700 Wallingford, Oxfordshire OX10 8BA 701 UK 703 Email: jad@sinodun.com 705 Sara A Dickinson 706 Sinodun Internet Technologies 707 Stables 4 Suite 11 708 Howbery Park 709 Wallingford, Oxfordshire OX10 8BA 710 UK 712 Email: sara@sinodun.com 714 Stephen Morris 715 Internet Systems Consortium 716 950 Charter Streed 717 Redwood City CA 94063 718 USA 720 Email: stephen@isc.org 722 Roy Arends 723 Nominet UK 724 Minerva House 725 Edmund Halley Road 726 Oxford Science Park 727 Oxford, Oxfordshire OX4 4DQ 728 UK 730 Email: roy.arends@nominet.org.uk