Name Server and NSentry Data

Nameserver and NSentry Data

There are two ways to ensure accessibility of a .de domain (i.e. to "connect" the domain):

1. In case of a delegation, the applicable Resource Records (RRs) are provided on two or more of the name servers of the domain concerned (strictly speaking one should already say "zone" here). The .de domain servers refer requests for delegated domains to those servers. The name servers and zones must meet a variety of technical requirements. In the .de zone, only the referring NS records are available for delegated zones. In future, the entry may include further infrastructure data.
2. Alternatively, the data can be administered directly in the .de zone. When this option is chosen, it becomes unnecessary to provide an own name server. However, some restrictions will apply for the publishable Resource Records:

• The maximum number of Resource Records allowed to be entered directly in the .de zone for each .de domain is limited to five. (Minimum: one RR)
• Only type A (IPv4 addresses) and type MX (Mail eXchanger) records are supported.
• These A and MX records are subjected to further technical inspections.

Prerequisites for Direct Entries
Up to five NSentries ("A" and/or "MX" entries) are possible. The syntax of each NSentry must be as follows:

Syntax of an NSentry:

domain.de. A <IP address>

subdomain.domain.de. A <IP address>

domain.de.  MX <preference> <host name of mail server>

*.domain.de. MX <preference> <host name of mail server>

You can only use that domain as NSentry for which the request has been made.

For address records (IN A), the following applies: You can use any subdomain that meets the requirements of a host name (according to RFC952 / RFC1123). You are not allowed to use wildcards by entering *. For the definition of the format of the IP address refer to RFC1180, item 5.4 seq. It is not permitted to use IP addresses of internal networks (according to RFC1597) or local hosts. You may, however, state identical NSentries with several IP addresses for the purpose of load balancing.
In case of mail exchange records (IN MX) the following applies: For the preference value you can use any figure between "0" and "999", with "0" denominating the highest and "999" the lowest preference. Wildcards are also permitted with mail exchange records. The name of the mail server stated in the mail exchange record must meet the requirements for valid host names (according to RFC952, RFC1123). Please observe that the Top Level Domain of the mail server must be an existing TLD. Consequently, mail exchange records referring to a local host are not permitted.
A corresponding address record must be on hand for the mail server. If the mail server is recorded in the requested domain itself, the corresponding address record must be included in the domain request.

Example:

denic.de. MX 10 mailer.denic.de.
mailer.denic.de. A 192.0.2.42
General Requirements
All name servers stated in the request must be available and be authoritative for the requested zone.

 

Redundant Connection

 

• At least two name servers connected via IPv4 are required. All IPv4 and IPv6 addresses of each name server are determined or deduced from the request for the further steps of the check. The request must contain at least one name server that includes only IPv4 addresses which differ completely from all the IPv4 addresses of all the other name servers stated in that very request.

Example:
permitted: Name server 1 with the IP address: 192.0.2.1 and name server 2 with the IP address: 192.0.2.3

• Possibly existing IPv6 addresses cannot be used to meet the redundancy requirement.

Glue Records

• If the domain server is located within the domain for which a registration request has been made, the request must include at least one IPv4 and/or one IPv6 address (glue record).

• If you want to enter a name server with one or several IPv6 glue records, the name server must also have at least one IPv4 address.

• It must be possible to find out all A- and AAAA-RR sets of a name server immediately, completely, consistently and authoritatively via any of the IP addresses (v4 or v6) of a name server stated in the request.

Requirements for SOA Data in the Zone

• The SOA serial numbers of the zones must be identical on all name servers

• We provide guideline values for the following SOA values:

The guideline for "Refresh" is: 3600 – 86400 (in seconds)The guideline for "Retry" is: 900 – 28800 (in seconds); "Retry" should be 1/8 to 1/3 the time needed for "Refresh"The guideline for "Expire" is: 604800– 3600000 (in seconds)The guideline for "negTTL" is: 180-86400 (in seconds)

 

Requirements for Further Data in the Zone

• The NS-RR set must be exactly identical with the list of name servers given in the request. There must not be any CNAME-RR for the zone that is applied for (more precisely: at the zone apex).

• The referral response (with QNAME of maximum length and including all the necessary address data with glue records) must fit into a DNS-UPD packet, i.e. must not exceed 512 bytes.

• The primary name server in the SOA-RR of the requested zone must be identical on all name servers.

• Other Specifications Concerning the Name Servers

IPv6 addresses must originate from a Global Unicast address space, be distributed by IANA, marked as ALLOCATED and be routable. This applies to all IPv6 addresses of the stated name servers, regardless whether they are glue records or not.