CZDS Notes

This page is meant to provide enhanced information to support Centralized Zone Data Service access requests. This is an attempt to streamline the process of getting access to the public DNS zone file data under the terms of Section 2 of Specification 4 on the ICANN Registry Agreement from 2017. Other registry contracts will have similar language.

This document is written so as to protect the personal information of the person that issued the CZDS zone file access request. This is also expected to be useful to others in regards to their own access requests or eventual interaction with ICANN compliance.

Basis for granting our zone file access request

The zone file access request that likely brought you to this page was made in support of research in the Security, Stability and Resiliency of the DNS. In particular, the research is currently focused in the security mechanisms that apply to electronic mail transmission and its adoption over time by registrants and registrars, across all regions of the globe. In order to fulfill this goal, zone file data from the CZDS is combined with other data sources to provide a window on the deployment of email security or authentication protocols across the board.

This use case falls squarely within the requirements on § 2.1.1 of the Specification 4 (“Registry Operator will enter into an agreement with any Internet user, which will allow such user to [⋯] download zone file data”). § 2.1.1 goes forth into prescribing a number of reasons for the Registry Operator to deny an application request, as follows:

• (a) the CZDA Provider may reject [⋯] any user that does not satisfy the credentialing requirements [⋯]

  The user profile associated with the zone file access request that led you to this document has been populated with all the required information of the individual issuing the request. The following items might merit additional context:

  • Fax Number: The individual making the request does not have access to inbound facsímile transmissions over Fax. This is a deliberate decision based on technology obsolescence and data protection concerns. Hovever, lack of a facsímile number in no way impede the identification and location information enumerated in § 2.1.2 of Specification 4 and, therefore should not constitute basis for rejecting the request. Specially considering the presence of a valid, correct and complete physical address and voice phone number in the CZDS user profile associated with the request.
  • Organization: The individual making the request is doing so precisely as that: an individual. This has been indicated explicitly in the Organization field of the user profile to prevent any doubts on the matter.

• (b) Registry Operator may reject [⋯]any user that does not provide correct or legitimate credentials [⋯]

  As explained above, all supplied credentials — e.g.: Email, voice phone number, email, postal address—are correct and legitimate.

• [⋯] or where Registry Operator reasonably believes will violate the terms of Section 2.1.5. below

  § 2.1.5 of the Specification 4 unambiguously requires the Registry Operator to grant access to zone file data for lawful purposes. The purpose of the request, provided in the request itself and expanded above, are lawful in the jurisdiction where this request was issued. The requestor also believes that the request is lawful in the jurisdiction of the Registry Operator. That said, § 2.1.5 cite the following potential reasons to reject an access request:

  • ( a ) user takes all reasonable steps to protect against unauthorized access to, use of, and disclosure of the data

    Zone file data obtained as a result of this CZDS zone file access request is stored in general purpose computer hardware that has been secured according to best practices. Transit of the zone file data is minimized by design and restricted to the minimum amount of hardware required for its intended purpose. In addition, zone file data is not backed up to any external media. Access to the zone file data is restricted to the individual who issued to zone file data access request.

  • ( b ) under no circumstances will Registry Operator [⋯] allow user to use the data to (i) [⋯] marketing activities to entities other than the user’s existing customers [⋯],

    The zone file data obtained as a result of this CZDS zone file access request is meant to be used for the purpose stated above, which does not involve any form of marketing to any third parties.

  • ( b ) under no circumstances will Registry Operator [⋯] allow user to use the data to [⋯] (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-accredited registrar

    The zone file data obtained as a result of this CZDS zone file access request will be used precisely to avoid the need to engage in the wasteful resource utilization depicted bu the restriction above. Indeed, access to the zone file data allows for an efficient operation of the data gathering component of the stated objective, and therefore reduces resource utilization for all parties involved.

  • ( b ) under no circumstances will Registry Operator [⋯] allow user to use the data to [⋯] (iii) interrupt, disrupt or interfere in the normal business operations of any registrant.

    See point above.

  • ( c ) Registry Operator may revoke access of any user if Registry Operator has evidence to support that the user has violated the terms [⋯]

    Revocation requires evidence, which is available fully allows the Registry Operator to terminate the access rights of the requestor. This document is concerned with the approval of initial requests or renewal of said requests.

If despite the above exposition you are still unable to approve the CZDS zone file access request, we would appreciate you getting in touch using the email address provided in the request to provide additional information. Both the request and this document have been prepared in good faith, with the goal of helping us all save time and obtain the desired data access with minimal interaction and in the shortest possible time. Providing additional information in future requests is a positive step in this direction, but we can only do so with understanding of your specific needs.

On the duration of zone file access approval

The decision on how long to approve zone file access rests on each Registry Operator policies for the affected TLD.

At the time of this writing, manual vetting of zone file access requests can be a time consuming task. CZDS users have the ability to submit access requests through an API, allowing for substantial automation to be leveraged for automatic management of access requests. In this regard, the shorter the duration of the approval, the more access requests that the Registry Operator will have to process over time.

From the argument above, it follows that approving access requests for the maximum available amount of time reduces Registry Operator costs and improves end users continued access to the required data.

On the use of automatic approval on the Registry CZDS interface

The CZDS interface offers Registry Operators with the option to automatically approve access requests. By using this function, Registry Operators can unburden from the mandatory task of having to process access requests while at the same time, allowing end users to fulfill their access requirements with minimal interruptions.

While evaluating whether to use this option or not, the confidentiality of the zone file contents is often mentioned. Please keep in mind that the contents of a DNS zone are not confidential. The zone files are pushed to DNS servers for public consumption via queries. Furthermore, there are mechanisms that can be used to explore the contents of those zone files, even when NSEC3 is used. Other protocols and methods such as WHOIS and Passive DNS can be leveraged to compile a large fraction of the zone file data, sometimes at substantial cost to the Registry Operator.

On the involvement of ICANN compliance

While it is true that the ICANN Registry Agreement from 2017 does not provide an absolute SLA on the processing of CZDS zone file access requests, ICANN compliance does offer a mechanism that allow end users to log complaints against Registry Operators that erroneously deny access requests or fail to respond in a reasonable time. Sending a complete complaint via email to globalsupport@icann.org is also a known mechanism to log a complaint.

It is important to emphasize that as per the Registry Agreement, the Registry Operator has the obligation to process the requests according to the constraints described above. Failing to do so constitutes a breach of contract.