Proposed Unsponsored TLD Agreement: Appendix C, Part 4 (.name)

Proposed Unsponsored TLD Agreement: Appendix C, Part 4 (.name) (2 July 2001)

Part 4 - DNS Zone Generation and Propagation

Overview

The Domain Name System (DNS) resolving service for the .name top-level domain (TLD) provides end-users with the ability to use .name addresses in standard Internet applications. It also supports the SLD E-mail forwarding service by directing e-mail to the mail exchangers operated by the Registry Operator.

The DNS contains a number of records called Resource Records, or RRs for short, in a hierarchy. This hierarchy starts at the root, and all DNS lookups conceptually start at this root and step through the hierarchy until they reach the target RR. The most common domain lookups typically seek the IP address associated with a Fully Qualified Domain Name ("FQDN"); this is stored in the "A" resource record. Other common RR types include the "MX" RR which is used for e-mail delivery, "NS" which points to a nameserver for a domain on the next hierarchical level, and "SOA" which appears once in each zone and defines various parameters of the zone.

Requests for any address in the .name zone will be delegated from the root servers to a set of DNS servers specified by the Registry Operator. These DNS servers will resolve all second- and third-level domains in the .name TLD, either by delegating nameservice of third-level domains to nameservers specified through the Shared Registration System, by providing MX responses for second-level domains in connection with the SLD E-mail forwarding service, or by providing A record responses for second- and third-level domains used for the .name TLD's infrastructure services such as shared second-level informational web pages.

The nameservice provided by the Registry Operator for each active, non-suspended registered domain ("firstname.lastname.name") will have:

• One or more NS records pointing to nameservers authoritative for that domain. Provisioning and operation of these lower-level nameservers is to be arranged by or for the customer and is not the responsibility of the Registry Operator. However, these nameservers will typically include Resource Records appropriate to the third-level domain. These will typically include one or more A records for resolving host IP addresses, and one or more MX records that indicate which host in the domain handles incoming email.
  
  
• One or more A records (often known as "glue records") to give the IP addresses of the nameserver(s) for the domain, in the unlikely case that the nameserver(s) is not already registered elsewhere in the DNS.
  
  
• Optional extra records, such as DNS-SEC "SIG" and "NXT" records.

In addition, the Registry Operator will create second-level domains in the .name TLD to correspond to any third-level domains that exist. For each such second-level domain, the nameservice provided by the Registry Operator shall include MX records for the SLD E-mail forwarding service and A records for shared second level information pages. These will not interfere with the normal third-level registered domains ("firstname.lastname.name"), and are the only records that will be permitted to be on the second level. As each third-level registration is received, a corresponding second-level set of MX records will be added, which point to the Registry Operator's SLD E-mail forwarding servers. Further details on the email forwarding service are contained in Part 1(D) of this Appendix.

In addition, the nameservice provided by the Registry Operator includes and SOA record that contains the refresh time, negative cache TTL, serial number and contact details for the zone administrator.
Zone files are generated by the Registry Operator based on data stored in the Shared Registration System database. The zone files are then propagated to DNS nameservers operated by or for the Registry Operator. Registry Operator will determine based on performance and other considerations whether to provide the nameservice at the second and third levels through a single zone, or whether nameservice for one or more subdomains (e.g., smith.name) should be provided through a separate zone (often known as a "zone cut").

Standards Compliance

The Registry Operator will provide a service which is fully compliant with the core DNS protocol, as defined in RFC1034 and RFC1035, with all due attention paid to the clarifications defined in RFC2181 and RFC2182. Enhancements to this standard are defined in further RFCs, as listed in the Part 14 of this Appendix. Additional features supported by the Registry Operator's DNS service include TSIG (RFC 2845) and DNS-SEC (RFC 2535). Should any extra enhancements to the DNS standard be ratified by the IETF, in accordance with the Registry Agreement the Registry Operator will endeavour to implement these in a timely fashion, with the proviso that internet stability and client backwards compatibility must be maintained.

Structure

