DNS Delegation Requirements
draft-wallstrom-dnsop-dns-delegation-requirements-03

Document Type Active Internet-Draft (dnsop WG)
Last updated 2016-11-14 (latest revision 2016-10-26)
Stream IETF
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream WG state Candidate for WG Adoption
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
DNSOP                                                       P. Wallstrom
Internet-Draft
Intended status: Best Current Practice                       J. Schlyter
Expires: April 29, 2017                                         Kirei AB
                                                        October 26, 2016

                      DNS Delegation Requirements
          draft-wallstrom-dnsop-dns-delegation-requirements-03

Abstract

   This document outlines a set of requirements on a well-behaved DNS
   delegation of a domain name.  A large number of tools have been
   developed to test DNS delegations, but each tool uses a different set
   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
   order to just make the delegation work.  In order to have a well-
   behaved delegation that is robust to failures and also makes DNS
   resolvers behave consistently, there are a large number of things to
   consider.

   Based on this document, it should be possible to set up a fully
   functional DNS delegation for a domain name, but also to create a set
   of test specifications for how to test a DNS delegation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 29, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Wallstrom & Schlyter     Expires April 29, 2017                 [Page 1]
Internet-Draft         DNS Delegation Requirements          October 2016

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  DNS Terminology . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Reserved Words  . . . . . . . . . . . . . . . . . . . . .   4
   2.  Basic requirements  . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  The domain name MUST be valid . . . . . . . . . . . . . .   5
     2.2.  The domain MUST have a parent domain  . . . . . . . . . .   5
     2.3.  The domain MUST have at least one working name server . .   5
   3.  Address requirements  . . . . . . . . . . . . . . . . . . . .   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
   4.  Connectivity requirements . . . . . . . . . . . . . . . . . .   6
     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
   5.  Name server requirements  . . . . . . . . . . . . . . . . . .   7
     5.1.  Authoritative name servers SHOULD NOT be recursive  . . .   7
     5.2.  Name servers SHOULD support EDNS0 . . . . . . . . . . . .   7
     5.3.  Name servers MUST process QNAME case insensitive  . . . .   8
   6.  Consistency requirements  . . . . . . . . . . . . . . . . . .   8
     6.1.  All name servers SHOULD respond with the same SOA serial
           number  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  All name servers SHOULD respond with the same SOA RNAME .   9
     6.3.  All name servers SHOULD respond with the same SOA
           parameters  . . . . . . . . . . . . . . . . . . . . . . .   9
     6.4.  All name servers MUST respond with the same NS RR Set . .   9
   7.  Delegation requirements . . . . . . . . . . . . . . . . . . .   9
     7.1.  The delegation SHOULD contain at least two name servers .   9
     7.2.  The NS RR set in the parent SHOULD be a subset of the NS
           RR set in the child . . . . . . . . . . . . . . . . . . .  10
     7.3.  The name servers SHOULD have network path diversity . . .  10
Show full document text