idnits 2.17.1 draft-wallstrom-dnsop-dns-delegation-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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: 7.8. Glue records in delegation SHOULD exactly match records 8.3. The chain of trust for the delegation MUST be valid . . . 12 8.4. One DS MUST match a least one DNSKEY in the child zone . 12 8.5. The number of NSEC3 iterations must not be higher than 8.6. RRSIG validity period SHOULD NOT be too short nor too 8.7. The name server MUST include RRSIG in all responses to 8.8. The name servers MUST include valid NSEC/NSEC3 record in 9.1. Illegal characters MUST NOT be in the domain name . . . . 14 9.2. Hyphens SHOULD NOT be in position 3 and 4 of the domain 9.5. The SOA RNAME MUST not contain the '@' character . . . . 14 9.8. The MX record in apex MUST point to a valid hostname . . 15 == 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: 9.5. The SOA RNAME MUST not contain the '@' character -- The document date (October 26, 2016) is 2739 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1996' is mentioned on line 511, but not defined == Missing Reference: 'RFC2136' is mentioned on line 511, but not defined ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-02) exists of draft-kristoff-dnsop-dns-tcp-requirements-01 -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP P. Wallstrom 3 Internet-Draft 4 Intended status: Best Current Practice J. Schlyter 5 Expires: April 29, 2017 Kirei AB 6 October 26, 2016 8 DNS Delegation Requirements 9 draft-wallstrom-dnsop-dns-delegation-requirements-03 11 Abstract 13 This document outlines a set of requirements on a well-behaved DNS 14 delegation of a domain name. A large number of tools have been 15 developed to test DNS delegations, but each tool uses a different set 16 of requirements for what is a correct setup for a delegated domain 17 name. However, there are few requirements on how to set up DNS in 18 order to just make the delegation work. In order to have a well- 19 behaved delegation that is robust to failures and also makes DNS 20 resolvers behave consistently, there are a large number of things to 21 consider. 23 Based on this document, it should be possible to set up a fully 24 functional DNS delegation for a domain name, but also to create a set 25 of test specifications for how to test a DNS delegation. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 29, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. DNS Terminology . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 64 2. Basic requirements . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. The domain name MUST be valid . . . . . . . . . . . . . . 5 66 2.2. The domain MUST have a parent domain . . . . . . . . . . 5 67 2.3. The domain MUST have at least one working name server . . 5 68 3. Address requirements . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Name server address MUST be globally routable . . . . . . 5 70 3.2. The IP address of a name server MUST be delegated by IANA 6 71 4. Connectivity requirements . . . . . . . . . . . . . . . . . . 6 72 4.1. All name servers MUST have UDP connectivity over port 53 7 73 4.2. All name servers MUST have TCP connectivity over port 53 7 74 5. Name server requirements . . . . . . . . . . . . . . . . . . 7 75 5.1. Authoritative name servers SHOULD NOT be recursive . . . 7 76 5.2. Name servers SHOULD support EDNS0 . . . . . . . . . . . . 7 77 5.3. Name servers MUST process QNAME case insensitive . . . . 8 78 6. Consistency requirements . . . . . . . . . . . . . . . . . . 8 79 6.1. All name servers SHOULD respond with the same SOA serial 80 number . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.2. All name servers SHOULD respond with the same SOA RNAME . 9 82 6.3. All name servers SHOULD respond with the same SOA 83 parameters . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.4. All name servers MUST respond with the same NS RR Set . . 9 85 7. Delegation requirements . . . . . . . . . . . . . . . . . . . 9 86 7.1. The delegation SHOULD contain at least two name servers . 9 87 7.2. The NS RR set in the parent SHOULD be a subset of the NS 88 RR set in the child . . . . . . . . . . . . . . . . . . . 10 89 7.3. The name servers SHOULD have network path diversity . . . 10 90 7.4. The name servers MUST have distinct IP addresses . . . . 10 91 7.5. The referral SHOULD fit into a non-truncated 512 byte UDP 92 packet . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 7.6. All name servers MUST be authoritative for the domain 94 name . . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 7.7. The delegation name MUST exactly match the apex of the 96 child zone . . . . . . . . . . . . . . . . . . . . . . . 11 98 7.8. Glue records in delegation SHOULD exactly match records 99 in child zone . . . . . . . . . . . . . . . . . . . . . . 11 100 7.9. SOA MNAME SHOULD be authoritative for the zone . . . . . 11 101 8. DNSSEC requirements . . . . . . . . . . . . . . . . . . . . . 12 102 8.1. The DS Digest Type MUST be assigned by IANA . . . . . . . 12 103 8.2. The DNSKEY algorithm MUST be assigned by IANA . . . . . . 12 104 8.3. The chain of trust for the delegation MUST be valid . . . 12 105 8.4. One DS MUST match a least one DNSKEY in the child zone . 12 106 8.5. The number of NSEC3 iterations must not be higher than 107 what is allowed . . . . . . . . . . . . . . . . . . . . . 13 108 8.6. RRSIG validity period SHOULD NOT be too short nor too 109 long . . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 8.7. The name server MUST include RRSIG in all responses to 111 DNSSEC queries . . . . . . . . . . . . . . . . . . . . . 13 112 8.8. The name servers MUST include valid NSEC/NSEC3 record in 113 NXDOMAIN responses . . . . . . . . . . . . . . . . . . . 13 114 9. Syntax requirements . . . . . . . . . . . . . . . . . . . . . 14 115 9.1. Illegal characters MUST NOT be in the domain name . . . . 14 116 9.2. Hyphens SHOULD NOT be in position 3 and 4 of the domain 117 name . . . . . . . . . . . . . . . . . . . . . . . . . . 14 118 9.3. The NS names MUST be valid hostnames . . . . . . . . . . 14 119 9.4. The NS names MUST NOT be an alias . . . . . . . . . . . . 14 120 9.5. The SOA RNAME MUST not contain the '@' character . . . . 14 121 9.6. The SOA RNAME MUST be a legal hostname . . . . . . . . . 15 122 9.7. The SOA MNAME MUST be a legal hostname . . . . . . . . . 15 123 9.8. The MX record in apex MUST point to a valid hostname . . 15 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 125 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 126 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 128 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 129 13.2. Informative References . . . . . . . . . . . . . . . . . 17 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 132 1. Introduction 134 This document outlines a set of requirements on a well-behaved DNS 135 delegation of a domain name. Many domain name registries use a set 136 of requirements on what they may consider a valid delegation. Such 137 requirements can be used to implement tools that are used for pre- or 138 post-delegation checks of the delegations in that registry. 140 To test the quality of the delegation there has been a number of 141 different tools developed, each based on a different set of 142 requirements. This document outlines a set of baseline requirements 143 on a correct setup for a delegated domain name. This document is 144 based on current RFCs and documents requirements that are protocol 145 specific, but also administrative policy requirements drawn from best 146 practices and recommendations. 148 The DNS requirements are split into these different areas, to easier 149 differentiate between what they are for: 151 o Basic 153 o Address 155 o Connectivity 157 o Name server 159 o Consistency 161 o Delegation 163 o DNSSEC 165 o Syntax 167 A secondary name server operator should follow the advice in the BCP 168 document [RFC2182]. 170 Nothing in this document precludes others testing servers for 171 protocol compliance. DNS operators should test their servers to 172 ensure that their vendors have shipped protocol compliant products. 173 Name server vendors can use these tests as a part of this release 174 processes. Registrants can use these tests to check their DNS 175 operators servers. 177 1.1. DNS Terminology 179 This document attempts to fully follow the DNS terminology as defined 180 in [RFC7719]. 182 Many requirements in this document deal with the properties of a name 183 server that is used as part of a delegation, therefore the wording 184 mentioning the use - authoritative or recursive - of a name server as 185 part of this is omitted. 187 1.2. Reserved Words 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 2. Basic requirements 195 The Basic requirements are fundamental to a working DNS delegation. 196 Without these properties, the rest of the requirements are 197 irrelevant. 199 2.1. The domain name MUST be valid 201 The domain name MUST follow the rules defined in Section 2.1 of 202 [RFC1123] in order to be able to map the domain into a DNS packet. A 203 domain name is normally valid if the name has been registered with a 204 domain name registry. 206 Internationalized domain names, [RFC5891], are expected to be encoded 207 using Punycode [RFC3492], thus following the rules outlined in 208 Section 2.3.1 of [RFC1035]. Any validation of the domain name in 209 U-label form is out of scope for this document. 211 2.2. The domain MUST have a parent domain 213 A DNS delegation MUST have a parent domain from which it is 214 delegated. The concept of zone cuts was first described in [RFC1034] 215 and later clarified in Section 6 of [RFC2182]. The only exception is 216 the root zone, which do not have a parent zone. 218 2.3. The domain MUST have at least one working name server 220 A fully working DNS delegation has a parent zone delegating the zone 221 to a set of child name servers. At least one name server MUST be 222 able to answer DNS queries in order to be able to authoritatively 223 serve data for the child zone. 225 3. Address requirements 227 A delegation in the public Internet DNS hierarchy will use the 228 globally unique address space. 230 3.1. Name server address MUST be globally routable 232 In order for the domain and its resources to be accessible from the 233 Internet, authoritative name servers must have addresses in the 234 routable public addressing space. 236 IANA is responsible for global coordination of the IP addressing 237 system. Aside its address allocation activities, it maintains 238 reserved address ranges for special uses. There are two IANA 239 registries for Special-Purpose Addresses, the IANA IPv6 Special- 240 Purpose Address Registry and the IANA IPv4 Special-Purpose Address 241 Registry. 243 [RFC6890] instructs IANA on how to structure the IPv4 and IPv6 244 Special-Purpose Address Registries. The registries 245 [IANA-IPv4-Special] and [IANA-IPv6-Special] are maintained by IANA, 246 and are also described in Section 2.2 and 2.3 of [RFC7249]. 248 A name server MUST NOT be using any IP address within any of these 249 registries that are marked with False in the Global column. 251 3.2. The IP address of a name server MUST be delegated by IANA 253 IP addresses not delegated by IANA MUST NOT be used used by a name 254 server. Thus, IP addresses within a prefix not delegated to a RIR by 255 IANA MUST be rejected. 257 The IANA registry [IANA-IPv6-Unicast] SHOULD be used to determine the 258 status of an IPv6 prefix. Only prefixes with the status ALLOCATED 259 are allowed. 261 The IANA registry [IANA-IPv4-Registry] SHOULD be used to determine 262 the status of an IPv4 prefix. Only prefixes with the status 263 ALLOCATED and LEGACY are allowed. Note that IPv4 LEGACY is not 264 allocated to a RIR. 266 Martians [RFC1208] is a humorous term applied to packets that turn up 267 unexpectedly on the wrong network because of bogus routing entries. 268 Bogons [RFC3871] are packets sourced from addresses that have not yet 269 been allocated by IANA or a RIR, or not delegated to a RIR by IANA as 270 described above. Martians and Bogons SHOULD NOT be used as an 271 addressed used by a name server. 273 4. Connectivity requirements 275 The use of underlying protocols for DNS is described in Section 4.2 276 of [RFC1035]. 278 The Internet supports name server access using TCP on server port 53 279 (decimal) as well as datagram access using UDP on UDP port 53 280 (decimal). Today DNS is used in conjunction with both IPv4 and IPv6, 282 Name servers configured for a zone in a delegation MUST be able to 283 answer queries using the DNS protocol. 285 4.1. All name servers MUST have UDP connectivity over port 53 287 DNS queries are sent using UDP on port 53, as described in 288 Section 4.2.1 of [RFC1035]. A name server MUST respond to DNS 289 queries over UDP for each IP address configured for that name server. 291 4.2. All name servers MUST have TCP connectivity over port 53 293 In addition to UDP, DNS queries can also be sent using TCP on port 294 53, as described in Section 4.2.2 of [RFC1035]. A name server MUST 295 respond to DNS queries over TCP for each IP address configured for 296 that name server. This requirement has also been further clarified 297 in [RFC7766], which makes TCP a REQUIRED part of a full DNS protocol 298 implementation. 300 It should be noted that even though [RFC7766] requires TCP for a DNS 301 protocol implementation, it does not make specific recommendations to 302 operators of DNS servers. However, it also notes that failure to 303 support TCP (or the blocking of DNS over TCP at the network layer) 304 may result in resolution failure and/or application-level timeouts. 305 The operational requirements on DNS Transport over TCP are further 306 discussed [I-D.kristoff-dnsop-dns-tcp-requirements]. 308 5. Name server requirements 310 5.1. Authoritative name servers SHOULD NOT be recursive 312 To ensure consistency in DNS, an authoritative name server SHOULD NOT 313 be configured to do recursive lookups. Also, open recursive 314 resolvers are considered bad Internet practice due to their 315 capability of assisting in large scale DDoS attacks. The 316 introduction to [RFC5358] elaborates on mixing recursor and 317 authoritative functionality. Section 2.5 of [RFC2870] have very 318 specific requirement on disabling recursion functionality on root 319 name servers. 321 5.2. Name servers SHOULD support EDNS0 323 EDNS0 is a mechanism to announce capabilities of a DNS 324 implementation, and is now basically required by any new 325 functionality in DNS such as DNSSEC. Initially standardized in 326 [RFC2671] and later updated by [RFC6891], EDNS0 is a mechanism to 327 announce capabilities of a DNS implementation. 329 5.3. Name servers MUST process QNAME case insensitive 331 The DNS standards require that name servers treat names with case 332 insensitivity. That is, the names example.com and EXAMPLE.COM should 333 resolve to the same IP address. However, in the response, most name 334 servers echo back the name as it appeared in the request, preserving 335 the original case. This is specified in [RFC1034] and [RFC1035], and 336 further clarified by [RFC4343]. 338 Therefore, another way to add entropy to requests is to randomly vary 339 the case of letters in domain names queried. This technique, also 340 known as "0x20" because bit 0x20 is used to set the case of of US- 341 ASCII letters, was first proposed in [I-D.vixie-dnsext-dns0x20], Use 342 of Bit 0x20 in DNS Labels to Improve Transaction Identity. With this 343 technique, the name server response must match not only the query 344 name, but the case of every letter in the name string; for example, 345 wWw.eXaMpLe.CoM or WwW.ExamPLe.COm. This may add little or no 346 entropy to queries for the top-level and root domains, but it's 347 effective for most hostnames. 349 6. Consistency requirements 351 For DNS resolver behaviour to be consistent for a domain, it is 352 important that the authoritative data for the domain to be 353 consistent. All authoritative name servers for a zone should serve 354 the same data, although it should be noted that there exists cases 355 where authoritative name servers are configured to reply with 356 different answers depending on the client source address and/or query 357 options such as EDNS0 client subnet option as specified in [RFC7871]. 359 An indicator of inconsistency is that infrastructure records (e.g., 360 SOA and NS) differs between the authoritative name servers. 362 Section 4.6 in [RFC4786] advices that data synchronisation in an 363 anycast setup should be done in a manner so that anycast nodes 364 operate in a consistent manner. 366 6.1. All name servers SHOULD respond with the same SOA serial number 368 An indication that not all authoritative name servers have a 369 consistent and updated copy of the zone is that the serial numbers 370 differ. When querying for the SOA RR all name servers SHOULD respond 371 with the same SOA serial number. 373 Section 4.3.5 in [RFC1034] explains the typical function of the 374 serial numbers in zone maintenance and transfers. 376 One should note that even though different SOA serial numbers are a 377 strong indicator of an inconsistent setup, there are several 378 scenarios where the serial number varies between name servers. One 379 example is a zone with frequent updates to zone data, where 380 propagation delay between the name servers may result in limited 381 inconsistency. 383 6.2. All name servers SHOULD respond with the same SOA RNAME 385 As per Section 3.3.13 of [RFC1035], the RNAME field in the SOA RDATA 386 refers to the mailbox of the person responsible for the zone. An 387 indication that not all authoritative name servers have a consistent 388 and updated copy of the zone is that the RNAME differs. When 389 querying for the SOA RR all name servers SHOULD respond with the same 390 SOA RNAME. 392 6.3. All name servers SHOULD respond with the same SOA parameters 394 The inconsistency of the SOA parameters REFRESH, RETRY, EXPIRE and 395 MINIMUM, defined in Section 3.3.13 of [RFC1035], might lead to 396 operational problems for the zone. These SOA parameters SHOULD be 397 consistent for all authoritative name servers for the zone. 399 6.4. All name servers MUST respond with the same NS RR Set 401 All authoritative name servers MUST serve the same NS record set in 402 order to ensure consistency in the zone cut as described in 403 Section 4.2.2 of [![RFC1034]]. Any inconsistency of NS records 404 described in Section 3.3.11 of RFC 1035 might result in operational 405 failures. 407 7. Delegation requirements 409 [RFC2182] is a BCP on how to select and operate secondary name 410 servers, and summarize many operational issues with the delegation of 411 a zone. For a delegation to work continuously if one component 412 fails, there are operational considerations to ensure this. 414 Section 4.2.2 [RFC1034] also adds that the administraters of both the 415 parent and child zone should ensure that NS and glue RRs on both 416 sides of the zone cut are consistent. 418 7.1. The delegation SHOULD contain at least two name servers 420 Section 4.1 [RFC1034] states that by administrative fiat we require 421 every zone to be available on at least two name servers. Section 5 422 of [RFC2182] that answers the question on how many name servers are 423 needed, the recommendation is that "three servers be provided for 424 most organisation level zones, with at least one which must be well 425 removed from the others." 427 In order to avoid any operational problems, a delegation SHOULD 428 contain at least two (2) authoritative name servers. 430 7.2. The NS RR set in the parent SHOULD be a subset of the NS RR set in 431 the child 433 As per the name resolving algorithm described in [RFC1034] the NS RR 434 in the child zone is authoritative for the zone, and any delegation 435 hints in the parent are discarded in the resolving process. The NS 436 RR set in the parent zone SHOULD be a subset of the NS RR set in the 437 child zone. 439 7.3. The name servers SHOULD have network path diversity 441 [RFC2182], Section 3.1 states that distinct authoritative name 442 servers for a child domain should be placed in different topological 443 and geographical locations. The objective is to minimise the 444 likelihood of a single failure disabling all of them. Further 445 support for this is given in Section 5: 447 It is recommended that three servers be provided for most 448 organisation level zones, with at least one which must be well 449 removed from the others. 451 To avoid any single point of failure in networking, the name servers 452 SHOULD exhibit network path diversity. Using current routing 453 technology, this means that all name servers SHOULD NOT be placed 454 within a single routing domain, or AS (autonomous system). 456 7.4. The name servers MUST have distinct IP addresses 458 A common workaround to a registry policy that requires at least two 459 name servers is to create two (2) names with the same IP address. 461 To avoid any operational errors and workaround such as this, all name 462 servers used for the zone MUST use distinct IP addresses. 464 7.5. The referral SHOULD fit into a non-truncated 512 byte UDP packet 466 The DNS still defaults to using UDP, although efforts into requiring 467 or transitioning to use TCP have come a long way. The UDP packet 468 limit is 512 bytes, and although the EDNS0 [RFC6891] extension 469 mechanism to overcome this limit have been in use for a very long 470 time, many middleboxes and proxies still interfere with DNS packets 471 ([RFC5625]). 473 To avoid any such problems with the delegation, and to avoid any 474 unexpected truncation of a referral response, the referral containing 475 the delegation from the parent SHOULD fit within 512 bytes. 477 7.6. All name servers MUST be authoritative for the domain name 479 A name server that does not answer authoritatively for the zone is a 480 clear sign of misconfiguration, and is a common cause for operational 481 problems. 483 Section 6.1 of [RFC2181] mandates that the name servers MUST answer 484 authoritatively for the zone. 486 7.7. The delegation name MUST exactly match the apex of the child zone 488 The configured zone on the child name servers MUST match the 489 delegated name of the zone. When querying the child name servers for 490 the zone, any authoritative data for another name MUST NOT be in the 491 response. 493 [RFC2181] states that the SOA RR and the NS RR indicates the origin 494 of the zone, and both are mandatory records in a zone. Both RRs MUST 495 be present and match the name of the zone. 497 7.8. Glue records in delegation SHOULD exactly match records in child 498 zone 500 In-bailiwick glue for name servers listed at the parent SHOULD match 501 the in-bailiwick glue for the name servers in the child. 503 If the glue address mismatch between the parent zone and the child, 504 this is a strong indication of configuration error. 506 7.9. SOA MNAME SHOULD be authoritative for the zone 508 The hostname of the MNAME field may or may not be listed among the 509 delegated name servers, but SHOULD still be authoritative for the 510 zone. MNAME may be used for other services, e.g., DNS NOTIFY 511 [RFC1996] and DNS Dynamic Updates [RFC2136]. 513 It should be noted that there are no formal requirement that the name 514 server listed in the SOA MNAME is reachable from the public Internet. 515 Because of this, it may be difficult to implement a reasonable test 516 for this requirement. 518 8. DNSSEC requirements 520 If DNSSEC is used for the zone, either by indicating that the zone is 521 signed with a DS record, or the use of a DNSKEY in the zone itself, a 522 number of things are required for a fully functional delegation. 524 The Domain Name System Security Extensions (DNSSEC) add data origin 525 authentication and data integrity to the Domain Name System, and was 526 first introduced with the RFCs [RFC4033], [RFC4034] and [RFC4035]. 527 The are also a number of additions to DNSSEC such as NSEC3 described 528 in [RFC5155], and a number of algorithms to the cryptographic 529 functions. 531 8.1. The DS Digest Type MUST be assigned by IANA 533 The The Digest Type Field is defined as part of the DS RDATA Wire 534 Format of Section 5.1.3 in [RFC4034]. The appendix A.2 defines the 535 initial set of digest algorithm types with possible future 536 algorithms. The IANA registry for DS Digest Types [IANA-DNSSEC-DS] 537 was defined by [RFC3658]. 539 Any DS Digest Type used for a zone MUST be assigned by IANA. 541 8.2. The DNSKEY algorithm MUST be assigned by IANA 543 The DNSKEY RR is defined in Section 2 of [RFC4034] as part of the 544 DNSKEY RDATA Wire Format. The appendix A.1 defines the initial list 545 of DNSKEY Algorithm Types. The IANA Registry for DNSKEY Algorithm 546 Types [IANA-DNSSEC-DNSKEY] was created with [RFC3755]. 548 Any DNSKEY algorithm number used for in a zone MUST be assigned by 549 IANA. 551 8.3. The chain of trust for the delegation MUST be valid 553 A valid authentication chain from the parent DS, as described in 554 Section 3.1 of [RFC4033], MUST exist for the SOA, DNSKEY and NS 555 records of the child zone if a DS record is published in the parent 556 zone. 558 8.4. One DS MUST match a least one DNSKEY in the child zone 560 DNS delegations from a parent to a child are secured with DNSSEC by 561 publishing one or several Delegation Signer (DS) resource records in 562 the parent zone, along with the NS records for the delegation. 564 As stated in Section 2.4 of [RFC4035], a DS RR SHOULD point to a 565 DNSKEY RR that is present in the child's apex DNSKEY RRset. If there 566 is a DS RR published at the parent, there MUST be at least one DNSKEY 567 RR in the child zone that matches at least one DS RR for every 568 signature algorithm, otherwise the authentication of the referral 569 will fail, as described in Section 5.2 of [RFC4035]. 571 For each unique algorithm from the DS RRs present, there MUST be a 572 matching DNSKEY using that algorithm in use in the child. 574 8.5. The number of NSEC3 iterations must not be higher than what is 575 allowed 577 Section 10.3 of [RFC5155] specifies the max number of NSEC3 578 iterations allowed for different key sizes. This requirement is 579 enforced by several resolver implementations. 581 The number of NSEC3 iterations MUST NOT be higher than what is 582 allowed by Section 10.3 of [RFC5155]. It should be noted that the 583 values in the table MUST be used independent of the key algorithm. 585 8.6. RRSIG validity period SHOULD NOT be too short nor too long 587 [RFC6781] describes operational considerations on the choice of 588 validity periods for RRSIGs. Having too short validity periods might 589 cause operational failure in case of unexpected events, but is good 590 for protecting against replay attacks. Having too long validity 591 periods may be good for operational security, but opens up for replay 592 attacks. 594 The RRSIG validity periods in the zone SHOULD NOT be too short nor 595 too long. 597 8.7. The name server MUST include RRSIG in all responses to DNSSEC 598 queries 600 If the zone is signed, the name servers MUST be able to include RRSIG 601 RRs as additional data in any response when the query has the DO bit 602 set, as described in Section 3.1.1 of [RFC4035]. 604 8.8. The name servers MUST include valid NSEC/NSEC3 record in NXDOMAIN 605 responses 607 If the zone is signed, the name servers MUST be able to include NSEC/ 608 NSEC3 RRs as additional data in any response when the query has the 609 DO bit set, as described in Section 3.1.1 of [RFC4035]. 611 9. Syntax requirements 613 All domain- and host names in DNS MUST follow the rules outlined in 614 Section 2.3.1 of [RFC1035]. The Name Syntax and LDH Label have been 615 further clarified in Section 11 in [RFC2181] and Section 2.3.1 in 616 [RFC5890]. From this follow the requirements below. 618 9.1. Illegal characters MUST NOT be in the domain name 620 There MUST NOT be any illegal characters used in the domain name. 621 The domain name MUST follow the rules defined in Section 2.3.1 of 622 [RFC1035], Section 2.1 of [RFC1123], Section 11 of [RFC2182] and 623 Section 2 of [RFC3696]. 625 9.2. Hyphens SHOULD NOT be in position 3 and 4 of the domain name 627 The effort of internationalization of domain names and the 628 development of IDNA brought us the extension mechanism of using the 629 string 'xn--' to have a special meaning. To allow future extensions 630 to DNS there SHOULD be no instances of labels in the DNS that start 631 with two characters, followed by two hyphens, where the two 632 characters are not "xn". This has been described in Section 5 of 633 [RFC3696]. 635 9.3. The NS names MUST be valid hostnames 637 The Name Server name MUST be a valid hostname according to the rules 638 defined in Section 2.3.1 of [RFC1035], in Section 2.1 in [RFC1123], 639 Section 11 in [RFC2181] and Section 2 and 5 in [RFC3696]. 641 9.4. The NS names MUST NOT be an alias 643 As specified in Section 10.3 of [RFC2181], the Name Server name MUST 644 NOT be an alias (CNAME). 646 9.5. The SOA RNAME MUST not contain the '@' character 648 The SOA RNAME field is a mailbox address defined in Section 3.3 of 649 [RFC1034] and Section 2.2 of [RFC1912]. The RNAME field MUST follow 650 the rules of an e-mail address defined in Section 3.4.1 of [RFC2822], 651 and the '@' character MUST be changed so that the whole e-mail 652 address is converted into a single domain name as described in 653 Section 3.3 of [RFC1034] and Section 2.1 of [RFC1123]. 655 9.6. The SOA RNAME MUST be a legal hostname 657 The SOA RNAME field is a mailbox address. The SOA RNAME field is 658 defined in Section 3.3 of [RFC1034] and Section 2.2 of [RFC1912]. As 659 a field containing a domain name, the content of the RNAME field MUST 660 follow the rules outlined in Section 2.3.1 of [RFC1035] and 661 Section 2.1 of [RFC1123]. 663 9.7. The SOA MNAME MUST be a legal hostname 665 The SOA MNAME field is a hostname. The SOA MNAME field is defined in 666 Section 3.3.13 of [RFC1035]. As a field containing a domain name, 667 the content of the RNAME field MUST follow the rules outlined in 668 Section 2.3.1 of [RFC1035]. 670 Furthermore, Section 7.3 in [RFC2181] makes it clear that the SOA 671 MNAME field SHOULD NOT be the name of the zone itself. 673 9.8. The MX record in apex MUST point to a valid hostname 675 The requirement on the existence of an MX RR in the apex of the child 676 zone may vary by policy from different parent zones. However, it is 677 strongly recommended in Section 7 of [RFC2142] that all domains 678 should have a mailbox named hostmaster@domain. SMTP can make a 679 delivery without the MX, using the A or AAAA record as specified in 680 Section 5.1 of [RFC5321]. 682 If an MX RR exists in the apex of the child zone, the hostname that 683 the MX RR points to MUST follow the rules outlined in Section 2.3.1 684 of [RFC1035] and Section 2.1 of [RFC1123]. 686 10. Security Considerations 688 This document has no security considerations (yet). 690 11. IANA Considerations 692 This document has no IANA actions. 694 12. Acknowledgements 696 The requirements documented in this document were developed within 697 the CENTR Test Requirements Task Force (TRTF). Most of the original 698 requirements and text come from the Zonemaster project. 700 13. References 702 13.1. Normative References 704 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 705 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 706 . 708 [RFC1035] Mockapetris, P., "Domain names - implementation and 709 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 710 November 1987, . 712 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 713 Application and Support", STD 3, RFC 1123, 714 DOI 10.17487/RFC1123, October 1989, 715 . 717 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 718 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 719 . 721 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 722 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 723 DOI 10.17487/RFC2182, July 1997, 724 . 726 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 727 DOI 10.17487/RFC2822, April 2001, 728 . 730 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 731 Rose, "Protocol Modifications for the DNS Security 732 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 733 . 735 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 736 Insensitivity Clarification", RFC 4343, 737 DOI 10.17487/RFC4343, January 2006, 738 . 740 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 741 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 742 2015, . 744 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 745 D. Wessels, "DNS Transport over TCP - Implementation 746 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 747 . 749 13.2. Informative References 751 [I-D.kristoff-dnsop-dns-tcp-requirements] 752 Kristoff, J., "DNS Transport over TCP - Operational 753 Requirements", draft-kristoff-dnsop-dns-tcp- 754 requirements-01 (work in progress), August 2016. 756 [I-D.vixie-dnsext-dns0x20] 757 Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to 758 Improve Transaction Identity", draft-vixie-dnsext- 759 dns0x20-00 (work in progress), March 2008. 761 [IANA-DNSSEC-DNSKEY] 762 IANA, "Domain Name System Security (DNSSEC) Algorithm 763 Numbers", November 2003, 764 . 767 [IANA-DNSSEC-DS] 768 IANA, "Delegation Signer (DS) Resource Record (RR) Type 769 Digest Algorithms", Oktober 2003, 770 . 773 [IANA-IPv4-Registry] 774 IANA, "IANA IPv4 Address Space Registry", August 2015, 775 . 777 [IANA-IPv4-Special] 778 IANA, "IANA IPv4 Special-Purpose Address Registry", 779 January 2006, . 782 [IANA-IPv6-Special] 783 IANA, "IANA IPv6 Special-Purpose Address Registry", 784 January 2006, . 787 [IANA-IPv6-Unicast] 788 IANA, "IPv6 Global Unicast Address Assignments", October 789 2015, . 792 [RFC1208] Jacobsen, O. and D. Lynch, "A Glossary of Networking 793 Terms", RFC 1208, DOI 10.17487/RFC1208, March 1991, 794 . 796 [RFC1912] Barr, D., "Common DNS Operational and Configuration 797 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, 798 . 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, 802 DOI 10.17487/RFC2119, March 1997, 803 . 805 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 806 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 807 . 809 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 810 RFC 2671, DOI 10.17487/RFC2671, August 1999, 811 . 813 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 814 Name Server Operational Requirements", RFC 2870, 815 DOI 10.17487/RFC2870, June 2000, 816 . 818 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 819 for Internationalized Domain Names in Applications 820 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 821 . 823 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 824 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 825 . 827 [RFC3696] Klensin, J., "Application Techniques for Checking and 828 Transformation of Names", RFC 3696, DOI 10.17487/RFC3696, 829 February 2004, . 831 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 832 Signer (DS)", RFC 3755, DOI 10.17487/RFC3755, May 2004, 833 . 835 [RFC3871] Jones, G., Ed., "Operational Security Requirements for 836 Large Internet Service Provider (ISP) IP Network 837 Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September 838 2004, . 840 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 841 Rose, "DNS Security Introduction and Requirements", 842 RFC 4033, DOI 10.17487/RFC4033, March 2005, 843 . 845 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 846 Rose, "Resource Records for the DNS Security Extensions", 847 RFC 4034, DOI 10.17487/RFC4034, March 2005, 848 . 850 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 851 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 852 December 2006, . 854 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 855 Security (DNSSEC) Hashed Authenticated Denial of 856 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 857 . 859 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 860 DOI 10.17487/RFC5321, October 2008, 861 . 863 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 864 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 865 DOI 10.17487/RFC5358, October 2008, 866 . 868 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 869 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 870 . 872 [RFC5890] Klensin, J., "Internationalized Domain Names for 873 Applications (IDNA): Definitions and Document Framework", 874 RFC 5890, DOI 10.17487/RFC5890, August 2010, 875 . 877 [RFC5891] Klensin, J., "Internationalized Domain Names in 878 Applications (IDNA): Protocol", RFC 5891, 879 DOI 10.17487/RFC5891, August 2010, 880 . 882 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 883 Operational Practices, Version 2", RFC 6781, 884 DOI 10.17487/RFC6781, December 2012, 885 . 887 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 888 "Special-Purpose IP Address Registries", BCP 153, 889 RFC 6890, DOI 10.17487/RFC6890, April 2013, 890 . 892 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 893 for DNS (EDNS(0))", STD 75, RFC 6891, 894 DOI 10.17487/RFC6891, April 2013, 895 . 897 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, 898 DOI 10.17487/RFC7249, May 2014, 899 . 901 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 902 Kumari, "Client Subnet in DNS Queries", RFC 7871, 903 DOI 10.17487/RFC7871, May 2016, 904 . 906 Authors' Addresses 908 Patrik Wallstrom 910 Email: pawal@blipp.com 912 Jakob Schlyter 913 Kirei AB 915 Email: jakob@kirei.se