One DNS server at the main site will be configured as the Primary Master for the .name zone. This Primary Master (hereafter termed "Master server") will be the only Master Server for the .name zone. This Master server will receive updates from the update server, which in turn receives the updates from the database. The Master server will push updates out to other DNS servers, which will be configured as Slave servers for the .name zone. Updates sent from the update server will be in dynamic DNS format, and go to the Master server first. Notify messages then propagate out to the Slaves on the rest of the network, which request Incremental Zone Transfers as required. If additional outsourced servers are provided, the Master server will send updates to these servers as well.

Implementation details

The .name DNS service will operate from multiple, dedicated servers, as described in Appendix A. These servers will provide authoritative resolution for third-level domains under .name. The servers will be physically located according to the "Location and Hosting" section of this Appendix and as described in Appendix A - these locations will be chosen so as to minimise the load on any one server. Should the Registry Operator decide that further DNS service is required, this may be provided by extra servers on the Registry Operator's DNS network or by the use of outsourced DNS service, at the Registry Operator's discretion. In the interests of expediency, primary resolving DNS services may also be provided by outsourcing during the landrush period, again at the Registry Operator's discretion.

Sequence of events for Master server

• Wait for a query
  
  
• Incoming query for RR stored in .name domain
  
  
  • Accept the query
    
    
  • Process the query according to the zone file
    
    
  • If the requested RR was located, return the data, and resume query-waiting state
    
    
  • If the requested data is not available to this server, return a pointer to the most appropriate place to find more information (delegated domains).
    
    
• Incoming query for non-.name data
  
  
  • Return REFUSED response code 5
    
    
• Zone Transfer (Authoritative or Incremental) query from slave server
  
  
  • Initiate zone transfer then continue processing
    
    
• Zone Transfer (Authoritative or Incremental) query not from slave server
  
  
  • Return REFUSED response code 5
    
    
• Dynamic Update request from update server
  
  
  • Perform the dynamic update, then send Notify requests to slaves
    
    
• Dynamic Update request not from update server
  
  
  • Return REFUSED response code 5
    
    
• Notify message
  
  
  • Ignore and continue processing

Sequence of events for Master Backup server

• Zone Transfer (Authoritative or Incremental) query from slave server
  
  
  • Initiate zone transfer then continue processing
    
    
• Zone Transfer (Authoritative or Incremental) query from IANA IP-addresses as defined in Appendix A.
  
  
  • Initiate zone transfer then continue processing
    
    
• Zone Transfer (Authoritative or Incremental) query not from slave server
  
  
  • Return REFUSED response code 5
    
    
• Dynamic Update request from update server
  
  
  • Perform the dynamic update, then send Notify requests to slaves
    
    
• Dynamic Update request not from update server
  
  
  • Return REFUSED response code 5
    
    
• Notify message
  
  
  • Ignore and continue processing

Sequence of events for Slave servers

• Waiting for queries
  
  
• Incoming query for RR stored in .name domain
  
  
  • Accept the query
    
    
  • Process the query according to the zone file
    
    
  • If the requested RR was located, return the data, and resume query-waiting state
    
    
  • If the requested data is not available to this server, return a pointer to the most appropriate place to find more information.
    
    
• Incoming query for non-.name data
  
  
  • Return REFUSED response code 5
    
    
• Zone Transfer (Authoritative or Incremental) query
  
  
  • Return REFUSED response code 5
    
    
• Dynamic Update request
  
  
  • Return REFUSED response code 5
    
    
• Notify message
  
  
  • Request SOA from master and request IXFR if serial has changed

All Internet-visible DNS servers will offer unrestricted .name query resolution to any Internet clients in normal operation, although the Registry Operator reserves the right to deny access to clients which are deemed to be causing, or about to cause, a loss in service to other Internet clients. The DNS servers will listen for incoming queries on the IANA-assigned DNS port (which is defined as port 53 for both UDP and TCP connections). Any RFC1035-compliant client with suitable Internet connectivity will be able to connect to at least one Registry Operator DNS server on port53 for the purposes of performing a DNS query.

Domain names as stored in the DNS are constructed from a characterset specified in the "Charactersets" of this Appendix. The rules for valid domain names are taken from RFC1035, which states:

"The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less."

RFC1035 also has some further comments on characterset extensibility and case rules for this service:

"For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided."

