idnits 2.17.1 draft-toorop-dnsop-dns-zone-provisioning-yang-01.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 == Line 143 has weird spacing: '...gorithm ine...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 13, 2020) is 1473 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3688' is mentioned on line 366, but not defined ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group P. Lexis 3 Internet-Draft PowerDNS 4 Intended status: Standards Track L. Lhotka 5 Expires: October 15, 2020 P. Spacek 6 CZ.NIC 7 O. Sury 8 Internet Systems Consortium 9 W. Toorop 10 NLnet Labs 11 April 13, 2020 13 A Data Model for configuring Domain Name System (DNS) Zone Provisioning 14 on Authoritative Nameservers 15 draft-toorop-dnsop-dns-zone-provisioning-yang-01 17 Abstract 19 This document describes a data model for configuring DNS Zone 20 provisioning on authoritative nameservers. This data model only 21 includes definitions for configuration of primary and secondary 22 relationships. 24 The purpose of this document is to enumerate the properties involved 25 in managing zone provisioning, for usage in managing zone 26 provisioning methods, such as catalog zones or NETCONF. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 15, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.2. Properties for primary nameservers . . . . . . . . . . . 3 65 1.3. Properties for primary nameservers . . . . . . . . . . . 3 66 2. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 This document describes a data model for configuring DNS Zone 77 provisioning on authoritative nameservers. The model consists of a 78 list of DNS Zones. Besides the name of the zone, each zone MAY 79 contain properties for provisioning of those zones on primary and 80 secondary nameservers. 82 1.1. Definitions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY", 86 and "OPTIONAL" in this document are to be interpreted as described in 87 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 1.2. Properties for primary nameservers 92 The optional properties for primary nameservers are: 94 o "notify-to" 96 Which value consists of an IP address (with optional port-number) 97 of the secondary nameserver to notify about changes to the zone, 98 and an optional TSIG key (See [RFC2845]) with which the NOTIFY 99 message [RFC1996] - which is used to send the notification - is 100 signed. 102 If no port-number is given, port 53 is assumed. 104 o "allow-transfer" 106 Which value consist of a subnet in which the IP address of the 107 secondary nameserver requesting a transfer has to fall, with an 108 optional TSIG key with which the transfer request (either AXFR 109 AXFR [RFC5936] or IXFR [RFC1995]) has to be signed and which will 110 be used to sign the messages that will convey the complete or 111 partial DNS Zone. 113 1.3. Properties for primary nameservers 115 The optional properties for secondary nameservers are: 117 o "allow-notify" 119 Which value consist of a subnet in which the IP address of the 120 primary nameserver which is signaling that the DNS Zone has 121 changed must fall, and an optional TSIG with which the NOTIFY 122 message use MUST be signed. 124 o "transfer-from" 126 Which value consists of an IP address (with optional port-number) 127 of the primary nameserver from which to transfer the complete or 128 partial DNS Zone, with an optional TSIG which MUST be used to send 129 the AXFR or IXFR request and with which the transferred Zone data 130 MUST be verified. 132 If no port-number is given, port 53 is assumed. 134 2. Tree Structure 136 This document defined the YANG module "ietf-dns-zone-provisioning", 137 which has the following tree structure. 139 module: ietf-dns-zone-provisioning 140 +--rw tsig-keys 141 | +--rw tsig-key* [name] 142 | +--rw name inet:domain-name 143 | +--rw algorithm inet:domain-name 144 | +--rw secret string 145 +--rw zones 146 +--rw zone* [name] 147 +--rw name inet:domain-name 148 +--rw allow-notify* [subnet] 149 | +--rw subnet inet:ip-prefix 150 | +--rw tsig-key? -> /tsig-keys/tsig-key/name 151 +--rw allow-transfer* [subnet] 152 | +--rw subnet inet:ip-prefix 153 | +--rw tsig-key? -> /tsig-keys/tsig-key/name 154 +--rw notify-to* [ip port] 155 | +--rw ip inet:ip-address 156 | +--rw port inet:port-number 157 | +--rw tsig-key? -> /tsig-keys/tsig-key/name 158 +--rw transfer-from* [ip port] 159 +--rw ip inet:ip-address 160 +--rw port inet:port-number 161 +--rw tsig-key? -> /tsig-keys/tsig-key/name 163 3. YANG Module 165 file "ietf-dns-zone-provisioning@2020-04-13.yang" 166 module ietf-dns-zone-provisioning { 168 yang-version 1.1; 170 namespace "urn:ietf:params:xml:ns:yang" 171 + ":ietf-dns-zone-provisioning"; 173 prefix dnszp; 175 import ietf-inet-types { 176 prefix inet; 177 } 179 organization 180 "IETF Domain Name System Operations Working Group (dnsop)"; 182 contact 183 "WG Web: 184 WG List: 186 Editor: Willem Toorop 187 "; 189 description 190 "This YANG module defines a model for configuring DNS Zone 191 provisioning on authoritative nameservers. 193 Copyright (c) 2020 IETF Trust and the persons identified as 194 authors of the code. All rights reserved. 196 Redistribution and use in source and binary forms, with or 197 without modification, is permitted pursuant to, and subject to 198 the license terms contained in, the Simplified BSD License set 199 forth in Section 4.c of the IETF Trust's Legal Provisions 200 Relating to IETF Documents 201 (https://trustee.ietf.org/license-info). 203 This version of this YANG module is part of RFC ????; see the 204 RFC itself for full legal notices."; 206 revision 2020-03-09 { 207 description 208 "Initial revision."; 209 reference 210 "RFC XXXX: A YANG Data Model for" 211 + " DNS Zone provisioning configuration"; 212 } 214 /* Groupings */ 216 grouping tsig-key { 217 leaf name { 218 type inet:domain-name; 219 mandatory true; 220 description 221 "The name of the key"; 222 } 223 leaf algorithm { 224 type inet:domain-name; 225 mandatory true; 226 description 227 "Name of the algorithm"; 228 reference 229 ""; 231 } 232 leaf secret { 233 type string; 234 mandatory true; 235 description 236 "Shared secret in base64 format. Possible lengths are 237 dependent on the algorithm"; 238 } 239 description 240 "Shared key used for authenticating transactions with 241 authoritative name servers"; 242 reference 243 "RFC2845: Secret Key Transaction Authentication for DNS 244 (TSIG)"; 245 } 246 grouping acl-net-key { 247 leaf subnet { 248 type inet:ip-prefix; 249 mandatory true; 250 description 251 "Contacting IP address must match this subnet."; 252 } 253 leaf tsig-key { 254 type leafref { 255 path "/tsig-keys/tsig-key/name"; 256 } 257 description 258 "When provided all interactions to and from the 259 contacting remote end must use this tsig-key."; 260 } 261 description 262 "Access control allowing the action from IP addresses from the 263 given subnet and tsig-key if present. Without tsig-key only 264 the subnet needs to match. The subnet should be 0.0.0.0/0 or 265 ::/0 to allow access from all IPv4 or all IPv6 addresses"; 266 } 268 grouping addr-key { 269 leaf ip { 270 type inet:ip-address; 271 mandatory true; 272 description 273 "IP address to contact."; 274 } 275 leaf port { 276 type inet:port-number; 277 default 53; 278 description 279 "Port to conact."; 280 } 281 leaf tsig-key { 282 type leafref { 283 path "/tsig-keys/tsig-key/name"; 284 } 285 description 286 "When provided all interactions with to and from the 287 contacted remote end must use this tsig-key."; 288 } 289 description 290 "IP address of remote party to contact, either to notify about 291 updates in the zone, or to fetch the zone from. An optional 292 tsig-key can be given to validate the transfer or to sign the 293 notify."; 294 } 296 container tsig-keys { 297 list tsig-key { 298 key "name"; 299 uses tsig-key; 300 description 301 "The tsig-key which is referred to from acl-net-key 302 and/or addr-key."; 303 } 304 description 305 "The list of tsig-keys which are referred from 306 acl-net-key and addr-key."; 307 } 309 container zones { 310 list zone { 311 key "name"; 312 leaf name { 313 type inet:domain-name; 314 description 315 "The name of the DNS Zone"; 316 } 317 list allow-notify { 318 key "subnet"; 319 uses acl-net-key; 320 description 321 "Secondary servers allow notifies for DNS Zone updates 322 from IP addresses from this subnet. If a tsig-key is 323 given, the notify must be signed with that key."; 324 } 325 list allow-transfer { 326 key "subnet"; 327 uses acl-net-key; 328 description 329 "Primary servers allow transfers to the IP addresses 330 to the given subnet. If a tsig-key is given, the transfer 331 request must be signed and the DNS messages used for the 332 transfer will also be signed with that tsig-key"; 333 } 334 list notify-to { 335 key "ip port"; 336 uses "addr-key"; 337 description 338 "Primary servers send NOTIFY messages when the Zonne 339 has been updated to this IP. If a tsig-key is given, 340 it will be signed with that key."; 341 } 342 list transfer-from { 343 key "ip port"; 344 uses "addr-key"; 345 description 346 "Secondary servers contact the given ip-address to 347 acquire DNS Zone content. When a tsig-key is given 348 the request will be signed with it, and the DNS 349 messages conveying the Zone must be signed with 350 that tsig-key."; 351 } 352 description 353 "A DNS Zone with properties which describe the provisioning 354 relationships within for authoritative nameserver."; 355 } 356 description 357 "The list of DNS Zones for which the properties are defined 358 that describe the primary/secondary relationships."; 359 } 360 } 361 363 4. IANA Considerations 365 This document registers the following namespace URI in the "ns" 366 subregistry of the "IETF XML Registry" [RFC3688]: 368 o URI: urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed- 369 notifications 371 o Registrant Contact: The IESG. 373 o XML: N/A; the requested URI is an XML namespace. 375 This document registers the following YANG module in the "YANG Module 376 Names" registry [RFC6020]: 378 o Name: ietf-restconf-subscribed-notifications 380 o Namespace: urn:ietf:params:xml:ns:yang:ietf-dns-zone-provisioning 382 o Prefix: dnszp 384 o Reference: RFCXXXX 386 5. Security considerations 388 Instances of the data model defined in this document contain 389 sensitive information with which eavesdroppers can interfere in DNS 390 Zone provisioning and potentially even alter DNS Zone content. Care 391 must be taken that instances of this data model are only conveyed 392 over secure authenticated and encrypted channels. 394 6. Acknowledgements 396 Thanks to 398 7. Normative References 400 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 401 DOI 10.17487/RFC1995, August 1996, 402 . 404 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 405 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 406 August 1996, . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 414 Wellington, "Secret Key Transaction Authentication for DNS 415 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 416 . 418 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 419 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 420 . 422 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 423 the Network Configuration Protocol (NETCONF)", RFC 6020, 424 DOI 10.17487/RFC6020, October 2010, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 Authors' Addresses 433 Pieter Lexis 434 PowerDNS 435 Den Haag 436 Netherlands 438 Email: pieter.lexis@powerdns.com 440 Ladislav Lhotka 441 CZ.NIC 442 CZ 444 Email: lhotka@nic.cz 446 Petr Spacek 447 CZ.NIC 448 CZ 450 Email: petr.spacek@nic.cz 452 Ondrej Sury 453 Internet Systems Consortium 454 CZ 456 Email: ondrej@isc.org 458 Willem Toorop 459 NLnet Labs 460 Science Park 400 461 Amsterdam 1098 XH 462 Netherlands 464 Email: willem@nlnetlabs.nl