FAQ/Help

The Individual Registrant Privacy Option (IRPO) is an optional feature available for individuals who are not in significant trade. Choosing to use IRPO withholds the telephone number and contact address information provided to the .nz Query Service.

Our introduction of the Individual Registrant Privacy Option follows a comprehensive review involving five public consultations and calls from many in the Internet community for greater privacy protection. More information about the 2015-16 review can be found at https://dnc.org.nz/whois-review.

A domain name registration data query is our new proposed term for what is currently known as a WHOIS search – where people can search for the registration details of a domain name. Query Service is our new proposed term for what is currently known as the WHOIS Service.

When registering a domain name it is still necessary to provide your contact details including telephone number, physical address and email address to a .nz authorised Registrar.  This is a requirement of .nz policy and ensures Registrars can contact their registrants in relation to the administration of their domain name.

It means that your telephone and contact address information won’t be visible when somebody does a domain name registration data query (currently known as a WHOIS search) on your domain name. Importantly, that information still exists in the register of .nz domain names – it just won’t be publicly visible.

When the Individual Registrant Privacy Option becomes available you’ll be able to take it up through your .nz authorised registrar (domain name provider). It will involve a declaration through your .nz authorised registrar that you’re an individual registrant and not using your domain name for significant trade.

When you’ve made the declaration, your telephone and contact address information will be withheld from public display in the .nz Query Service (currently known as the WHOIS).

The Registrant Privacy Option will be available from some .nz authorised Registrars from 28 November 2017. All registrars are required to offer this option by 28 March 2018.

The DNCL website will display a list of all .nz authorised Registrars who are offering this service from 28 November. You can view a list of .nz Authorised Registrars at the following link: https://dnc.org.nz/registrars

If you’re interested in being updated about the implementation of the Individual Registrant Privacy Option, you can sign up to our newsletter at https://dnc.org.nz/subscribe.

If you are concerned about your address information being displayed before this change is available through your domain name provider, you are able to request our Provisional Address Masking Option, details of which are at https://dnc.org.nz/pamo.

An automatic application of the Individual Registrant Privacy Option to all individual registrants would cover those individual registrants who use their domain name for significant trade purposes. Those who use their domain name in this way should not be able to the Individual Registrant Privacy Option. Many domain names are registered in the name of individuals but used for business or trading – these activities carry with them a lesser need for the Individual Registrant Privacy Option when it comes to display of contact information. We’re also aware that there are some individual registrants who still want all their information publicly displayed.

This hasn’t been finalised yet. We are looking to make it as easy as possible in 2018. We are keen to make the transition as easy as possible but need to consider the impact of any implementation on registrars.

DNCL’s default position is information withheld because of the Individual Registrant Privacy Option will not be disclosed unless authorised or required by law.

In all our decisions about the release of withheld information we are guided by the Privacy Act 1993 in particular Principal 11 and relevant sections of this Act 

The Privacy Act 1993 places an extremely high threshold on the release of withheld data.

More details on reporting will be available soon.

Our transparency reports about applications for release of withheld information have not yet been finalised but may include the number of times we’re asked to release withheld information, type of requestor (e.g. a member of the public or organisation) and how many times requests are approved or denied. We will release our transparency reports on a regular basis and make them available on our website – http://dnc.org.nz.

The DNCL must establish that there is a legitimate need for the information.

Where this has been established, the DNCL may enter in to a MOU with organisations responsible for maintaining the integrity of the internet.

There can be two different sorts of MOUs – those with approved entities having automatic access and those where approved entities have streamlined access to the withheld information. Automatic access will be restricted to approved entities tasked with maintaining cyber security, and an extremely high threshold will be adopted before such an MOU is entered into. There is also the additional requirement that any entity that holds an MOU with the Domain Name Commission will be held accountable for their requests through transparency reporting.

The MOUs will set out clear responsibilities and expectations around those entities’ ability to access withheld information. We’ll work closely with them to make sure they’re meeting our expectations. This is likely to involve compliance checks to ensure data is accurate, complete and secure. If our monitoring uncovers any misuse, we may end the MOU and take away the MOU holder’s ability to access withheld information through any arrrangement.

Requestors will have to make a declaration on the application form limiting the use to the purposes for which it is sought and that the withheld information will not be used, disclosed, published or disseminated for any other purpose. If the withheld information if misused, DNCL may refuse to accept further requests from the Requestor and may also lay formal complaints with other appropriate agencies such as the Privacy Commissioner.

If you’ve got a question that isn’t covered here you can ask by using this form or emailing info@dnc.org.nz.

The Domain Name Commission Limited (DNCL) is a wholly-owned subsidiary company of InternetNZ. DNCL is responsible for the day-to-day oversight and running of the .nz domain name space. 

As the overseer of the .nz domain name space, DNCL:

• authorises Registrars 
• monitors Registrar activities and their compliance with .nz policies
• handles complaints that arise in the operation of the .nz market 
• protects the rights and relationships of all parties in the .nz market  - including Registrars, Registrants and Registry
• administers the .nz Dispute Resolution Service.

DNCL does not:

• get involved in matters regarding the content of .nz websites
• get involved in matters relating to the illegal or malicious use of .nz domain names, such as phishing 
• register .nz domain names for Registrants. This is done on behalf of Registrants by Registrars (domain name providers).

No. DNCL is part of the InternetNZ Group, independent of the New Zealand Government. More information about the InternetNZ Group and the structure of .nz can be found at https://internetnz.nz/about-us/internetnz-group. 