The Registry Operator intends to honour the original domain name specification, so that all domain names for which the Registry Operator provides nameservice shall comply with the format described in Part 13 (Domain name character set) of this Appendix C. This means that all domains must use only alphanumeric characters and the dash ("-") character, until a standard for multilingual or extended characterset DNS records is ratified by the IETF.

The constants defined in section 2.3.4 of RFC1035 will be applicable to the .name domain:

"labels 63 octets or less
names 255 octets or less
TTL positive values of a signed 32 bit number.
UDP messages 512 octets or less"

Note that the .name domain is an IN-class domain; all records stored in the .name domain are in the IN class. Chaos, Hesiod and CSNET records are not supported.

Example Zone

An example of the zone file format used in .name follows. Note that this is an example only, and intended only to provide a rough guide; further information can be found by reading the relevant RFCs (particularly 1034, 1035).

; .NAME zone
;
; Automatically generated from the master database
$TTL 2d
$ORIGIN name.
@		IN	SOA	ns1.nic.name. hostmaster.name. (
					14		; Serial number
					1H		; Refresh time
					1H		; Retry time
					1D		; Expiry time
					5M	)	; Negative cache time


		IN	NS	ns1.nic.name.
		IN	NS	ns2.nic.name.
		IN	NS	ns3.nic.name.
		IN	NS	ns4.nic.name.
		IN	NS	ns5.nic.name.
		IN	NS	ns6.nic.name.
		IN	NS	out.nic.name. 
		IN	A	192.168.1.1
		IN	MX	10 mail.nic.name.


; The GNR-specific domain


nic		IN	NS	ns1.nic.name.


; Name servers


ns1.nic		IN	A	192.168.1.1
ns2.nic		IN	A	192.168.1.22
ns3.nic		IN	A	192.168.1.23
ns4.nic		IN	A	192.168.1.24


; Network services


www.nic		IN	CNAME	@
ftp.nic		IN	CNAME	@
mail.nic		IN	CNAME	@


; Delegated domains and email forwarding


smith			IN	MX	mx1.nic.name.
			IN	MX	mx2.nic.name.
			IN	MX	mx3.nic.name.
			IN	MX	mx4.nic.name.
john.smith		IN	NS	ns.john.smith.name.
ns.john.smith	IN	A	192.168.2.1

mary.smith		IN	NS	ns.registrar.com.
			IN	NS	ns2.registrar.com.

The Registry Operator retains the right to split the .name zone and delegate certain secondlevel domains to specific nameservers if deemed necessary to provide an optimal level of service. This will not adversely affect the DNS resolution process and will be transparent to end-users.

Update mechanism

The near-realtime service will be achieved through the use of several extended features of the DNS protocol.

• Dynamic DNS Updates (RFC2136)
  
  
• DNS Notify messages (RFC1996)
  
  
• Incremental zone transfers (RFC1995)

Updates are generated by the update server from the master database. These updates are then transmitted to the master server using the Dynamic DNS update protocol, in the form of a series of messages containing records to add or remove. The master server then uses the DNS Notify mechanism to inform slave servers of changes to the zone file. When the update server has finished sending the update messages to the Primary Master server, the Master server integrates these into the zone file, generating a new zone file and incrementing the serial number on the SOA record (see later). The Master server then sends out one Notify request to each of the listed slaves.

As each slave receives a Notify message, it will load the Start Of Authority (SOA) record from the .name zone on the master server. This is a special record type which contains some numbers defining the operation of the domain. The first of these numbers is called the serial number, and is the current version of the zone file. When a slave requests the SOA record, it will then compare the serial number from this record to the SOA record it has stored in the slave copy of the zone. If the serial number is higher on the master than on the slave, then the zone file has changed.

This will cause each slave in turn to request an Incremental Zone Transfer from the Master, which will transfer only the changes made since the previous serial number. As each slave obtains the new zone file, it will send out a Notify message to all registered nameservers for the .name domain in turn, resulting in several SOA requests on the Master from each slave. The amount of data transferred in an SOA request is very small, and causing the slaves to send Notify messages as well as the Master will reduce the chances of a missed notification.

