2. Nameserver Predelegation Check
2.1 The New Warning and Error Messages Issued in the Course of the Name server Predelegation Checks (Name Server Policy)
Obligatory requirements are described using the word "must" or "must not". Infringements of such rules trigger an ERROR message.
Recommendations are described using the word "should". Infringements of such rules trigger a WARNING message.
2.1.1 General Requirement
All name servers stated in the request must be reachable and authoritative for the requested zone [if not, output of ERROR message].
Explanation: Since the operator of the name server may not be identical with the domain holder nor the adminstrating DENIC member and is thus no contractual partner of DENIC, and since a delegation is to his/her disadvantage, this rule shall ensure that the delegation can be considered approved by the name server, if the zone is served authoritatively. In the remaining aspects, the predelegation check corresponds with the spirit and the text of the RFCs 1034 and 1035.
2.1.2 Redundant Connection
1. One prerequisite for delegation is the existence of at least two name servers. At least one of them must be connected via IPv4. To carry out the further steps of the check, all IPv4 and IPv6 addresses of each name server are identified or, if feasible, deduced from the request. The request must contain at least one name server with an IP address that differs from all other name servers of the same request [if not, output of ERROR message].
Explanation: RFC 1035 expressly requires that all DNS zones are redundantly supported by at least two independent name servers. To avoid negative effects on the TLD servers (see RFC 4697) if one of the name servers of the delegated zone cannot be reached, particular importance is attached to diversity of network topology.
Example:
permitted:
a. name server 1 with the IP adress 192.0.2.1 and name server 2 with the IP address 198.51.100.1
b. name server 1 with the IP adress 192.0.2.1 and name server 2 with the IP address 2001:db8:85a3::8a2e:370:7334
not permitted:
c. name server 1 with the IP adress 192.0.2.1 and name server 2 with the IP address 192.0.2.1
d. name server 1 with the IP adress 2001:db8:85a3::8a2e:370:7334 and name server 2 with the IP address 2001:db8:85a3::8a2e:370:7336
2.1.3 Glue Records
1. In principle, the Narrow Glue Policy shall apply: Glue records are entered in the .de or 9.4.164.arpa zone if and only if the name of a name server is definitely located within the delegated domain.
a. If the name server is located in the domain to be delegated, at least one IPv4 or IPv6 address must be stated (A-/AAAA-RRSet) [if not, output of ERROR message].
Explanation: The stated constallation requires at least one glue record.
b. If the name server is not located in the domain to be delegated, but the request still contains at least one IP address (v4 or v6) of that server, this IP address will not be taken into consideration for the request [output of WARNING message].
Explanation: DENIC applies the Narrow Glue Policy for both .de and 9.4.e164.arpa, i.e. it accepts glue records only under specific, very restricted conditions, to be precise, if the name server is located within the delegated zone. Possibly stated additional addresses are superfluous and will not be considered. The warning message shall draw the attention to potential input errors.
2. The A- and AAAA-RRSet of a name server must be directly, fully, consistently and authoritatively ascertainable via every IP address (v4 or v6) stated in the request, and the sets must be identical with the data of the request [if not, output of ERROR message].
Explanation: Since glue data co-exist with the authoritative data, it must be ensured that they are consistent, i.e. that the address data in the glue records are identical with the authoritative address data that have been determined by the “standard way”. Moreover, the rule of consistency requires that RRSets (Record Sets, i.e. one or several records of the same type) are always stated in full. That means, for example, that you cannot state only one or two addresses of a name server for the glue records but must include all of them. Last but not least the “Narrow Glue Policy” applies to IPv4 as well as to IPV6 addresses, i.e. if corresponding record sets (A or AAAA) exist in the authotitative data, they must be made availlable in glue records.
2.1.4 Requirements Concerning the SOA Data in the Zone
1. Obsolet: The SOA serial number on all name server zones should tally [if not, output of WARNING message].
2. For the following SOA values, guideline values are specified:
a. "Refresh" should be within the following range: 3600 – 86400 (in seconds) [if not, output of WARNING message].
Explanation: This value determines the frequency of data reconciliation of the secondary name servers and the primary master. Lower values generate
increased DNS traffic and boost the load of the systems involved, higher values may have a negative impact on the up-to-dateness of the data. Since the
values must finally be agreed by the operators and the participating name servers, a warning is issued only if the chosen value falls short of or exceeds
the "standard" values.
b. "Retry" should be within the following range: 900 – 28800 (in seconds) [if not, output of WARNING message].
Explanation: This value replaces the value stated under "Refresh" after the first unsuccessful attempt until either successful reconciliation is made or the
"Expire" value is reached. So the value must be below the "Refresh" value. It must be taken into consideration, however, that too small a value may cause
load peaks and will trigger a warning message.
c. The "Retry" value should be 1/8 and 1/3 of the "Refresh" value [if not, output of WARNING message].
Explanation: This ensures that the relation between the "Refresh" and the "Retry" value is appropriate for the changeover logic to bring about a
noteworthy advantage.
d. "Expire" should be within the following range: 604800 – 3600000 (in seconds) [if not, output of WARNING message].
Explanation: This value defines the period of unsuccesful reconciliation attemps until a slave stops to further support the zone. Values below one week are very problematic because they may lead to the loss of all authoritative name servers of a zone within a short period, so that the zone remains completely paralyzed due to delegation. 1,000 hours as an upper limit is a frequently used value. If this limit is exceeded, a severe reconciliation problem must be assumed, which should not be ignored.
e. "negTTL" must/should be within the following range: 180 - 86400 (in seconds) [if not, a WARNING message is issued].
Explanation: Together with the TTL of the SOA record, this value determines the useful life of negative replies pursuant to RFC 2308. Values that are two high (in this case more than one day) do not noticeably reduce the DNS traffic and/or are curtailed by DNS caches, anyway. So they would be inefficient. Values that are too low (in this case less than three minutes) finally lead to a complete shut down of the "negative caching", which is meant to be avoided.
2.1.5 Requirements Concerning the Further Data in the Zone
1. The NS-RRSet must correspond exactly to the list of name servers stated with the request [if not, output of ERROR message].
Explanation: RFC 1034 stipulates that the authoritative name server data used in the delegating and the delegated zone must be identical.
2. The existence of a CNAME-RR is not permitted for the requested zone (more precise: at the zone apex) [if not, output of ERROR message].
Explanation: One and the same node in the DNS tree must not have any additional record types besides the CNAME record. Since a delegated zone requires at least the SOA record and the NS records, the existence of a CNAME record would represent an infringement of the protocol.
3. The referral response (assuming a QNAME of up to 191 Bytes length and counting all required address data, including glue records) must fit into an DNS-UDP package, i.e. must not exceed 512 bytes [if not, output of ERROR message].
Explanation: The name server of DENIC answers requests for data in delegated zones with a reference to the actually responsible name server on the next hierarchical level. Standard UDP packages allow a useful load of 512 bytes at maximum. To avoid that the answers are curtailed and the question is then resubmitted via TCP, thus leading to a disproportionate workload of the DENIC name server, the above mentioned length restriction is introduced. Since the space consumed is determined by the length of the name server names and their compressibility as well as by the number of the glue records, this calculation method is safer than specifying a maximum limit for the number of name servers.
4. The primary name server stated for the SOA-RR of the requestes zone should be identical on all name servers [if not, output of WARNING message].
Explanation: This is an additional means to verify the consistency addressed under 2.1.4 , paragraph 1.
2.1.6 Other Defaults for the Name Servers
1. IPv6 addresses must originate in an address space that is marked as Global Unicast and as ALLOCATED and routable. This applies for all IPv6 addresses of the stated name servers, regardless of the fact whether the address is a glue record or not [if not, output of ERROR message].
Explanation: IPv6 knows various validity ranges for addresses ("Scoping"). To make the check results unambiguous and comprehensible and to secure uniform accessibility of the name servers throughout the world, only those addresses are accepted that are globally unambigous.
2. Recursive request should not be permitted [if not, output of WARNING message].
Explanation: For safety reasons and to ensure a correct view on the namespace, authoritative and recursive name servers are strictly separated in the operational praxis.
3. Reachability via TCP should be guaranteed [if not, output of WARNING message].
Explanation: RFC 1034 and 1035 specify for DNSs the use of UDP as well as of TCP transport, with UDP having priority and being used for the major share of the data traffic. Under certain circumstances (e.g. response size) a resolver may have to switch to TCP, which is expressly supported by RFC 1123.