.nz policies are developed in an open and transparent manner, involving public consultation with the local Internet community. See the Policy Development Process for how this works. 

Anybody is free to identify a .nz policy change and notify DNCL. This can be done by emailing policies@dnc.org.nz. DNCL will consider the rationale for the suggested change and may initiate a public consultation process.

Registrants need to be identifiable individuals over 18 years of age or properly constituted organisations. Registrants do not need to be based in New Zealand nor does their domain name need to be hosted in New Zealand.

Talk to your .nz Registrar. Only your Registrar can amend the details for your .nz domain name. Nobody else has access to the register to be able to amend your details for you. DNCL cannot amend your details.

The easiest way to find out the name of your registrar is to use the "search domains" function at the top of this page. If you enter the first part of your domain name (the dnc part of dnc.org.nz), select the appropriate .nz domain name from the list, and click ‘More details’. You will be shown the details associated with your domain name. The registrar details are in the second group of fields shown.

Before registering a .nz domain name, you must first verify that the name is available. You can do this through the search domains function at the top of this page, or through similar searches provided by a number of commercial organisations.

If the domain is already registered to someone else (ie. the Status is not 'Active'), you could wait until it becomes available again, contact the current registrant directly to see if they are interested in transferring the name to you, or lodge a complaint using the Dispute Resolution Service if you feel that the current registration is unfair.

If the domain name is available, you should contact one of the authorised registrars listed on this site and make arrangements for them to register the name on your behalf. Many registrars allow you to register domain names with them immediately through automated functions on their web sites. Make sure you fully understand the registrar's terms and conditions and remember, act promptly because names are registered on a 'first come, first served' basis. More information can be found in the .nz policies.

A registrar is an entity authorised to access the .nz register to register and maintain domain names on behalf of registrants. Authorisation to be a registrar is granted by the DNC after strict criteria are met, following which an agreement for connection to the SRS is signed with InternetNZ.

A list of authorised registrars is maintained on this page.

You are free to transfer your domain name to another registrar at any time, except during the first five days after your domain was registered.

To transfer, you’ll need to contact your current registrar and get the UDAI (Unique Domain Authentication ID) for your domain name. Your registrar is obliged to make it available to you promptly upon request. Please note that transferring your domain name does not necessarily absolve you of any contractual obligations you may have entered into with your old registrar.

More information can be found in the Operations and Procedures Policy.

Any complaint you might have with regard to the management of your domain name should be taken up with your registrar. Only after you have exhausted all avenues of resolving the problem with your registrar, and any other parties involved, should you take your complaint to the DNC.

Further information regarding what sorts of complaints the Domain Name Commission can help with can be found here. 

Registration of your domain name is not directly connected with the hosting of your web site or email address. Registration entitles you to use the domain name for the registration term and to have the domain name delegated to an IP Address.

Any issues with regard to your web site or email address should be directed to those parties with whom you have made hosting arrangements.

Registering a domain name is akin to obtaining a licence. As long as the domain name is kept current, you can continue to use it.

Domain names are not able to be "owned" by any party. You may choose the registrar you wish to maintain the domain name on your behalf and are free to transfer to another a registrar at any time.

You also have the right to expect that parties authorised to access the register will not use your personal details for targeted contact campaigns. More information may be found in the .nz policies on this site.

Your core responsibilities are to keep all information about your domain name current and accurate, and to pay, as they become due, all the charges associated with the domain name.

In addition, you must comply with the relevant .nz policies and satisfy yourself that your use of the domain name will not infringe anybody's intellectual property. Your obligations are defined in detail in the agreement you have with your registrar.

When you register a .nz domain name, you are accepting that the details in the register concerning your domain name are available to all as a matter of public record.

This information consists mainly of contact details, relevant dates, and name server details. No financial information is involved.

The information may be used by others to contact you regarding the right to use the domain name, or on technical matters relating to the domain name. It could also be used by law enforcement agencies pursuing enquiries relating to the domain name. Parties authorised to access the register are forbidden from using your personal details for targeted contact campaigns.

In consultation with Treasury, DNCL has developed a process for updating .nz domain names where the Registrant company has been struck off the New Zealand Companies register.

This is necessary because any .nz domain name held by a struck off New Zealand company vests in the Crown. For details please email info@dnc.org.nz

Information about the retail and wholesale cost of a .nz domain name, over time, can be found here. 

The WHOIS is a publicly available search service that lets people find information about a domain name listed in the .nz register. Using the WHOIS is commonly known as a ‘domain name search’. You can find out more about doing a WHOIS search here.

If you have a question which isn't covered above, please email info@dnc.org.nz.

There are a number of things you need to do to become an authorised registrar:

1. Review both the Registry Documentation, this includes the technical information potential registrars would require to connect to the SRS; and the .nz Policies and Procedures, Agreements and Forms that apply to the .nz environment.
    
2. Ensure that the Terms and Conditions agreement you will require your customers to sign up to meet the minimum requirements specified in the Registrant Core Terms and Conditions document.
    
3. Complete the application for authorisation as a registrar form (Form AOR1) and send with any attachments, plus a cheque for $3,000 (excluding GST) to the address detailed on the form.
    
4. Respond to any requests or directions by the DNC to ensure your application is processed in a timely manner.
    
5. If authorisation is granted, complete the application for connection to the .nz registry form (Form CON1) and send to the address detailed on the form.
    
6. Respond to any requests or directions by the Registry Manager to ensure your application is processed in a timely manner.
    