Changes to the zone file are tracked on the Master server; it stores journal data which indicates the changes between each successive serial number. Servers which do not have the previous zone file data, or servers which hold corrupted data, may request an Authoritative Zone Transfer (AXFR) using the DNS protocol to transfer a complete copy of the zone. This method is primarily used for synchronising servers after a system shutdown or reboot, and may be required in the unlikely case of a NOTIFY request being lost.

The negative cache time on the SOA record for the .name domain is purposefully kept as small as possible, on the region of 2 to 5 minutes. This value dictates how long a negative response is stored in a resolver's cache before the data may be requested again, and affects the amount of time an end-user would have to wait between registering a .name domain and being able to access it through DNS. Some older systems may ignore this negative cache value and either not cache negative responses or use a hardcoded default value. Time to live for existing domains is longer, on the order of several days, since domain expiry is less of an issue than bringing new domains into the system. It should be noted that these are suggested values only and GNR retains the right to alter them to optimise the performance of the .name resolving service.

For reasons of increased efficiency, further communication links between GNR servers and external secondary DNS providers may be provided at the discretion of the Global Name Registry.

.name zone summary

In case of ambiguity between this section and the example zone file provided above, this section is to be taken as definitive. In the top level, there will be the following resource records:

• SOA - "Start of Authority", containing the serial number for the zone and the time-to-live values.
  
  
• NS - five or more NS records which point to the nameservers for the .name domain, and any secondary nameservers provided by either the Registry Operator or outsourced DNS providers.
  
  
• A - one or more A records pointing to Registry Operator WWW servers for the purpose of providing information on the .name domain; these are intended to point end-users in the correct direction for registering names in the .name domain.
  
  
• MX - one or more MX records which point to internal Registry Operator SLD E-mail servers for the purpose of providing a channel by which end-users may raise service queries and so forth. These MX records are aliases to the "smtp.nic.name" domain so that messages to "abuse@name" or "hostmaster@name" are redirected to the appropriate location.
  
  
• NXT - DNS-SEC records, which are required for providing validation of NXDOMAIN responses.
  
  
• SIG - DNS-SEC signature records used to validate responses from the .name domain.
  
  
• KEY - DNS-SEC public key for the .name zone

In the second level, there will be MX records which will resolve requests to registered SLD E-mail forwarding 2nd level domains to one of the Registry Operator-provided email forwarding servers. The reply will take the form of "mx<NN>.nic.name", where "<NN>" indicates a decimal number. There will also be A records which point to shared second level information pages. The only RR types allowed in the second level are A records, MX records, and corresponding DNS-SEC "NXT"/"SIG" records. In addition, the Registry Operator reserves the right to split second-level domains into further zones which will also be operated by the Registry Operator's servers (as described earlier in this section), and these will necessitate further SOA, NS, and KEY records on the second level.

On the third level, permitted record types are:

• NS - name server records which will typically point to one or more registrar-provided nameservers for the domain.
  
  
• NXT - DNS-SEC record which is used for NXDOMAIN validation.
  
  
• SIG - DNS-SEC record which can be used to verify the authenticity of returned data.

In addition, A records will be included as necessary for glue to support nameservers delegated at the first, second, and third levels.

The Registry Operator's WWW servers will also require A records on the third level, so that users may go to "www.gnr.name" in order to find out more about the .name domain, including how to register through an approved registrar.

Wherever A resource records are mentioned in this Appendix, it should be noted that IPv6 AAAA or A6 resource records may be used in addition to, or as a substitute for, A records, as and when IPv6 is implemented in the .name zone. Registry Operator will provide ICANN with specifications for this service so that prior consultation and agreement may be achieved on any implementation.

Operating parameters

The DNS service is a critical component of the .name registry. It is of utmost importance that this service be available whether or not any other part of the registry is accessible. The service level is defined and governed as described in Appendix D and Appendix E. The DNS sites will be set up and operated according to the suggestions offered by RFC2870, "Root name server operational requirements", although the Registry Operator plans to use this as a guideline only and does not guarantee total conformance to this RFC.

To ensure that updates are synchronised, and for correct operation of the TSIG protocol, it is necessary to keep the clocks on the DNS servers synchronised. This is achieved using the Network Time Protocol, as described in RFC1305. Each DNS server will run an NTP client, connecting to a central master NTP server at the main site. The TSIG protocol requires that all clocks be synchronised to within a few minutes of each other. Further details on the NTP service are provided in Part 12 (Other Modules) of Appendix C.

