| < draft-wallstrom-dnsop-dns-delegation-requirements-02.txt | draft-wallstrom-dnsop-dns-delegation-requirements-03.txt > | |||
|---|---|---|---|---|
| DNSOP P. Wallstrom | DNSOP P. Wallstrom | |||
| Internet-Draft | Internet-Draft | |||
| Intended status: Best Current Practice J. Schlyter | Intended status: Best Current Practice J. Schlyter | |||
| Expires: March 23, 2017 Kirei AB | Expires: April 29, 2017 Kirei AB | |||
| September 19, 2016 | October 26, 2016 | |||
| DNS Delegation Requirements | DNS Delegation Requirements | |||
| draft-wallstrom-dnsop-dns-delegation-requirements-02 | draft-wallstrom-dnsop-dns-delegation-requirements-03 | |||
| Abstract | Abstract | |||
| This document outlines a set of requirements on a well-behaved DNS | This document outlines a set of requirements on a well-behaved DNS | |||
| delegation of a domain name. A large number of tools have been | delegation of a domain name. A large number of tools have been | |||
| developed to test DNS delegations, but each tool uses a different set | developed to test DNS delegations, but each tool uses a different set | |||
| of requirements for what is a correct setup for a delegated domain | of requirements for what is a correct setup for a delegated domain | |||
| name. However, there are few requirements on how to set up DNS in | name. However, there are few requirements on how to set up DNS in | |||
| order to just make the delegation work. In order to have a well- | order to just make the delegation work. In order to have a well- | |||
| behaved delegation that is robust to failures and also makes DNS | behaved delegation that is robust to failures and also makes DNS | |||
| skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 23, 2017. | This Internet-Draft will expire on April 29, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 32 ¶ | skipping to change at page 2, line 32 ¶ | |||
| 2.2. The domain MUST have a parent domain . . . . . . . . . . 5 | 2.2. The domain MUST have a parent domain . . . . . . . . . . 5 | |||
| 2.3. The domain MUST have at least one working name server . . 5 | 2.3. The domain MUST have at least one working name server . . 5 | |||
| 3. Address requirements . . . . . . . . . . . . . . . . . . . . 5 | 3. Address requirements . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. Name server address MUST be globally routable . . . . . . 5 | 3.1. Name server address MUST be globally routable . . . . . . 5 | |||
| 3.2. The IP address of a name server MUST be delegated by IANA 6 | 3.2. The IP address of a name server MUST be delegated by IANA 6 | |||
| 4. Connectivity requirements . . . . . . . . . . . . . . . . . . 6 | 4. Connectivity requirements . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1. All name servers MUST have UDP connectivity over port 53 7 | 4.1. All name servers MUST have UDP connectivity over port 53 7 | |||
| 4.2. All name servers MUST have TCP connectivity over port 53 7 | 4.2. All name servers MUST have TCP connectivity over port 53 7 | |||
| 5. Name server requirements . . . . . . . . . . . . . . . . . . 7 | 5. Name server requirements . . . . . . . . . . . . . . . . . . 7 | |||
| 5.1. Authoritative name servers SHOULD NOT be recursive . . . 7 | 5.1. Authoritative name servers SHOULD NOT be recursive . . . 7 | |||
| 5.2. Name servers SHOULD support ENS0 . . . . . . . . . . . . 7 | 5.2. Name servers SHOULD support EDNS0 . . . . . . . . . . . . 7 | |||
| 5.3. Name servers MUST process QNAME case insensitive . . . . 8 | 5.3. Name servers MUST process QNAME case insensitive . . . . 8 | |||
| 6. Consistency requirements . . . . . . . . . . . . . . . . . . 8 | 6. Consistency requirements . . . . . . . . . . . . . . . . . . 8 | |||
| 6.1. All name servers SHOULD respond with the same SOA serial | 6.1. All name servers SHOULD respond with the same SOA serial | |||
| number . . . . . . . . . . . . . . . . . . . . . . . . . 8 | number . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 6.2. All name servers SHOULD respond with the same SOA RNAME . 9 | 6.2. All name servers SHOULD respond with the same SOA RNAME . 9 | |||
| 6.3. All name servers SHOULD respond with the same SOA | 6.3. All name servers SHOULD respond with the same SOA | |||
| parameters . . . . . . . . . . . . . . . . . . . . . . . 9 | parameters . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 6.4. All name servers MUST respond with the same NS RR Set . . 9 | 6.4. All name servers MUST respond with the same NS RR Set . . 9 | |||
| 7. Delegation requirements . . . . . . . . . . . . . . . . . . . 9 | 7. Delegation requirements . . . . . . . . . . . . . . . . . . . 9 | |||
| 7.1. The delegation SHOULD contain at least two name servers . 9 | 7.1. The delegation SHOULD contain at least two name servers . 9 | |||
| skipping to change at page 7, line 41 ¶ | skipping to change at page 7, line 41 ¶ | |||
| To ensure consistency in DNS, an authoritative name server SHOULD NOT | To ensure consistency in DNS, an authoritative name server SHOULD NOT | |||
| be configured to do recursive lookups. Also, open recursive | be configured to do recursive lookups. Also, open recursive | |||
| resolvers are considered bad Internet practice due to their | resolvers are considered bad Internet practice due to their | |||
| capability of assisting in large scale DDoS attacks. The | capability of assisting in large scale DDoS attacks. The | |||
| introduction to [RFC5358] elaborates on mixing recursor and | introduction to [RFC5358] elaborates on mixing recursor and | |||
| authoritative functionality. Section 2.5 of [RFC2870] have very | authoritative functionality. Section 2.5 of [RFC2870] have very | |||
| specific requirement on disabling recursion functionality on root | specific requirement on disabling recursion functionality on root | |||
| name servers. | name servers. | |||
| 5.2. Name servers SHOULD support ENS0 | 5.2. Name servers SHOULD support EDNS0 | |||
| EDNS0 is a mechanism to announce capabilities of a DNS | EDNS0 is a mechanism to announce capabilities of a DNS | |||
| implementation, and is now basically required by any new | implementation, and is now basically required by any new | |||
| functionality in DNS such as DNSSEC. Initially standardized in | functionality in DNS such as DNSSEC. Initially standardized in | |||
| [RFC2671] and later updated by [RFC6891], EDNS0 is a mechanism to | [RFC2671] and later updated by [RFC6891], EDNS0 is a mechanism to | |||
| announce capabilities of a DNS implementation. | announce capabilities of a DNS implementation. | |||
| 5.3. Name servers MUST process QNAME case insensitive | 5.3. Name servers MUST process QNAME case insensitive | |||
| The DNS standards require that name servers treat names with case | The DNS standards require that name servers treat names with case | |||
| End of changes. 5 change blocks. | ||||
| 6 lines changed or deleted | 6 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||