7. Once connected, if you want any existing domain names to transfer across to you from another registrar, you will need to complete the process outlined in the Operations and Procedures policy.

The application fee for authorisation as a registrar is $3,000 (excluding GST). The domain name fee is set at $1.25 (excluding GST) per domain name per month. The registry charges a minimum monthly fee of $48 (excluding GST).

You can apply to become a .nz authorised registrar at any time.

Yes, they can. There is no distinction drawn between domestic and foreign entities as far as access to the .nz register is concerned. Any foreign registrar is bound by the same policies and procedures as domestic registrars, including (for example) the exclusive jurisdiction of the New Zealand courts, and the inclusion of the core terms and conditions for registrants.

Once authorised and once you have organised your connection with .nz Registry Services (NZRS), you will be given access to the SRS test platform to test your software.

Once you are authorised and have completed testing your systems to the satisfaction of NZRS, you will be able to connect to the production SRS.

No. If you want to become an authorised registrar you will need to apply to DNCL as outlined in the published Operations and Procedures policy.

You can follow the process outlined in the Operations and Procedures policy to take your names with you. Whether the process applies to you depends on the billing arrangement you have with your customers. Check with DNCL about this.

A reseller agreement relates to the services your registrar offers you as a reseller. The authorisation application fee relates to the costs associated with the DNC assessing the application to decide if you meet the standard to become an authorised registrar. Becoming a .nz authorised registrar has no effect on your relationship with your existing registrar and their provision of resale services to you; you may continue to act as a reseller and simultaneously act as a registrar.

You are able to establish a reseller relationship with any .nz authorised registrar which offers reseller services. There is no need to become a .nz registrar to provide registration services in .nz.

The zone file is pushed to the .nz nameservers on the hour, every fifteen minutes. For more information regarding the zone file please see the Operations and Procedures policy.

.nz Registry Services (NZRS) is bound by an agreement which sets out the detailed service requirement specifications. These requirements are identified in the Service Level Agreement. NZRS reports against the SLA on a monthy basis and this information is published in the .nz newsletter.

If you have a question which isn't covered above, please email info@dnc.org.nz.

The registration of a shorter variant at the second level does not affect any existing registrations at the third level. A registration of the shorter variation is in addition to, and not as a replacement for any registrations at the third level. 

As with other .nz domain names, there is no requirement for a registrant to make use of a domain name they have registered. 

A UDAI is a code required to validate a request to transfer a .nz domain name from one registrar to another. For those with a conflicted name a UDAI is also needed to manage your Conflicted Name Preference with DNCL. 

For security reasons UDAIs expire after 30 days. If you have a UDAI already you can check its validity by using our tool here: https://www.dnc.org.nz/udai If you need a new one you need to contact your Domain Name Provider.

If you would like more information about what a UDAI is, then please feel free to click the following link: https://www.dnc.org.nz/udai-info

A conflicted name is a shorter .nz name direct at the second level that has equivalents registered in at least two second levels. E.g. for anyname.nz, one registrant may hold anyname.co.nz while others may hold anyname.org.nz and anyname.school.nz.

If you want to try and get the shorter version of the name you will need to go through the Conflicted Name Process. 

If the shorter version of your name is conflicted you can choose to take part in the Conflicted Name Process by going to the Lodge your preference page and lodging one of the following preferences:

1. You want to try and get the shorter version of your domain name
2. You don't think anyone should get it
3. You don't want it and don't care who gets it

Once you've lodged your preference, a confirmation email will be sent to the registrant email address we have on record. 

The Lodge your preference page shows people with conflicted names how to find the contact details of those they are in conflict with. This allows them to directly discuss with one another about who might get the name direct at the second level.

If the conflicted domain name resolves, you will have 2 months from the date and time that the name resolves to register that domain name with a registrar

If a clear outcome doesn't result from either the online system or through private discussions, the Domain Name Commission may offer a facilitation service.

Please note that if someone who is conflicted allows their existing domain name to lapse, they will no longer be in the conflict process.

You can find out who you are conflicted with by going to the Conflicted name process page and entering your domain name.

Yes. This is helpful because you can then find out what they might want to do and try to work out any issues there might be if more than one of you wants the name.

In cases where people can't decide who should get the conflicted name, either: DNCL may offer a free facilitation service to try and work it out; or the name won't become available at the second level at all.

Yes. You must have lodged your preference for any conflicted domain name by the 1.00 p.m. 18th October 2017. You can lodge your preference using your UDAI here 

If you haven't lodged your preference by 1.00 p.m.18th of October, you will lose your rights to the domain name and you will be removed from the conflicted names process.

 

If the person you're conflicted with stops the registration of their existing domain name and that name lapses, you will no longer be conflicted and may then be able to register the shorter version of your name direct at the second level. If this is the case, you will have 2 months from the date and time the Domain Name resolved to register the domain with a registrar. 

Conflicts stop when all parties to the conflict have reached agreement on who will have rights in the name. If a conflict isn't resolved, the name will be unavailable for registration.

In some scenarios, it could be that you have registered all the conflicted domain names and so technically are conflicted with yourself. An example of this is you having registered both anyname.co.nz and anyname.org.nz, with no other version of anyname in the .nz domain name space.

If this was the case - and supposing you wanted to register the shorter version of your .nz name direct at the second level - when going through the conflicted name process opt for one of your conflicted domain names to want to be registered directly at the second level and the others not to.

To resolve this type of self-conflict, go to the Lodge your preference page and:

• validate the first name using its UDAI
• select "I want to try and get the shorter version of my domain name"
• validate the remaining names, one at a time, using their UDAIs. Select "I don't want the shorter version of my domain name and don't care who gets it" for each of these names

This will resolve the conflict and your registration of the name will be able to proceed and you will have two months from the date that the domain name resolved to register it with a registrar.

Only names registered before 30 May 2012 are eligible to take part in the conflicted name process.

For reasons of fairness, where there is more than one Registrant competing for a .nz domain name to be registered directly at the second level DNCL does not believe preference could be given to the oldest registration.

Similarly, DNCL does not believe one second level should have preference over any other. For example, the Registrant of anyname.co.nz should not be treated differently to the Registrant of anyname.school.nz.

Within the .nz domain name space no preference is given to people who have rights in a name (such as a company or trademark owner).

However, anyone who believes they have rights to a .nz domain name that someone else has registered can use the free-to-file Dispute Resolution Service (DRS). Information about this service can be found here. 

In the .nz domain name space, registrants are under no obligation to ‘use’ a domain name they’ve registered - e.g. for a website or email address. This includes those involved in a conflict set. 

Until a conflicted name is resolved – that is, when all those involved have lodged their preference at www.dnc.org.nz for who should get the shorter name – it will be unavailable for registration or use. 

You’re free to negotiate with the other party involved and encourage them to lodge their conflict preference. You can find their contact details by using the ‘search domains’ tool at dnc.org.nz.

There is no cost to lodge a preference for a conflicted domain name. If you were to register a conflicted name once resolved there will be registration costs involved as with any other .nz domain name. Conflicted names can only be registered once the conflicted parties all come to agreement. 

The Domain Name System (DNS) is like the white pages for the Internet – mapping the Internet Protocol (IP) addresses to domain names that are easy to read.

For example the domain name for this website is www.dnc.org.nz, and the website is located on a computer server that has the IP address 202.78.240.52.  It is the DNS that translates that domain name into the IP address, so that your browser can find the location of the server to request the website you want to view.

The DNS was designed early in the history of the Internet and was not designed with security in mind.  Vulnerabilities exist in the DNS that can be exploited allowing attackers to intercept, re-direct, or modify your Internet traffic. 

DNSSEC was developed in response to these vulnerabilities.

The Domain Name System Security Extensions (DNSSEC) have been developed to improve the security of the Domain Name System (DNS) and provide increased protection for activities such as browsing the Internet and email.  DNSSEC is in the process of being rolled out internationally.

DNSSEC ensures that the website displayed on your computer really is the genuine website that you intended to visit.  It works, in simple terms, by using encoded “keys”, similar to passwords, that your web browser looks up in the DNS to verify that you are viewing the genuine website.

The Internet’s root zone was signed in 2010, and increasing numbers of Country Code Top Level Domains (ccTLDs) and Generic Top Level Domains (gTLDs) are now being signed.

.nz, a ccTLD, has signed .nz and all of the second level domains such as .co.nz, .govt.nz and .org.nz.

Registrants can now decide whether they wish to deploy DNSSEC for their domain names to provide these assurances to visitors to their site.

While every website could benefit from implementing DNSSEC the priority should be for those websites that are concerned about the integrity of their domain name, such as those that process financial and personally identifiable information, and sites that are at a higher risk for malicious activity.

DNSSEC has been developed to provide authentication and integrity to the DNS to mitigate threats (listed below) , while ensuring that backwards compatibility is maintained.  

Origin Authentication and Data Integrity

DNSSEC-capable resolvers are able to digitally verify that the DNS data they receive is identical to the information on the authoritative DNSSEC-capable name server.  This is done by authenticating the origin and integrity of DNS data as it transits the Internet.

Authenticated denial of existence

DNSSEC-capable resolvers are able to determine whether or not a resource, such as a name server, actually exists.

One example of the benefits that DNSSEC provides is that owners of websites and email servers that have implemented DNSSEC, will have a higher degree of certainty that visitors to their website and emails destined for their email servers, will not be redirected elsewhere.

DNSSEC does not provide confidentiality for data that is transmitted.

The short answer is yes, as DNSSEC and SSL provide different types of protection.  SSL aims to provide data confidentiality by encrypting the connection between websites and the web browsers of its visitors.  DNSSEC provides Origin Authentication of DNS data, Data Integrity, and Authenticated Denial of Existence.

Vulnerabilities in the DNS are being actively exploited by attackers. These attacks are often undetectable to users. The attacks, which DNSSEC addresses, can be categorised into the following:

• DNS Spoofing (malicious cache poisoning)
• Malicious Resolvers
• Man in the Middle (MITM) Attacks

This is where a DNS name server is manipulated into accepting and storing false data that is not from a trusted DNS source, and reissues that false data. 

One way this is used by attackers is to modify the IP address for a website, so that visitors to that website are unknowingly redirected to a fraudulent destination selected by the attacker.  For example, criminals may redirect users to a fake banking website. They can then harvest all of the usernames and passwords entered on the fake website, and use them on the legitimate website to withdraw funds.

A resolver is the client-side or local part of the DNS, and initiate DNS queries to lookup the IP address of a given resource, such as website.  As the DNS is a hierarchical system many DNS Servers can be involved in the lookup and DNS servers in the chain can also act as resolvers as they pass along the lookup request. 

Malicious resolvers provide fraudulent DNS responses in an attempt to redirect your Internet traffic to a fraudulent destination or website.