DNS data will be periodically checked for validity against the registry database. This is accomplished in several stages: all requests received by the master server from the update server are recorded. These requests will then be compared with the master list from the update server to ensure that all updates have been processed correctly. All slave servers will retrieve the SOA record every hour to compare the serial number of the master zone against the current version of the slave zone, and if the master has a newer copy of the zone then an IXFR will be performed. If a notify message is missed, then it will only be a maximum of one hour before the slave server is brought back up to date. The .name zone from the master server will be compared with the central database once every 24 hours, using an authoritative zone transfer from the master to the update server and comparing the data directly.

Security

The Registry Operator has identified data integrity as the key security priority, followed by data accessibility. Any data retrieved from any of the .name domain servers must be accurate, and if this is not the case then that server should be removed from service until such time as the problem can be resolved.

Transaction Signatures ("TSIG"), as described in RFC2845, will be used for data transmission from the update server to the master server. TSIG uses a shared secret authentication method, using a single key to encrypt communications between two systems. All transactions between the master server and the update server must use TSIG; any attempted dynamic update or zone transfer will be rejected if the key is not used. Using the TSIG protocol ensures that the messages sent from a source system are received unaltered at the target, and so guarantees that update requests originating from the update server will reach the master server without the usual possibility of data tampering along the way. TSIG will also be used to sign transactions between the master and slave servers, in a similar way. The procedure for securing dynamic updates is described in several RFCs, in particular RFC3007.The TSIG key and IP address combination provides two layers of security between update server, master server and slave servers. All dynamic update and zone transfer requests and replies take place on a separate network interface to the main query interface, and this update interface also implements stricter routing controls and firewalling rules. In total, communication integrity and host authentication are protected by three layers of security.

Registry Operator intends to offer the functionality of DNS-SEC, with which the integrity of the data itself can be verified.. This protocol adds key records to zones, which use key pairs to authenticate the data. DNS-SEC does not guarantee the integrity of the communications link, but it provides surety that the data has not been altered, so by using DNSSEC and the TSIG protocol in tandem the Registry Operator servers have both communications, and data, integrity. Signing of the .name domain will follow the recommendations of RFC 2541 (DNS Security Operational Considerations), using DNS-SEC as defined in RFC2535.

The use of DNS-SEC is optional for Internet users wishing to resolve .name domains. The DNS-SEC data is stored as extra RRs for each signed record in the zone. A DNS-SEC-capable resolver will retrieve the DNS-SEC signature records in the additional section of a DNS response. The resolver must then check this signature against the .name public key to verify that the data has not been tampered with. Since the root domain is not signed at this time, the Registry Operator public key will not be stored in the root zone; this key will be available from other sources, and further information on obtaining this key, as well as pointers to more information on DNS-SEC, will be available from the Registry Operator's website.

DNS servers will run a minimal set of services, as listed in Part 12 (Other Modules) of Appendix C, in addition to the DNS server software. Checks will take place on all DNS servers to ensure that data integrity is retained, and should any fault or incongruity be detected, a full zone transfer will take place from the Master server to the affected slave, or from Update server to the Master. This event will also be logged.

Reporting

A count of all transactions processed by each DNS server will be recorded, and sent to the main site once every 24 hour period. Each domain update request received at the main site via the update server will be recorded in the local site log, and transferred to the main site. If a domain is registered with an invalid name, this will also be stored in the local site log. Further logs such as NXDOMAIN logs may also be produced for the purpose of analysing and increasing efficiency. Domain update requests will be coupled with an indication of the outcome of the request.

Any security-related messages will be recorded in a separate log. These will be categorised as TSIG authentication failures, source IP address mismatch and target IP address mismatch. In addition, regular checks will be performed on the integrity of the DNS data by retrieving random records (using a client on a separate system to the DNS network) and checking the signature against the Registry Operator's key, via DNS-SEC. Other statistics will be held by GNR for the purposes of internal operational monitoring and service performance checking. Further details on required reporting are contained in Appendices T and U.

Page Updated 03-Jul-2001

(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.