.nz Specific EPP rules¶
Contact Identifier - <contact:id>¶
All contact objects are identified by a unique identifier. The contact id has to be provided by the registrar with a contact create command.
The only time a contact object is created by the server is with a transfer of a domain name. Please check the <domain:transfer> command for more information.
Server-generated contact objects begin with the characters “nzrs_auto”. Registrars will not be able to create contact ids starting like this. The namespace is reserved for server-generated contact objects and contact creates with contact ids starting with “nzrs_auto” will fail.
Status of a contact object¶
A contact object as per EPP standard has at least one associated status value.The default status is “OK”. In the NZ registry system (SRS) a contact cannot be transferred or locked. Therefore the .nz EPP server doesn’t support any other contact object status but “OK”.
Individual and Organisational Name - <contact:name> and <contact:org>¶
The EPP standard allows an attribute for individuals <contact:name> and an additional element for the name of an organisation <contact:org>.
However the SRS only supports a single contact name as it is sufficient to provide either an organisation or a person as registrant. .nz domain names have no additional attribute to store an organisation or to flag whether the contact is an organisation or a person. A .nz domain name registrant, administrative contact and/or technical contact can be either identifiable individuals over 18 years of age or properly constituted organisations. Therefore, the .nz EPP server only supports a <contact:name> element and ignores the <contact:org> element supplied by registrars.
If a value is provided with the <contact:org> element a policy error is returned to avoid misunderstanding of what contact information is stored. Any additional details provided via EPP that cannot be stored by the SRS will generate a policy error as well.
Postal element - <contact:postalInfo>¶
In the EPP standard the postal element <contact:postalInfo> can occur once or twice with an attribute type=”int” and/or type=”loc”.
However the SRS only accepts internationalised postal information. Therefor only the “int” value is accepted and returned by the .nz EPP server and only one postalInfo element can be supplied.
Maximum of two <contact:street> elements¶
Providing a third street element via the contact create command will return a policy error as the SRS only allows two address fields.
The SRS doesn’t support the transfer of contact objects between registrars and allows registrars to only query their own contact objects. Therefore no additional authorisation information is required to create and query contact objects. An <authInfo> element provided by the registrar is ignored.
Disclosure of Data Elements and Attributes¶
The EPP standard RFC5733 supplies an optional <contact:disclose > element to allow clients to identify elements that require special handling by the server to make sure this data is not disclosed to third parties (e.g. Whois).
Under .nz policy registrants who are individuals are able to elect a privacy option. Therefore to set the individual registrant privacy option, registrars need to set the flag attribute in the <contact:disclose> element to ‘0’ (zero). To turn off the individual registrant privacy option, set it to ‘1’ (one).
- Privacy can be applied to any contact of individual registrants who are not in significant trade.
- Privacy can be set for just the contact address, phone number and fax number.
When specifying the <contact:disclosure flag=”0”> element, if <contact:email>, <contact:org> or <contact:name> is a sub-element, the error code 2308 will be returned as we do not offer privacy on e-mail addresses. If any other element exists, then we will mask all the fields as detailed in the .nz Operations and Procedures v2.1 section 21.8.
Please check .nz policies and procedures as per the DNC Operations and Procedures Policy - for more information on data disclosure regulations under .nz.
AuthInfo vs UDAI¶
The <authInfo> element is required in many EPP commands. However the .nz EPP server ignores any user generated AuthInfo input.
When a .nz domain is created a random 8 digit UDAI (Unique Domain Authentication ID) is generated that is required to authenticate requests to transfer domain names from one registrar to another.
The UDAI is generated by the registry system and is returned to the registrar by placing a message in the registrar’s Poll message queue.
Providing content in the required AuthInfo element (per RFC 5731) is ignored by the system unless the command is a domain:transfer, domain:update or domain:info. In case of a domain:update a new UDAI is generated if the AuthInfo element is provided, i.e. the actual password if provided is ignored, while the domain:info command can be used to validate a UDAI.
The domain:info will not return the UDAI on demand as we’re only permanently storing the one-way cryptographic hash of the UDAI (as per best-practices for storing passwords) in the database after the initial generation and poll message have been sent.
Status Values for .nz EPP¶
Domains in the SRS can only have one of two statuses, either “Active” or “PendingRelease”. Other information that is represented by statuses in the EPP standard may actually be attributes or date elements in the SRS.
|Status||Status in .nz EPP||Status/Attribute in SRS|
|an active, delegated domain name||OK||Active|
|a domain name in RedemptionGracePerid (after cancel/delete)||PendingDelete||PendingRelease|
|a domain name not delegated in the DNS||clientHold||Delegate=”0”|
|a domain name that has been locked by the registry||serverUpdateProhibited AND serverDeleteProhibited AND serverRenewProhibited AND serverTransferProhibited||LockedDate=”YYYY-MM-DD HH:MM:SS”|
As per .nz policy a registered .nz domain name can be transferred, updated, renewed and deleted at any time unless the domain name has been locked by the registry. Therefore no client statuses other than clientHold can be set with <domain:update> command. The statuses clientUpdateProhibited, clientDeleteProhibited, clientRenewProhibited and clientTransferProhibited are not supported by the .nz EPP implementation.
To specify the length of a domain nameʼs registration period EPP standard provides a validity period element. The element consists of an attribute ʻunitʼ and a number. The unit attribute describes if the provided length is in months or years. Unit values can be either year (y) or month (m). The combination of unit and provided number determines the length of the registration period.
In the SRS the corresponding field is called “Term”. This field only allows the specification of the number of months a domain name is to be registered. The value can be between 1-120. I.e. a .nz domain name can be registered between 1 months and 10 years.
In the .nz EPP implementation if no period value is provided in a domain create request the default registration period is one month. Please note that the EPP standard only allows a maximum value of 99 for the period element. That means you could not create a domain name with a period of 120 months but instead would need to use the unit value “y” and the maximum registration value of 10 (years).
.nz domain names are auto renewed at the end of their registration period. The default value of an auto-renwal is one month. In the SRS a Term field can be changes to auto-renew a domain name for a longer period at the end of a registration period. However the EPP standard only allows an update of a registration period by running a <domain:renewal> command. The renewal is processed immediately, not at the end of the registration period. I.e. if a longer registration period is required rather than having the domain name auto-renewed on a monthly baisis the domain name needs to be renewed with the <domain:renewal> command.
There is a 5 day Renewal Grace Period in which a renewal can be undone by deleting the domain name. If a domain name is renewed and the registrant decides not to keep the domain name it can be deleted within 5 days of the renewal. This will cancel the domain name, undo the renewal and cancel the renewal billing transaction, the renewal is not charged.
Un-cancel a domain name¶
After a domain name is cancelled it is changed to the status “PendingDelete” (in SRS: “PendingRelease”). This period lasts 90 days and during that time the domain name can be re-activated (un-cancelled) by the registrar of the domain name. To un-cancel the domain name the registrar needs to send a <domain:update> command which will automatically change the status from “PendingDelete” to “OK”.
Note: A domain name with status “PendingDelete” is not delegated in the DNS.
Originally in the SRS domain contact details were - and mostly still are - embedded in the domain name. I.e contact details like postal information, email address and phone/fax details are not kept in a separate contact objects (aka handles) but within the domain object (domain name).
We have introduced contact objects to the SRS to be able to add an EPP interface to the system. For the reason of backward compatibility the SRS will continue to except contact information embedded in the domain.
That means transferred domain names may have embedded contact details rather than contact objects. As these cannot be queried by EPP the system automatically generates contact objects with the contact details when a domain is transferred with the EPP server. Please see the Transfer Command for more information.
Registrant, Administrativ and Technical contact¶
Even though the <domain:registrant> element is optional per EPP standard, .nz policy requires a registrant and if not provided the registration will fail.
If no admin contact or technical contact type is provided with the create or update of a .nz domain name SRS default values are uses. The admin contact would be the same as the registrant and the technical contact would be the Registrar’s Default Technical Contact.
Name Servers/Host Objects¶
.nz is not supporting host objects. Therefore name servers need to be provided in hostAttr elements. .nz domain names can have between 0 and 10 name servers.
IPv4 and/or IPv6 addresses only need to be provided if the name servers are ‘self serving’ (host name = domain name). If they are not required they will be ignored and not stored in the system.
DNSSEC - DS records¶
The SRS Accepts DS Records to support checking of the authenticity of results retrieved from the DNS system for delegated domains. Each DS record consists of four fields: KeyTag, Algorithm, DigestType and Digest. See DS data field definitions
The following registration rules will be applied:
- Each domain can hold up to 10 DS records
- DS records will only be accepted if name server (NS) records are present for the domain
- DS records will be included in the zone only if the domain is delegated
- If a transaction attempts to delete NS records for a domain with DS records, it will be rejected. DS records must be deleted before NS records. It is valid to delete both NS and DS records in the same transaction.
|<secDNS:alg>||1||We support the following algorithms: 5 (RSA/SHA-1), 6 (DSA-NSEC3-SHA1), 7 (RSASHA1-NSEC3-SHA1), 8 (RSA/SHA-256), 10 (RSA/SHA-512), and 13 (ECDSA Curve P-256 with SHA-256)|
|<secDNS:digestType>||1||We support the following digestTypes: 1 (SHA-1) and 2 (SHA-256)|