This is where an attacker is able to redirect, intercept, and modify network traffic.  Because DNS does not provide any data integrity checks an attacker can intercept, and modify, legitimate DNS requests or responses.  This can also result in an attacker redirecting you to a fraudulent destination of their choosing.

Even a single compromised DNS name server can have a large scale impact because one DNS server can serve many thousands of DNS requests.

The following scenario illustrates how vulnerabilities in the DNS are being exploited by miscreants and how DNSSEC mitigates those threats.

The goal of the attacker is to redirect the customers of a banking website to a fraudulent website, under the attacker’s control, to harvest customer’s credentials.  In the following scenario neither the target bank nor ISP have implemented DNSSEC.

• The attacker sets up a fake banking website that looks identical to a legitimate bank’s website.
• The attacker then inserts fraudulent data into an ISP’s DNS servers, with the IP address for their fake website. 
• When any customers of the targeted ISP enter the website address for the targeted bank into their browser, the ISP’s DNS server provides the customer with the fraudulent IP address, redirecting their customers to the attacker’s website.
• When the customers log into the fraudulent website their usernames and passwords are captured and recorded by the attacker.
• The attacker then uses those credentials to log into the targeted bank’s website, masquerading as a legitimate user, and transfers funds to an account they control.

In this scenario if either the bank or the ISP had implemented DNSSEC then the ISP’s customers may not have ended up being redirected to the attacker’s fraudulent website.

• If the bank had implemented DNSSEC, the customer’s computer may have detected the fraudulent IP address when it attempted to validate the response from the ISP’s DNS server. 
• If the ISP had implemented DNSSEC then the ISP’s caching server would have rejected the attempt to poison its cache. 

Two real world examples similar to the example above can be found here:

• Brazilian Bank Bandesco
• Irish ISP Eircom

When you deploy DNSSEC on a domain name it is referred to as “signing” the domain name.  You can contact your .nz Registrar to see if they offer DNSSEC services, or you could contact a third party DNS Operator who may offer DNSSEC services. You should be aware that the Domain Name Commission does not have any formal relationships with DNS Operators who are not .nz Authorised Registrars.  Therefore the DNC cannot mandate their cooperation and participation in the management of DNSSEC signed domain names.

The Domain Name Commission's website has a list of all Authorised .nz Registrars. The list shows which registrars offer DNSSEC and which are 'DNSSEC Friendly'.

This status identifies Registrar’s that meet a higher level of service relative to offering DNSSEC services in the .nz space.  The Domain Name Commission recommends that Registrants looking to deploy DNSSEC look for Registrars who are DNSSEC Friendly. 

This status identifies those Registrars who have the capability to update the SRS with DS Records.

DNSSEC uses public key cryptography to digitally sign DNS data.  DNSSEC-capable resolvers are able to verify whether the data contained in a DNS response comes from an authoritative DNS server and whether it has been altered.

DNSSEC works in a chain, and each part of the chain must be signed for the whole signature to be valid.  DNS Resolvers need to be able to fetch the public key and verify that it can be trusted. 

The public key to validate a domain name’s data can be obtained from the domain name’s authoritative servers.  To establish the trust on a key, you can get a copy through an offline trusted channel or use a ‘Chain of Trust’. 

A ‘Link of Trust’ is established between a child zone and its parent.  The child zone provides a digest of the keys, known as a Delegation Signer (DS) Record, to the parent and the parent validates and signs it, using its own key.  The step is repeated up the hierarchy creating a ‘Chain of Trust’ that can be followed.

For example the Chain of Trust for dnc.org.nz is established through the keys for dnc.org.nz being signed by the .org.nz zone keys.  The keys for the .org.nz zone are signed by the .nz zone keys and the keys for the .nz zone are signed by the keys for the root '.' (dot) zone.  This forms the Chain of Trust that can be ‘walked’ from the DNS root zone down to dnc.org.nz.

As DNSSEC uses public key cryptography, the existence and management of a cryptographic key for each domain name that implements DNSSEC is required.

Registrants can elect to operate their own DNS or they can delegate this responsibility to a third party called a ‘DNS Operator’. 

At some point after DNSSEC has been implemented on a domain name, and it’s DNS records have been signed, changes to the DNS data may be needed.  The changes may be DNSSEC related, such as updating the key used to sign the data, or transferring a domain name registration to another Registrar.

These changes will need to be properly managed and additional steps are required to ensure that resolution errors do not occur.  Resolution errors may result in DNSSEC-capable resolvers being unable to verify the information that has been sent to them, and this may result a domain being unreachable for a period of time.

A DNS Operator could be the Registrar for your domain, a Registrar who does not manage your domain, a hosting provider, an ISP, or some other third party that offers DNS management services.

DNSSEC uses cryptographic ‘keys’ to to verify whether the data contained in a DNS response comes from an authoritative DNS server and whether it has been altered.

Registrants or DNS Operators need to store the public part of a cryptographic key in a DNS Resource Record, called a DNSKEY, in the zonefile for the domain.  To enable the DNSKEY to be authenticated, a DS (Delegation Signer) Record needs to be generated and added to the .nz Registry.  Only DNSSEC capable Registrars can add this information to the Registry.

Registrars who are able to handle and process DNSKEYs and DS Records are listed on the .nz Authorised Registrars list.

The process of updating of DNSSEC keys is referred to as rolling the keys, or a key rollover.

ISPs often provide caching recursive DNS services (DNS resolvers) for a large number of their customers. As a result ISPs are a crucial step in ensuring that the chains of trust created by DNSSEC are actually used. This is known as DNSSEC validation. The most important benefit of DNSSEC validation is that it protects users effectively against forged DNS responses.

