Registry Concepts¶
Registrar Portal¶
The current registrar portal is being deprecated and replaced by the new IRS web portal. The IRS portal is significantly different; some of the key highlights of the IRS portal are:
It lets you carry out the full life cycle of domain management functions, including:
Domain search, information, create, update, renewal, transfer, delete and restore,
Contact search, information, create, update, and delete, and
Host search, information, create, update, and delete.
Provides the ability to view and acknowledge service messages,
Lets you manage users and assign role based permissions, as well as
Domain management and registrar business reporting.
Functionality in the current registrar portal which is not being provided by the IRS portal includes:
Graphical representation of domain information and reports,
List of second level names that are currently available for registration,
Conflicted domains list,
Zone scan validation report, and
Registrant data quality issues.
Reporting¶
The IRS portal can generate a number of business reports including:
Transaction Summary — displays a list of registrar transactions,
Monthly Scorecard — displays a list of complete and incomplete registrant contacts,
Registrant Profile Data Integrity — displays a list of contact profiles that have insufficient data, and
Account Measurement — displays measurement transaction activities and measurement balance for registrars.
Note
Full details of the features and functionality provided by the IRS portal and how to use it can be found in the registrar guide. The IRS portal also comes with an extensive online help.
Tip
The information presented in the new IRS portal is different to the current registrar portal. The new system provides a number of built-in reports. We also want to understand what additional information you may need, as it may be possible to add additional reports to meet your requirements.
Warning
This is a significant change for all portal users
Domain name life cycle¶
The different stages of a domain life cycle are the states that a domain name passes through from the beginning of its life cycle (the Available state) to the end of the life cycle (returning to the Available state).
Changes of note:¶
Registration grace period is now known as the “add period”.
Renewal grace period, an explicit registrar renewal is still 5 days.
Auto-Renew grace period, please note the auto-renew grace period changes from 5 days to 45 days.
Pending release is now known as “redemption period”.
Pending delete is new (see below under IRS life cycle).
Pending restore period is new — the period during which a domain name is being restored to the registry after having been in the redemption period stage and can be up to 5 days. Typically a restore is performed immediately though - see the Restoring a domain section for more info.
Note
Potential registrar process change - terminology and grace periods
SRS life Cycle¶
New IRS life cycle¶
The IRS registry platform implements a domain life cycle in accordance with Section 3.1 of RFC 3915.
The stages/states of a domain life cycle are(Note. EPP status codes in brackets):
Available - The domain name is available for registration.
Add period (addPeriod) - The grace period (5 days) after which the domain name has been added to the registry. If the domain is deleted during this period, there is a refund for the cost of the registration and the domain goes straight to a pending delete state, skipping the redmption period.
Registered (ok) - The domain name is registered and active.
Renew period (renewPeriod) - The grace period (5 days) after a domain has been explicitly renewed by the Registrar. This grace period following a domain name renewal allows the Registrar to delete the domain if necessary and obtain a credit for the cost of the renewal.
Auto-renew period (autoRenewPeriod) - This grace period (45 days) occurs after a domain has been automatically renewed by the Registry. If the domain is deleted during this period, there is a refund for the cost of the renewal.
Redemption period (redemptionPeriod) - The grace period (90 days) following the deletion of a domain name from the Registry. During this period, the domain name no longer resolves and cannot be renewed but the Registrar has the option to use the restore command to return the domain name to the registered state.
Pending restore (pendingRestore) - The period during which a domain name is in the process of being restored to the Registry after having been in the redemptionPeriod stage. i.e. the time allowed between posting a restore request and a restore report.
Pending delete (pendingDelete) - A successful Domain Delete request transitions a domain object into pending delete state within the Registry. (A domain name that has been deleted transitions from registered, to redemption, and then to pending delete.) In the pending delete state, the domain name cannot be renewed or restored under any circumstances and is in the process of being removed from the Registry database to become available when the period ends.
Registered (inactive) - The domain name is registered and inactive. The inactive EPP status code indicates that delegation information (name servers) have not been associated with the domain. The domain is not activated in the DNS and will not resolve.
Tip
pendingDelete is a lifecycle state and a domain server status. When a domain is deleted it goes into the redemptionPeriod life cycle state and is assigned a server status of pendingDelete. When a domain has completed the redemptionPeriod it goes into the pendingDelete life cycle state and has a server status of pendingDelete until the domain is made available.
Conflicted domains¶
What is a conflicted domain name?¶
In 2014 the .nz domain name space released registrations directly at the second level. At the time of this release, some existing domain name holders had rights to registering the corresponding domain at the second level. If there was more than one existing .nz domain name registered (such as “anyname.co.nz” and “anyname.net.nz” ), it wasn’t clear who should have the right to register the new “anyname.nz” .
These unresolved names that more than one party might want were called ‘conflicted’ names. The Domain Name Commission (DNC) is managing a process to have the right to the new domain properly allocated. When the DNC allocates the right to one party to register one of these domains, the domain transfers from a conflicted state to a resolved state.
There are now less than 2,000 domain names at the second level that are in a conflicted state and cannot be registered until the conflict is resolved. We will be making changes to the conflicted name process in the new system including:
How does a registrar identify a conflicted resolved domain?¶
A registrar can determine if a domain is conflicted/resolved by using the EPP domain:check command, the registrar portal domain query, WHOIS and the Availability API.
Examples of these queries is shown below.
EPP domain:check Request for checking a domain
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<check>
<domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>conflictedtestdomain02.nz</domain:name>
</domain:check>
</check>
<clTRID>check-domain-011</clTRID>
</command>
</epp>
Response returned for a conflicted domain
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:chkData>
<domain:cd>
<domain:name avail="false">conflictedtestdomain02.nz</domain:name>
<domain:reason>This domain name cannot be registered directly at the second level.</domain:reason>
</domain:cd>
</domain:chkData>
</resData>
<trID>
<clTRID>check-domain-011</clTRID>
<svTRID>CIRA-000000301701-0000000002</svTRID>
</trID>
</response>
Response returned for a resolved domain that has not been registered.
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:chkData>
<domain:cd>
<domain:name avail="true">resolvedtestdomain02.nz</domain:name>
<domain:reason>This domain has restrictions applied to it. Approval is needed from the registry.</domain:reason>
</domain:cd>
</domain:chkData>
</resData>
<trID>
<clTRID>check-domain-011</clTRID>
<svTRID>CIRA-000000301701-0000000002</svTRID>
</trID>
</response>
Response returned for a resolved domain that has been registered or any name that is registered
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:chkData>
<domain:cd>
<domain:name avail="false">resolvedtestdomain02.nz</domain:name>
<domain:reason>Registered</domain:reason>
</domain:cd>
</domain:chkData>
</resData>
<trID>
<clTRID>check-domain-011</clTRID>
<svTRID>CIRA-000000301701-0000000002</svTRID>
</trID>
</response>
Response returned for any domain that is available for registration with no restrictions
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:chkData>
<domain:cd>
<domain:name avail="true">domaindoesnotexist.nz</domain:name>
</domain:cd>
</domain:chkData>
</resData>
<trID>
<clTRID>check-domain-011</clTRID>
<svTRID>CIRA-000000301701-0000000002</svTRID>
</trID>
</response>
Registrar portal domain query
Navigate to the Domains tab in the portal. Enter and search for the domain using the search box.
Response returned for a conflicted domain. Note life cycle column indicates it is blocked and the tags column gives the reason: Conflicted domain.
Response returned for a resolved domain that has not been registered. Note life cycle indicates it is available and the tags column gives some additional information: Resolved domain with override. See registering a resolved domain below for more information.
WHOIS query
A WHOIS request will return the following for conflicted and resolved domains:
Error code: 01044
Error message: The domain name requested has usage restrictions applied to it.
Please see your Registrar for more details.
Availability query
An availability request will return the following for conflicted domains:
{
"domainName" : "conflictedtestdomain01.nz",
"statuses" : [ "BLOCKED" ]
}
An availability request will return the following for resolved domains:
{
"domainName" : "resolvedtestdomain01.nz",
"statuses" : [ "BLOCKED_OVERRIDE" ]
}
How does a registrar register a conflicted domain?¶
Registration of a conflicted domain name is not possible. The conflict must be resolved first.
The EPP response returned for a create attempt:
<response>
<result code="2306">
<msg>Parameter value policy error</msg>
<extValue>
<value>
<fury:ciraCode>8436</fury:ciraCode>
</value>
<reason>Domain name conflictedtestdomain01.nz is blocked for create.</reason>
</extValue>
</result>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>CIRA-000021384907-0000000002</svTRID>
</trID>
</response>
How does a registrar register a resolved domain?¶
The domain name holder will register the domain with the registrar of their choosing. The registrar will send through a normal domain create request via EPP or the registrar portal. The domain will be in an “addPeriod” life cycle state and a number of server status will be applied to the domain:
pendingCreate
serverHold
serverRenewProhibited
serverTransferProhibited
serverUpdateProhibited
To complete the registration, approval will be required from the registry. The registry will ensure the correct domain name holder has registered the domain before granting approval.
Note
If the registration is successful the domain is in an addPeriod state and requires secondary approval from the Domain Name Commission. The DNC will verify that the domain name holder is the correct entity that was given the right to register the resolved domain. If the verification is successful the registration will be approved and the registration will complete. If the verification is not successful the registration will be rejected.
EPP response returned for a resolved domain that has been successfully registered:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns:host="urn:ietf:params:xml:ns:host-1.0" xmlns:fury="urn:ietf:params:xml:ns:fury-2.0" xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" xmlns:fury-rgp="urn:ietf:params:xml:ns:fury-rgp-1.0" xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<response>
<result code="1001">
<msg>Command completed successfully; action pending</msg>
</result>
<resData>
<domain:creData>
<domain:name>resolvedtestdomain02.nz</domain:name>
<domain:crDate>2022-07-07T02:52:00.527Z</domain:crDate>
<domain:exDate>2024-07-07T02:52:00.527Z</domain:exDate>
</domain:creData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>CIRA-000000302901-0000000002</svTRID>
</trID>
</response>
</epp>
Note
“action pending” is returned in the message.
EPP response returned for an unsuccessful registration attempt of a conflicted domain:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:host="urn:ietf:params:xml:ns:host-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" xmlns:fury="urn:ietf:params:xml:ns:fury-2.0" xmlns:fury-rgp="urn:ietf:params:xml:ns:fury-rgp-1.0">
<response>
<result code="2306">
<msg>Parameter value policy error</msg>
<extValue>
<value>
<fury:ciraCode>8436</fury:ciraCode>
</value>
<reason>Domain name conflictedtestdomain02.nz is blocked for create.</reason>
</extValue>
</result>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>CIRA-000000302703-0000000002</svTRID>
</trID>
</response>
</epp>
Locking¶
Registry lock (new feature)
Registry lock is a service that helps protect domains against malicious actors and unintended changes that may affect the stability and availability of a website. The .nz registry lock service adds a layer of security checks to safeguard change requests to a .nz domain name before executing them. The additional security checks make it deliberately harder to cause damaging changes to a domain name.
The registry lock service will not be active at the time of Go-Live. A decision on when this service will be launched will be made after the Go-Live date.
Note
Future feature - This registry lock service is for registrars to provide to their customers and it is different to the registry lock that is used in the current SRS. Please refer to the compliance lock below.
Compliance lock (new feature)
This compliance lock feature replaces the registry lock that was used in the SRS.
The Domain Name Commission have a complaints and disputes process to help improve the safety of the .nz space. Complaints and disputes that the Commission assist with are broadly divided into three main categories:
Complaints linked to domain name registration details,
Dispute Resolution Service complaints, and
Any other complaints, including complaints about providers of .nz domain names.
In some case an investigation may be required to resolve a complaint or dispute. Part of the DNC investigation process may lead to the locking of the domain name and associated contacts. This lock is called a compliance lock. A compliance locked domain cannot be transferred (registrar or registrant), cancelled or released and the registration details cannot be modified.
Registrars will be notified of the lock/unlock by services messages to their poll message queue which is accessible via EPP or the IRS portal. Example messages:
Domain xxxxxxxxxxxx.nz has been locked and all associated contacts have been copied and locked. Changes are not allowed. Contact the registry/regulator for questions.
Domain xxxxxxxxxxxx.nz has been unlocked. Changes are now allowed. Contact the registry/regulator for questions.
Registrant lock (for information only)
Registrant lock allows Registry Support to apply a lock to a Registrant for a domain so that no updates to the Registrant ID or Registrant Name can be made through either the IRS portal or EPP.
There are currently no plans to use this feature in the IRS.
Note
Registrant lock will not be used
Billing¶
Billing Cycle
Under the SRS, monthly billing would occur around the 6th day of the following month, to ensure any subsequent grace period actions were accounted for in the billing run.
This changes with the IRS, with the billing cycle being the first of every month, and any subsequent grace period actions, triggering rebate transactions, being applied to the following month’s invoice.
Registrant reference (deleted)
In the SRS the registrant reference (reg_customer_ref) is an optional field that registrars populate with reference information for the registrant, e.g. a customer number, that flows through to the invoice. It’s free-format and is associated with the domain. This field will not be available in the IRS and the data will not be migrated.
Note
This means that the registrant reference will not be present in the CSV file produced with the invoice.
Fees
The minimum domain name term for registrations and renewals is changing from monthly to yearly. The current wholesale fee for 1 month is $1.50 and for 12 months it is $18.00.
A table of domain registration and renewal fees, and any other fees we decide to add in the future, will be available in the IRS portal.
The current minimum monthly fee of $48.00 is also being removed.
Invoicing
Our invoice statements are undergoing a redesign.
The billing polices and procedures have been updated in Version 4.5 of the .nz Connection Agreement (see section 3.0 Charges).
There will be a small change to the invoice process. For the current invoice we include all transactions that occurred within a NZT month. For the new system this will change to all transactions within a UTC month. We are planning to issue the new invoices at the start of a month, which should be earlier than the current invoice that is issued after the 5th day of the month.
Note
Potential registrar process change - invoicing:
all transactions within a UTC month.
no minimum monthly fee charge
grace periods change
Domain automation jobs¶
In the SRS there are two domain automation scheduled jobs run by the registry system, renew domains and release domains. These jobs are replaced in the IRS by an automation system called housekeepers.
IRS uses housekeepers, set to run at periodic intervals, to transition domains through lifecycle phases. Specifically the domain_job_frequency housekeeper is responsible for all domain related housekeeper operations, including:
Expired status:
Deletes domain statuses, other than pending delete, if their expiry date has passed. If there are no remaining statuses for the domain, the “ok” status is added.
Expired lifecycle stage:
Transitions domains from one life cycle state to another, including statuses. It may attempt to renew a domain if conditions are met.
Cancelled TBR (droplist) session:
When a TBR session is cancelled, any remaining domains are moved to the next TBR session, if it exists. The domain’s stage of life expiry date may be affected.
The domain_job_frequency housekeeper is set to run every 320 seconds (~5.34 minutes).
This housekeeper changes current state operations, replacing the following SRS scheduled jobs:
Renew domains - daily at 2330, and
Release domains - daily at 0029.
It also replaces current immediate system actions associated with lifecycle transitions, including:
Immediate renew (triggered by an update to an expired domain), and
Immediate delete (triggered by a cancel during the add grace period).
Note
Potential registrar process change - daily renew and release domains processes and some immediate system actions change to periodic intervals (approx. every 5 minutes)
Protocol¶
SRS¶
The SRS protocol has been retired and will not be supported in the IRS.
EPP¶
The EPP protocol is supported in the IRS.
Objects¶
TThe SRS EPP used two object types: domain and contact.
The IRS EPP protocol uses three object types:
Domain objects contain information about domain names,
Contact objects contain information about the contacts that are associated with domain names, like the registrant, the admin contact, the technical contact and the new optional billing contact; See the Contacts section for more info, and
Host objects contain nameserver information.
Object Sponsorship
In the IRS registry, each object is required to have a sponsor and the sponsor, by default, is the registrar who creates the object.
Only the sponsor can change an object, i.e. update, renew, delete.
The sponsorship of a domain can be changed by a domain transfer.
A contact object can be associated with multiple domains belonging to the same sponsor. The sponsorship of a contact cannot be changed. Contacts associated to domains will be copied on transfer, not moved, to the new registrar.
A host object may be associated with multiple domains, with the same or different sponsors. Hosts are transferred when the superordinate domain is transferred.
Date Fields¶
For our current system we present all date/times as NZT with the UTC offset, e.g. (UTC +12/UTC+13).
This is changing in IRS and date/times are expressed in UTC (Coordinated Universal Time), with a special UTC designator (“Z”) at the end, e.g. 2021-11-25T21:31:29.425Z.
Tip
This includes EPP and WHOIS the IRS Portal.
In the IRS portal, however, two dates will be displayed in the search result, date columns: UTC and the client’s local time.
Tags¶
Tags is a new feature in IRS. Tags are used by the registry to identify (tag) domain names and then apply restrictions, overrides or special functions to those tagged domain names.
A Block tag is used to restrict any actions from being carried out with specific domain names and this will be the main type of tag that we will be using in IRS. For example, we will be using a blocked tags to restrict domain names that are prohibited by .nz policy from being registered such as government.nz. If a registrar attempts to register one of these restricted domains they will get a blocked operation message returned.
There are several other types of tags and full details can be found in the portal registrar guide.