Internationalised domain names¶
The registration of internationalised domain names (IDNs) with macronised vowels which feature in the Māori language, an official language under New Zealand law, will continue to be supported in the new registry system.
IDN’s are supported in the IRS portal and in the EPP API.
For the EPP API there is a significant change to the management of IDN domains, the IRS uses the IDN 1.0 EPP extension. This extension must be used when registering IDN domain names.
For full details of the extension see : idn-1.0 - RFC Draft: eppext-idnmap
The IRS registrar guide also contains details on using IDNs in the IRS portal and provides EPP examples.
Potential registrar process change - registering and querying IDN domain names
Domain search (domain details query)¶
In the current SRS registry, the DomainDetailsQry allows registrars to retrieve domain details for one or more domains, including details that are not shown in public WHOIS queries. The DomainDetailsQry can also be used to view historical details for a domain and may return a full update history. Most fields can be used as search filters to refine the results, and there is an option of returning a count of results as well.
In the IRS, the equivalent domain search functionality is provided by the IRS portal (also see the domain history section below). The search function in the IRS portal allows for a basic and an advanced search, where you can build complex queries.
This is a significant technical change for SRS registrars
Domain information can be retrieved from the registry via the EPP domain info commands and/or using the IRS portal. In addition to the IRS portal query/search functionality.
The IRS portal provides a number of built-in domain name management reports which can be downloaded in CSV format:
Activity Summary — displays a list of all of the interactions with your registry.
Transaction Details — displays a list of financial transactions for a configured reporting period.
Domain Names List — displays a list of all of the domain names for your registrar account.
The expiry time and date of the domain name was previously known and referred to as the billed until date in the SRS.
Potential registrar process change - terminology
Authorisation code (Auth-Code)
An Auth-Code (previously known as UDAI in the SRS, and a.k.a. EPP code, authorisation code, transfer code, or Auth-Info Code), is a generated passcode required to transfer a domain name between registrars; the code is intended to indicate that the domain name holder has authorised the transfer.
The main changes in IRS are:
Terminology change - we will no longer use the term UDAI and instead will refer to it as Authorisation code or Auth-Code,
The registry no longer generates the Auth-Code and no longer returns it by a poll message,
Registrars must specify a new Auth-Code when creating a domain or on request from a domain name holder,
Auth-Codes will expire after 30 days from creation or reset,
The Auth-Code must be 16 characters in length and consist only of alphanumeric characters, i.e. lowercase a to z, uppercase A to Z, numerals 0 to 9 or the hyphen (-),
We will not be be migrating current UDAI values,
Auth-Codes are stored with one-way cryptography/hashing. Therefore in EPP the domain:authinfo element is removed from the Domain Info response (registrars can no longer use a domain:info command to fetch the existing authInfo), and in the IRS portal the auth code is masked, and
There is no Auth-Code validation check available, a new one should be generated if a transfer fails with the provided Auth-Code.
Potential registrar process change - terminology, generation and validation of Auth-Code
Any UDAIs issued to domain name holders prior to Go-Live will not be valid after.
Delegate flag (deleted)
In the SRS the delegate flag is used to control whether the domain name is included in the .nz zone file. This field will not be available in the IRS. The current values will be transformed during migration, so any domains with delegate set to false, will have the domain clientHold status flag on in IRS.
Potential registrar process change - customer support
Registrant reference (deleted)
In the SRS the registrant reference (reg_customer_ref) is an optional field that registrars can populate with reference information for the registrant, e.g. a customer number, that flows through to the invoice. It’s free-format and is attached to the domain. This field will not be available in the IRS and the data will not be migrated.
Potential registrar process change - billing and customer support
Reseller name (new)
We are introducing a new field, “Reseller Name,” associated with a domain. The reseller field will be an optional string that registrars can use as they like. The intent is for registrars who have resellers to record the reseller name for the domain. The field will not be part of the WHOIS results. The field will be cleared when a domain is transferred between registrars.
The reseller name property is available in the IRS portal or, if using EPP, can be specified in a Domain Create or Domain Update request. EPP requests will require the
fury-2.0.xsd extension, the reseller name property is defined using the fury:key
Historical domain data was available to registrars via the SRS protocol, the key changes for historical domain data in IRS are:
No Pre-migration SRS historical data is being migrated from the current SRS to the new IRS,
Only transactions that occur after the IRS go-live date will be available for historical data queries,
Historical domain data queries will only be available via the IRS portal and registrars will only see historical data for the period when they are the sponsoring registrar for a domain; for example, if Registrar A transfers a domain to Registrar B and then the domain is transferred back to them, Registrar A will not be able to see historical data for the period during which Registrar B was the sponsoring Registrar,
Pre-migration SRS historical data will be available for access by registry support.
Please note, SRS historical data will not be be available to registrars and will not be migrated into the IRS database.
Privacy in the current system was formally known as the Individual Registrant Privacy Option (IRPO), we will now refer to it as just the “Privacy Option.” Privacy for a Domain Name Holder continues in the new system; however, there is a change to how it is applied at the domain and contact level.
In the current SRS, privacy can be set at the contact level, i.e. for any of the contacts associated with a domain: registrant, admin and/or technical. In the IRS this changes to privacy at the domain level, and is no longer available on a per contact basis.
Please refer to the new .nz policy (section 6) for the policy and operational rules for setting domain privacy and the Query Search section below for which details are returned when a domain has privacy applied.
Eligible domain name holders can elect the privacy option at the time of registering a domain name and can change their selection at any time afterwards.
Privacy applies to all contacts associated to a domain including secondary contacts that may be a mix of individuals and organisations.
Creating a domain¶
Domains can be created using the IRS portal or via the EPP API.
The term field in the current SRS contains the registration duration for the next renewal, whereas the term field in the IRS contains the registration duration for the last create or renewal.
Additionally, the term field in the SRS was based on months with a range from 1 to 120. In the IRS the unit has changed from months to years, with a range of 1 to 10. This means the minimum registration period is now 1 year.
Potential registrar process change - billing, website
To successfully create a new domain name, it must be associated with either a new or existing registrant, administrative and technical contact. This is the same as the current SRS, however in the IRS all three contacts must be provided. If the administrative and technical contact are not provided, no default contacts will be applied, as they are currently in the SRS.
For SRS registrars there is a significant change in how contacts are managed. Under SRS, contacts were embedded as fields and attributes as part of the domain name record. Under IRS, EPP contacts are managed as individual objects and must be created first before being associated with the domain name.
New to IRS is an optional fourth contact type, billing, which can be used to indicate individuals or organisations who are authorized to administer financial information for a registered domain. This contact is not published in the WHOIS.
Refer to the Contacts section for more information on contact changes.
Updating a domain¶
Domains under sponsorship of a registrar can be updated using the IRS portal or via the EPP API.
Renewing a domain¶
The term field in the SRS was based on months with a range from 1 to 120. In the IRS the unit has changed from months to years, with a range of 1 to 10. This means the minimum registration period is now 1 year.
Auto Renew + term
In the SRS, you’ve been able to preset the desired renewal length via the term field. For example, if you want a name to auto renew for 36 months, you would set the term to 36 prior to expiry.
The term field contains the registration duration for the last create or renewal;
All auto-renews will default to the minimum 1-year term;
Any renewal with a term longer than 1-year needs to done via an explicit renew command.
The daily renew domains job will be replaced and domains will be renewed within 6 minutes of expiry.
Registrars using the SRS protocol have been able to set the term to zero to trigger a system cancellation of the domain on the expiry date. A term of zero is no longer allowed so registrars will need to change their processes to send a delete request at domain expiry instead of setting the term to zero.
Potential registrar process change - billing, website, auto-renewals, cancellations
Registrar customers that have a large number of names on automatic 1 month renewals may want to consider renewing them prior to migration for variable terms to spread the renewals across a year.
Deleting a domain¶
When a domain is deleted it goes into the redemptionPeriod lifecycle state and will stay there for ninety days unless it is restored by the registrar. This is the same for both the SRS and IRS.
At the end of the redemptionPeriod there is a change in behaviour with the new IRS, the domain goes into the pendingDelete state, which is new, and the domain is assigned a To-Be-Released (TBR) session where it will get released when that session is processed. Once the domain has moved to pendingDelete state there is no option to restore it. The period between the end of the redemptionPeriod and the TBR session is currently set to a minimum of 48 hours, note this may change in the future.
For the current SRS, registrars can continue to successfully restore a domain, right up to the time it is released.
There are two other situations where pendingDelete applies in the IRS:
When a domain is deleted from addPeriod; it does not go into redemptionPeriod, but directly to pendingDelete; and
When a domain is deleted that has a Block tag on the Create event, it goes into redemptionPeriod, but when it reaches the end it does not go into a TBR session, as it is blocked from being re-created, it goes into pendingDelete.
For these two scenarios, the pendingDelete period is zero so effectively the domain is released immediately, the next housekeeper run sees that pendingDelete has expired and deletes the domain from the database. IRS housekeepers run every 5 minutes.
Transferring a domain¶
Domains can be transferred using the IRS portal or via the EPP API.
Under the IRS the transfer behaviour is much the same as the current system, however there are a couple of small differences:
When transferring a domain in redemption period (pending release), the domain will be set to registered when the transfer is complete.
If a domain is explicitly renewed by the sponsoring registrar as part of the transfer request, there is no renewal grace period. This means that if the domain is deleted within 5 days after the transfer there will be no rebate for the renewal.
For domains in the redemption period state on a transfer if no additional term is applied to the domain, a housekeeper job may be triggered to bring the expiry date on the domain up to date. See diagram below.
Potential registrar process change - no renewal grace period on a domain transfer and state change for domains in redemption period.
Restoring a domain¶
The current SRS interface does not comply with RFC 3915 and does not require both a restore request and restore report command before restoring the domain name.
The IRS requires both a restore request and restore report command before restoring the domain name.
The pending restore period, 5 days, is the time allowed between posting a restore request and a restore report. If a restore report is not received then the domain returns to a redemption state.
Registrars can issue a request and a report immediately after each other via EPP, and if using the IRS portal to restore a domain, the commands are grouped, it’s assumed that if a Registrar is going to do a restore request, they’ll want to do the report, so by clicking Restore Domain and entering the information, both are automatically issued simultaneously. They show up as two separate commands in the history. Typically a restore request and a restore report are processed within the same second so registrars should not see the pending restore status.
Suspending a domain (undelegate)¶
As noted above the delegate flag is not included in the IRS. To suspend a domain name so that it is no longer included in the .nz zone file (The domain name will not resolve in the DNS), the clientHold domain status needs to be set. This can be done via EPP or the IRS portal. To include the domain back in the .nz zone file, remove the clientHold status.
No change to the syntax.
IRS supports more algorithms than SRS (see DNSSEC Implementation in the IRS registrar guide).
IRS only supports 6 DS records, which is a reduction of the 10 SRS supports