The technology surrounding DNSSEC validation is mature and ISPs are encouraged to deploy DNSSEC validation on their DNS resolvers. Experiences and comments from some ISPs in NZ that have enabled DNSSEC validation can be found here /content/Firsthand_experiences_with_DNSSEC.pdf.

The cost of deploying DNSSEC validation is usually low to very low, DNSSEC functionality has been standard in DNS resolvers for some time. A white paper on DNSSEC deplyoment (covering BIND, Unbound and Microsoft Wndows Server 2012) is available here:
http://www.internetsociety.org/deploy360/resources/deploying-dnssec-validation-on-recursive-caching-name-servers/

Registrants can elect to operate their own domain name system or they can delegate this responsibility to a third party called a ‘DNS Operator’. A DNS Operator could be the Registrar for the domain, a Registrar who does not manage the domain, a hosting provider, an ISP, or some other third party that offers DNS management services.

It is important for the implementation of DNSSEC that there is a mechanism to encourage the cooperation and participation of DNS Operators, given the lack of a legal relationship between DNCL and non-Registrar DNS Operators. 

DNCL has established a contact repository of DNS Operators who offer DNSSEC services. The contact details of DNS Operators who provide them to DNCL will be made available to Registrars and other DNS Operators upon request. DNS Operators can email DNCL (info@dnc.org.nz) with their details to be included in the contact repository. 

NZRS has also provided this information regarding the requirements for DS records:

/content/DNSSEC_Requirements_for_DS Records.pdf

DNSSEC related policy can be found in the following .nz policy:

• .nz Operations and Procedures Policy

The following is a summary of the DNSSEC elements contained within the .nz Policies. 

.nz Operations and Procedures Policy

The .nz DNSSEC policy is found in the Operations and Procedures Policy.

When registering a new domain name the registrar will supply the following data:

• Domain name.
• Name server list. (Optional)
• Registrant Name.
• Registrant contact details.
• Registrant Customer ID. (Optional)
• Administrative contact details.
• Technical contact details.
• Billing term.

and, if applicable:

• DS Record List.

Registrars will be required to maintain the details of the domain names for which they are the registrar.  They will be able to amend/update the following fields:

• Name Server List.
• Registrant Name.
• Registrant Contact Details.
• Registrant Customer ID.
• Administrative Contact Details.
• Technical Contact Details.
• Billing Term.
• DS Record List.

In relation to managing DNSSEC signed domain names, Registrants, or their DNS Operator, will be responsible for:

• generating and managing their keys;
• generating the DS Records; and
• determining how often they perform key rollovers.

When a Registrant elects to un-sign a DNSSEC signed name, the Registrar will remove the DS Records for that name as soon as it is practical to do so.

Name Server Updates

Registrants can elect to operate their own domain name system or they can delegate this responsibility to a third party called a ‘DNS Operator’.  The DNS Operator could be the Registrar for the domain, a Registrar who does not manage the domain, a hosting provider, an ISP, or some other third party that offers DNS management services.

When a change of DNS Operator for a signed domain name is required and both the current and proposed DNS Operators are Registrars, then the cooperation and participation set out in 9.3 is required.

Domain Names with DNSSEC enabled

Prior to a name server update, the losing DNS Operator must provide the zone information for the domain name when requested to do so, and accept and add the new DNSKEY to the zone for the domain name, re-sign it and continue to serve this until they are notified the change is complete.

The gaining DNS Operator then provides the new DS Record to the losing DNS Operator who provides it to the Registry.  The name servers for the domain name can then be updated with the Registry.

Following the name server update, the gaining DNS Operator must delete the old DS Record and DNSKEY provided by the losing DNS Operator.

The losing DNS Operator must remove the domain name from their name servers when requested, but must not remove it before being requested to do so.

The Policy has a Clause (13.6) that notes:

• The DNC will establish and maintain a contact repository of DNS Operators who offer DNSSEC services.

The Authorised Registrars page (/registrars) identifies various capabilities of Registrars such as those who meet the criteria to be deemed ‘IDN Friendly’, and those who can provide IPv6 registrations. 

DNSSEC Friendly identifies Registrar’s that meet a higher level of service relative to offering DNSSEC services in the .nz space.  The Domain Name Commission recommends that Registrants looking to deploy DNSSEC look for Registrars who are DNSSEC Friendly. 

In addition to adhering to the DNSSEC related clauses in the .nz policies, Registrars who wish to apply for ‘DNSSEC Friendly’ status must also confirm the following:

A. I confirm that my organisation’s staff have been trained in DNSSEC fundamentals and their operation.

B. I confirm that my organisation has adequate information housed on our website which explains the benefits and basics of DNSSEC. 

C. I confirm that my organisation’s website will include the following information:

Key Policy

• Key length and algorithm used
• Key rollover period
• Whether a common key is used across multiple customers or a single key per customer

Key Protection

• State whether online/offline signing of keys is performed
• State how keys are backed up
• State how keys are handled (HSM, no HSM, or hardened host)

D. I confirm that Registrants will have the option to be notified when a new DS record is being introduced (as part of KSK rollover).

Organisations that wish to apply for the ‘DNSSEC Friendly’ status will need to complete the DNSSEC Status Application Form.  A DNS Security FAQ for Registrants has been prepared and a copy can be downloaded here.  .nz Registrars are permitted to reuse the content in this FAQ.

DNCL will review the applications on a case-by-case basis and may ask for evidence supporting the following affirmations before making a decision.

The status ‘Handles DS Records’ status identifies those Registrars who have the capability to update the SRS with DS Records.

Organisations that wish to apply for the ‘Handles DS Records’ status will need to confirm that their organisation:

• Accepts all IANA-accepted code points for DS’s or DNSKEY’s, and if accepting DNSKEY’s will produce valid DS records.
• Has the ability to delete, modify and add DS records (either provided directly or derived from DNSKEY).

The application form can be found at: www.dnc.org.nz/content/dnssec-status-application.pdf

DNCL will review the applications on a case-by-case basis and may ask for evidence supporting the following affirmations before making a decision.

DNSSEC introduces the following new DNS records: DNSKEY, DS, RRSIG, NSEC and NSEC3. 

The DNSKEY record contains the public part of a cryptographic key used to sign records in a zone.  It usually lives within the zone for a domain name. 

The DS record contains a cryptographic digest, a unique digital representation or ‘fingerprint’, of a zone’s DNSKEY and is included in the parent zone.  In the case of a domain under .org.nz the DNSKEY is created, then the corresponding DS record is generated and sent to the Registry to be included in the .org.nz zone.

The RRSIG records contain the cryptographic signatures for the DNS data. The NSEC and NSEC3 records are used to provide Authenticated Denial of Existence.

DNSSEC Practice Statement

The .nz Registry Services (NZRS) has developed a DNSSEC Practice Statement (DPS). It defines the operational procedures for the management of DNS Security Extensions (DNSSEC) in the New Zealand top-level domain (.nz) and second level domains under .nz.

It draws on the Internet Engineering Task Force (IETF) I-D for DNSSEC Practices Statement construction, but has a number of significant differences to keep the .nz DPS appropriate for .nz. 

The DPS can be found here: http://nzrs.net.nz/dns/dnssec/dps

DNSSEC Related Specifications

The following is a list of RFCs that define the current version of DNSSEC, and are provided for further reading:

• RFC 4033 - DNS Security Introduction and Requirements
• RFC 4034 - Resource Records for the DNS Security Extensions
• RFC 4035 - Protocol Modifications for the DNS Security Extensions
• RFC 4641 - DNSSEC Operational Practices
• RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

External Resources

There are many DNSSEC guides, how to documents, and websites on the Internet. The following is a list of some Key Management resources that are suggested for further reading:

• DNSSEC Key Maintenance (http://ws.edu.isoc.org/workshops/2008/cctld-ams/Documentation/DNSSEC_Key_maintenance.pdf

• DNSSEC Key Management and Rollover (http://www.securityweek.com/five-strategies-flawless-dnssec-key-management-and-rollover)

• Running OpenDNSSEC with 50000 zones (http://www.opendnssec.org/2011/02/17/running-opendnssec-with-50000-zones/)

NZRS has also provided this information regarding the requirements for DS records:

/content/DNSSEC_Requirements_for_DS Records.pdf

The Internet Society (ISOC) have produced this factsheet and basics page for more information:

http://www.internetsociety.org/deploy360/wp-content/uploads/2014/10/DNSSEC-Fact-Sheet-English-v1.pdf

http://www.internetsociety.org/deploy360/dnssec/basics/

ISOC have also produced more technical advice for Registrants:

http://www.internetsociety.org/deploy360/resources/dnssec-registrars/

The contact details of the person or organisation who manages the administrative aspects of the registration. This could be the Registrant or a nominated external party. These details are displayed in the WHOIS record for the domain name.

The date the current registration is billed and paid up to.

The length of time a domain name is registered and charged for. In the .nz domain name space names can be registered for terms ranging from 1 to 120 months. 

A two-character Internet top-level domain that is used or reserved for a country, a sovereign state, or a dependent territory. The ccTLD for the country of New Zealand is .nz. 

A .nz domain that was registered in at least two Second Levels before 9am, 30 May 2012 and whose registration Direct at the Second Level needs to go through DNCL’s Conflicted Name Process.

There have recently been some changes made to the Conflicted Names Process, these can be read here

If you want to learn more about Conflicted Names feel free to check out our FAQ section here

The process by which those with a Conflicted Name can have their say on which of them might register the shorter version of the domain name Direct at the Second Level.  

More information about the Conflicted Name Process can be found here.

Unless otherwise stated, any calendar day. 

The process by which a Registrar’s .nz authorisation is cancelled.

An alternative to Court action, giving parties within the .nz domain name space a mechanism to resolve disputes as to who should be the Registrant for a .nz name. 

Domain Name Commissioner.

The governance body for DNCL, normally consisting of five members appointed by InternetNZ. One board member is an InternetNZ Councillor.

A company wholly-owned by InternetNZ, responsible for the day to day oversight of the .nz domain name registration and management system. DNCL is headed by the Domain Name Commissioner (DNC).

The hierarchical distributed naming system that maps numeric Internet Protocol (IP) addresses to human readable domain names.

A cryptographic key used to verify whether the data contained in a DNS response comes from an authoritative DNS server and whether it has been altered. Registrars who are able to handle and process DNSKEYs are listed on DNCL’s website. 

An individual or organisation that offers DNS management services e.g. the Registrar for a domain name, a hosting provider, an ISP, or another party. 

A suite of Internet Engineering Task Force (IETF) specifications that improve the security of the DNS and provide increased protection for activities such as browsing the Internet and email.

A string of characters that are used to locate an individual or organisation on the Internet. Domain names are most commonly used for URLs (also known as web addresses) e.g. dnc.org.nz or dnc.nz. Domain names can also be used for email addresses e.g. info@dnc.org.nz or info@dnc.nz. 

The part of DNSSEC that contains ‘trusted’ digital signature information.

The list of Registrars who have the capability to update the SRS with DS Records – available on DNCL’s website. 

One of the categories of Top Level domains with three or more characters – for example .com, .org, .photography, etc. 

The body responsible for the global coordination of the DNS Root, IP addressing and other Internet protocol resources. 

The body responsible for the coordination of maintenance and methodology of the Internet’s unique identifiers. 

A domain name that contains at least one label that is displayed in language-specific script or alphabet (non-ASCII). In the .nz domain name space, domain names can be registered using the macronised characters ā, ē, ī, ō and ū.  

InternetNZ’s governing Council, consisting of 10 Councillors and 2 Officers elected by the InternetNZ membership. 

The membership-based organisation that holds the delegation for .nz. InternetNZ has two wholly owned subsidiaries that run .nz on its behalf – the Domain Name Commission Limited and NZRS Limited. 

An organisation that provides people with services for accessing and using the Internet. 

A domain name that has been temporarily locked to prevent any changes being made to the record. Domain names may be locked in certain circumstances (such as when required by a Court order or when a domain name has been cancelled as a sanction), including to preserve the integrity of the Register or while a domain name is in dispute through the .nz Dispute Resolution Service.

One of a limited number of Second Level Domains that have restricted registration criteria. There are six Moderated Second Level Domains - .cri.nz, .govt.nz, .health.nz, .iwi.nz, .mil.nz and .parliament.nz. 

The process by which a registration in a Moderated Second Level Domain is scrutinised by the Moderator for suitability. 

The individual or organisation authorised by DNCL to act as Moderator. 

A server on the Internet that translates domain names into IP addresses and vice versa. 

Information about the Name Servers that are used for a domain name, if relevant. Name Server information appears on the Register and is displayed in the WHOIS record for the name.

The formal agreement Registrars sign with NZRS Limited to access the SRS. 

the core .nz terms and conditions that Registrars must incorporate into their terms and conditions, which Registrants are required to agree to when registering a domain name.

The formal agreement Registrars sign with DNCL when they are approved to become an authorised .nz Registrar.

The organisation responsible for operating the .nz Register. NZRS is wholly-owned by InternetNZ.

The agreement DNCL has with InternetNZ to manage and administer the .nz domain name space on InternetNZ’s behalf.

A domain name holds pending release status for a period of 90 days after it has been cancelled. During the pending release period, the name will not resolve. During the 90 days, the name can be reinstated by the current Registrant but cannot be registered by anyone else.

The authoritative record of .nz domain names and who holds the right to use those names. The .nz Register is also the source of Name Server information for the .nz DNS.

The person or organisation to which a domain name is registered. The Registrant of every .nz domain name is recorded in the .nz Register and details can be found by performing a domain name registration data query. You can do this by inputting the domain name in the field at the top of this page. 

The contact details of the person or organisation who holds the registration. This must be the Registrant – the individual over 18 or properly constituted organisation that requested the registration.  These details are displayed in the WHOIS record for the domain name.

An organisation authorised by DNCL to connect to the SRS to provide .nz domain name registration services.

A group chaired by the Domain Name Commissioner (DNC) and comprised of DNCL and NZRS representatives, and six registrar representatives. The group represents the interests of the registrar community at large and is a key advisory element in the ongoing monitoring of the market by DNCL.

The current Registrar for a domain name.   

A .nz domain name that has been registered immediately before the .nz – e.g. anyname.nz.

The entity that maintains and operates the .nz Register on behalf of InternetNZ. The registry for .nz is NZRS Limited.

A .nz name Direct at the Second Level that has been reserved by the eligible Registrant. The eligible Registrant should register their Reserved name by 1pm 30 March 2017, otherwise it will become available for general registration, on a first-come, first-served basis. 

The ability to be able to reserve .nz domain names was part of Preferential Registration Eligibility (PRE) - an important aspect of a 2014-2015 policy change that allowed people to get shorter names directly at .nz. 

More information about that the policy change that allowed domain names to be reserved can be found at https://www.dnc.org.nz/more-options-nz and https://www.dnc.org.nz/faq-nz-registrations-directly-second-level

Recently, the date in which domain names need to be registered by before they become available on a first come, first served basis was extended, notification of this can be found by clicking here. The consultation document for this can be found in our consultation section via the following link: https://dnc.org.nz/resource-library/consultations

Means the domain name’s conflict status has been resolved. The registrant with resolved rights has two months from the date of resolution to register the name. 

A category within the existing .nz domain name hierarchy – e.g. in dnc.org.nz, ‘.org’ is at the second level.

The agreement that DNCL has with NZRS Limited for the operation of the .nz DNS and Register.

Refers to the .nz Register system.

The contact details of the person or organisation who manages the technical aspects of the registration. This could be the Registrant, or a nominated party such as a developer or web host.  These details are displayed in the WHOIS record for the domain name.

the password/code required to validate a request to transfer a .nz domain name from one Registrar to another. For those with a Conflicted Name, a UDAI is also needed to lodge a conflict preference with the Domain Name Commission Limited and, if resolved, register it.

An electronic facility used to query the details of a specific domain name in the .nz Register.

A list of .nz domain names that are included in a process that populates all appropriate names to various domain name servers around the world. The zone file is pushed to the .nz Name Servers every fifteen minutes.