The TMCH works by verifying and storing trademark records in a database so new gTLD registries (like Dot Kiwi) can conduct legitimate Sunrise launches. The TMCH also provides services for owners of gLTDs (like .kiwi owners), including its Trademark Claims service that warns trademark holders if someone else registers a domain name that matches their trademark so they can take appropriate action.  

The TMCH protects ‘labels’ that are an identical match with your trademark. For example: ‘Dot Kiwi’ is a single ‘trademark’ but has three ‘labels’ protected by the TMCH: ‘Dot Kiwi’, ‘DotKiwi’, and ‘Dot-Kiwi’. You can include up to 10 labels when you register your trademark with the TMCH and you can choose to register for between one and five years with options to renew.

If you register your trademark through an official TMCH agent (such as Dot Kiwi) you may be eligible for a small discount on the TMCH registration fee, plus you’ll benefit from our assistance in ensuring your application is error-free and approved quickly. We have already worked successfully with many clients to validate all trademark information before it is submitted to ensure there are no delays or rejections.

To use Dot Kiwi as your official TMCH agent, please review your trademark information at www.iponz.govt.nz and contact us today. Once we’ve reviewed your info, we’ll ask you to submit a TMCH Signed Declaration as well as a single sample of Proof of Use (evidence that your trademark is being actively used). We will also confirm with you the cost of your application. Once we’ve got all your info sorted, we’ll ensure your application is successfully registered by the TMCH.

Contact us today to register for the Trademark Clearinghouse.

Your domain name gives your website an address on the internet. Domain names contain a Top Level Domain (TLD) and a Second-Level Domain (SLD).  

Here’s an example:



The SLD (‘welcome’) is the unique domain name you choose. The TLD (‘.kiwi’) is the generic group of domains your domain name belongs to.  

When you type your website address into your browser, however, the actual address your browser accesses is a series of numbers called an IP address. The DNS operates a bit like a massive phone book for the internet by translating user-friendly domain names into numerical IP addresses.

Here’s how the DNS works in more detail:

• When you type a domain name like www.hello.kiwi into your browser, it searches the internet for the numerical IP address that corresponds to that domain name. Not knowing where to find the IP address, it first goes to what is known as a Recursive Resolver.
   
• The Recursive Resolver consults a Root Server to find domain names ending in the relevant TLD, in this example ‘.com’. Root Servers hold the DNS information about TLDs like .com, .nz, and, eventually, .kiwi.
  
  
• Root Servers know the locations of the Name Servers that store the address information for the next level of domain names, the SLDs. In our example, the relevant Root Server will respond to the Recursive Resolver with the address of the Name Server that stores information on the .kiwi domain name containing the SLD ‘dot-kiwi’.
  
  
• The Recursive Resolver then approaches the relevant Name Server looking for an IP address for the website called ‘www.hello.kiwi’. The Name Server responds with the IP address, which in this case is ‘202.160.117.142’.
  
  
• The Recursive Resolver then sends the IP address to your browser so it can request content from our website. And all of this happens within a fraction of a second.

Domain Name – A domain name is a unique address on the internet. Domains are most commonly used to identify websites. Just like how addresses in the real world have country, city and street, domain names are made up of different levels and separated by dots.

TLD – Top Level Domain. A top level domain is the part of the domain name located to the right of the last dot e.g. .com is a Top Level Domain, as is .net or .nz. TLDs are generally used to categorise the internet.

ccTLD – Country Code Top Level Domain. A ccTLD is a certain class of TLD, best described by way of example, e.g. .nz, .au, .ca, .us and so on. The ccTLD relates to a country, and generally signifies an attachment to, or representation of that country. It gets a bit confusing when countries such as Columbia (.co), Montenegro (.me) or Tuvalu (.tv) market the use of their ccTLDs in more generic ways and move away from the traditional association with their country – these are often referred to as “re-purposed” TLDs, or “pseudo generic TLDs”. Country Code TLDs are always two characters long.

gTLD – Generic Top Level Domain. A gTLD is another class of TLD, best described by way of example, e.g. .com, .org, .travel and so on. The gTLD does not represent a country like a ccTLD, but can relate to other more generic categories such as an industry (e.g. .travel, .xxx), a type of organisation (e.g. .org, .com, .edu, .gov, etc) and can even relate to a geographical region (e.g. .cat for Catalan). Generic TLDs are longer than 2 characters.

New gTLD – New Generic Top Level Domain. Prior to the year 2013, there were only 22 gTLDs in existence. Some of these gTLDs were for restricted use such as .gov, .mil, .int, and others were open for any use such as .com. Due to the vast growth of the internet since the early 1990s, the way we use the internet has changed and the amount of users and applications of the internet has grown tremendously. In response to this, in 2011 ICANN, decided to increase the amount of gTLDs available by accepting applications to introduce new gTLDs to the internet. As a result, in 2013 and 2014 we have the introduction of English and non-english script gTLDs, such as .kiwi, .google, .beer, etc.

IDN – Internationalised Domain Name. IDNs simply are domain names that are not in English script. For example, .قطر which is the Arabic version of .qa (Qatar), or . which is Cyrillic for .ru (Russia). Non English script can exist in the Top Level of a domain, and also at the Second Level within a domain, for example the use of macrons is possible within the .kiwi TLD, e.g. māori.kiwi

ICANN – An acronym for The Internet Corporation for Assigned Names and Numbers. ICANN is the organisation that is responsible for managing and coordinating the Domain Name System (DNS) to ensure that every address on this internet is unique and that all users of the Internet can find all valid addresses. It does this by overseeing the distribution of unique IP addresses and domain names. It also ensures that each domain name maps to the correct IP address.

URL – A Uniform Resource Locator, which probably doesn’t explain much. In other words, a URL is a commonly used term that really just means a “web address”, such as http://www.register.kiwi

2LD/SLD/3LD – These describe the different sections of a domain name. In the following example, http://this.domain.kiwi – “this” is the 3LD (Third Level Domain), “domain” is the 2LD (Second Level Domain, also known as an SLD) and of course “kiwi” is the TLD (Top Level Domain)

Registry – The Registry is the organisation in charge of the register of domain names. In this case, Dot Kiwi Limited is the Registry for the .kiwi Top Level Domain.

Registrar - The Registrar is the only kind of organisation that can register domain names at the Registry, on behalf of the Registrant. For a Registrar to register a domain name in a gTLD, they must be accredited by ICANN, and contracted with the specific gTLD Registry. In fact, we have a list of registrars that we recommend right here: link to registrars.

Registrant – The Registrant is the person or organisation that is licensed to use a domain name. A Registrant must register their domain name via a Registrar. The Registrant is often also referred to as the “Registered Name Holder” of a domain name.

DNC – The Domain Name Commission manages the .nz ccTLD name space. The DNC was appointed by InternetNZ to serve a number of functions that can be viewed here. InternetNZ and the DNC are not affiliated with Dot Kiwi Ltd and have no authority or administrative function over the .kiwi gTLD.

Labels – Labels is technically the correct terminology for the different sections or parts of a domain name. So, for the domain mydomain.kiwi the section “mydomain” is known as a label, and the “kiwi” word is also known as a label. Basically, any word or string of characters that is separated by a dot, is known as a label.

Trademark Clearinghouse – The Trademark Clearinghouse is an “opt in” database of eligible trademarks that are verified as current and in use. Trademark owners must apply to have their trademarks included in the database. Trademarks that exist in this database are eligible (some conditions may apply) to participate in the Sunrise events of each new gTLD being launched. Furthermore, the Trademark Clearinghouse acts as an early warning system for trademark owners who have their trademarks registered in the database. This early warning system is known as the Trademark Claims Service.

TMCH/TCH – Please see Trademark Clearinghouse.

Trademark Claims Service – The Trademark Claims Service is an early warning system for owners of trademarks who have their marks registered in the TMCH. If a domain name is registered in a new gTLD and the registered domain name matches a trademark in the TMCH, the trademark owner (or their Agent) will be notified that the registration has taken place, allowing the trademark owner to take action if deemed necessary. Also, the Registrant attempting to register the domain name will be warned (put on notice) that their domain name matches an active trademark, and will be given the option not to proceed with the registration. The Trademark Claims Service is not available in perpetuity, please see Trademark Claims Period for more information.

Clearinghouse Official Agent - A full list of Clearinghouse Official Agent’s can be located here. Official Agents are registered with the Trademark Clearinghouse and can submit trademarks into the TMCH on behalf of the trademark owners. Dot Kiwi Ltd is a Clearinghouse Official Agent.

TCS – Please see Trademark Claims Service.

DNSSEC – DNSSEC is an acronym for Domain Name System Security Extensions. If that doesn’t explain it for you, think of it as a way of ensuring that domain names are who they say they are – so it’s a little like an ID badge. It’s a complicated thing, but when you type a domain name into the address bar of your browser, there is a chain of events that you don’t see happen, where a number of computers talk to each other to get you to the website you asked for. DNSSEC helps ensure that each computer in that conversation are verified as the ones that are supposed to talk to each other to get you the website you asked for. In other words DNSSEC helps stop that chain from being breached by a computer with a fake ID. For more information visit ICANN’s website and search for DNSSEC.

IPv6 – IPv6 is an acronym for Internet Protocol Version 6. It might help if you know what an IP Address is first (click here), but basically an IP Address is like a unique number for any computer (or device) connected to the internet – a bit like a phone number. IPv6 exists to solve a problem with IPv4 IP Addresses. IPv4 IP addresses were like a short phone number, with fewer amounts of possible combinations. As the internet has grown, there has been a shortage of these numbers that can be uniquely allocated to devices. So, IPv6 came along (thanks to a bunch of very clever people) and made the IP addresses longer, providing an increase in possible combinations and thus solving the short supply of IP addresses!

IPv4 – IPv4 is an acronym for Internet Protocol Version 4. It might help if you know what an IP Address is first (click here), but basically an IP Address is like a unique number for any computer (or device) connected to the internet – a bit like a phone number. IPv4 IP addresses are still widely used on the Internet today, but IPv6 is now being used in addition to IPv4 since IPv4 number combinations have actually run out!

‘’A’ Record’ – An ‘A Record’, also known as an ‘Address Record’, is a small instruction that is contained within your domain name records (domain name records = Zone File). You can have multiple A Records within your Zone File. An A Record helps instruct computers to know where to look for certain things on the internet that relate to your domain name, such as your email service and your website server.

Domain Activation – This occurs when your domain name becomes active on the internet. It means you can start using it for things like email and websites. It’s a bit like when you’re given a credit card, you can’t use it until you activate it with your bank! The activation concept is no different in domain land.

Browser – This used to be someone who looked at magazines and never paid for them. In the context of the Internet a Browser is a program/application that runs on your computer or mobile device. It allows you to quite literally, browse the web looking by looking at websites. Common Browsers are Internet Explorer, Firefox, Safari and Chrome.

Cache – In web browsing world though, cache is a versatile term for just temporary storage. Computers and internet devices like to store data and information in their own cache (think of it as short term memory), so that they don’t need to keep going back to a website to get the same data over and over again. Just think about when you visit your favourite knitting website, is it easier for your computer to ask the website for the same logo every time you visit, or is it easier to ask for it once then just remember it for a few weeks? Basically, cache is computer speak for being lazy (efficient).

Cookies – Not to be confused with biscuits. There are many kinds of cookies and they’re not half as exciting as they sound. There are session cookies, super cookies - even zombie cookies and we certainly don’t recommend you eat them. When it comes to the internet and websites in particular, it’s useful to have a way for websites to remember stuff about you, normally the kind of stuff they remember is basic information. For example, on your favourite news website, you may like to automatically see Auckland weather reports rather than Wellington weather reports, in this example cookies can be a way that a website remembers your weather preference. More technically speaking, a Cookie is a small file located on your computer, the contents of the cookie can then be transmitted to the website when you re-visit it to remind the website what you like and how you like it. Unfortunately, sometimes cookies are used to store more information than they really should, so know your rights and if you’re worried about privacy, talk to someone who knows some stuff.

CRS – is an acronym for Complaint Resolution Service. Basically, if you have a complaint that relates to a .kiwi domain name you are welcome to submit a complaint to Dot Kiwi’s support team. Please refer to our Help section for which complaints Dot Kiwi can help with, and which ones we can’t.

DNS – is an acronym for Domain Name System. The DNS is one of the most important systems on the internet, in fact, we wouldn’t have an internet like the one we do today if DNS didn’t exist. The DNS basically maps domain names to IP addresses, which makes it easy for humans to use the internet without needing to remember lots and lots of numbers. If it wasn’t for the DNS, you’d need to type xxx.xxx.xxx.xxx to reach our website, instead of just hello.kiwi

DNS Resolution – in other words, Domain Name System Resolution. This is the process of resolving a domain name into an IP address. If a domain name resolution didn’t exist, we’d be stuck having to type (and remember) a sequence of 12 numbers into your browser instead of a simple to remember domain name.

DNS Server – In the context of the internet, a DNS (Domain Name System) Server is a computer that performs the actual DNS Resolution process. There are a number of different kinds of DNS Servers, but generally speaking they help translate domain names into IP addresses by pointing other computers get what they’re looking for.

Domain Name Resolvers – Also called DNS Resolvers or Recursive Resolvers, Domain Name Resolvers are the computers which are used by ISPs to respond to a user request to find an IP address associated with a domain name. The term “Resolving” in web world speak refers to the translation of a domain name into an IP address, which allows your browser to locate your desired website content. Think of it as though you are trying to find an address on a map, but aren’t sure where to look. You check the index, and it tells you the quadrant to check. The index is like a Domain Name Resolver in that it tells you where to look next for your desired location.

Domain Parking – While this is certainly not self-explanatory, it is a little bit how it sounds. If your domain name was a car, it would be like parking it in the garage where it can’t be seen or used. So in the domain universe, if you’ve registered a domain name but don’t yet know what to do with it, you just park it in the virtual garage until you find a use for it. What this means is that you can get the domain name you want right now, but worry about what you’re going to use it for later. Talk to your registrar (the company you registered the domain with) if you want to know more.

DRP – an acronym for Dispute Resolution Procedure. Believe it or not but domain names can sometimes become the center of a dispute between two parties. When such disputes arise, and there are lots of kinds of disputes (including but not limited to “I got here first, so this domain is mine”), it’s best if there is a predictable process that either or both parties can use to escalate the dispute to ensure a fair resolution. We call this a Dispute Resolution Procedure, or DRP for short. For more information on which DRPs are available please visit the ICANN help page at http://www.icann.org/en/help/dndr.

Email Client – If you’re reading this, you probably know what an email is and you may even use email yourself. If you were to read or write an email you would need a program, application or facility to do that with. We call that program, application or facility an Email Client. We know it doesn’t make obvious sense why, but we deal with it and so can you. If it vexes you though, read what an Email Server is and it might make more sense.

Email Server – An Email Server (or Mail Server) actually is pretty much what it sounds like – it exists to serve email. In the case of email, the email server accepts email FROM the sender, and serves it to you, the recipient. The really good thing about email servers is that they can serve hundreds of thousands of emails very quickly and for many people. To be more technical, there are two main kinds of mail servers that play different roles in the overall email service. One takes care of the sending of an email, and the other takes care of the receiving of an email.

Email Spoofing – Email Spoofing is a technique mostly used for spam and phishing scams. It’s where a true sender of an email forges the sending email address, so that the recipient thinks the email came from someone else. If you think about traditional mail, it would be like someone sending you a letter but putting a false “FROM” address on the envelope to make you think you can trust the contents. There are technologies and protocols that can help fights against email spoofing, but they’re not perfect. If you’re interested in knowing more, you should talk about SPF records with your domain registrar, and also ask about other options.

EPP – an acronym for Extensible Provisioning Protocol. If you are a Registrar and need to know what EPP is all about, then we’d seriously suggest that you get in touch with our technical team, or even consult with your own technical team. EPP is a protocol that exists so that registries and registrars can exchange requests and information easily between each other.

FTP – is an acronym for File Transfer Protocol. If you’ve ready this entire glossary you’ll know that the internet is full of protocols, and FTP is yet another one. Actually FTP is quite an important one in the life of the everyday internet. FTP is a protocol that allows the transfer of files from one location on the internet to another location on the internet. This is particularly helpful when you’re wanting to download files, or share files with others. Quite commonly, FTP is used by people who build websites and need to upload the website files to a computer that publishes that website on the internet. FTP is not the only protocol that allows the transfer of files on the internet, there are others - FTP is an oldie but a goodie.

GAC – This stands for the Governmental Advisory Committee of ICANN. The GAC play an important role within the ICANN organisation and are one of the advisory groups that ICANN relies on to receive advice on the interests and needs of stakeholders not represented in other sections of ICANN. The GAC’s specific role is to provide advice to ICANN on issues of public policy, and especially where there may be an interaction between ICANN’s activities or policies with national laws or international agreements. To find out more about the GAC, please visit https://gacweb.icann.org/display/gacweb/About+The+GAC

GNSO – Is an acronym for Generic Names Supporting Organisation. The GNSO is a supporting organisation within ICANN that fashions (and over time, recommends changes to) policies for gTLDs.

HTML – Hyper Text Markup Language. HTML is one of the main (markup) languages for building websites. It helps turn boring looking plain text into a web page that is easy to read and styled in an attractive, or unattractive way as the case may be way. The text you are reading right now is the result of HTML working its magic. If HTML had a tagline (which it doesn’t) it would be “Making text look cool since the early 90’s”.

HTTP – A commonly known acronym that lots of people don’t know the meaning of. Hypertext Transfer Protocol is an application protocol for distributed, collaborative, hypermedia information systems. If you don’t know what that means, and don’t want to find out, then we suggest you just remember that HTTP is often the bit you see automatically inserted in your browser before the domain name. The reason you see it there is to tell your browser to use the Hypertext Transfer Protocol when requesting the webpage.

IANA – The Internet Assigned Numbers Authority is a department of ICANN and is responsible for the global coordination of the DNS Root, IP addressing, and other Internet protocol resources. In other words, IANA makes sure that the internet doesn’t break.

IETF – IETF stands for Internet Engineering Task Force and their mission is to make the Internet work better. They seek to do this from an engineering or technical perspective, rather than getting bogged down in policy and business related concerns.

IMAP – This is what Apple would have called their maps app if someone called Mark Crispin hadn’t used the name first. Actually, it’s an acronym not a word, and it stands for Internet Message Access Protocol. IMAP is a protocol that is used for retrieving email from a mail server. The great thing about IMAP is that it allows an email client to stay “in sync” with the mail server, whereas the alternative protocol called POP requires intermittent checking of the mail server. When setting up your email client to access your mailbox, you’ll probably need to choose between POP or IMAP. Have a chat with your email service provider about which one they recommend for you.

InterNIC – The Network Information Center, which is also known as InterNIC was the governing body primarily responsible for domain name allocations up until 1998. After that time, ICANN then assumed InterNIC’s responsibilities.

NIC – See InterNIC.

ISP – an Internet Service Provider. This is a name sometimes given loosely to a company that provides some type of internet based, or internet related service. Most commonly this is the name you would give to the company who supplies you with Internet access, generally this is also your telephone company. Broadly though, an ISP is anyone who provides you with an Internet specific service, such as web hosting, email services, domain names and more.

LAN – in geek world (even in non-geek world), LAN means Local Area Network. A LAN is a group of computers and/or devices that are connected in a way that means they can talk and share stuff with each other. If this sounds a little weird, you’re sort of right, but without a LAN you can’t do cool stuff like have more than one computer on the internet at home, or share one printer between a few computers. Think of a LAN as a private network of computers that can share resources – including an internet connection.

Landing Page – A landing page is a tool that marketers like to use to sell you stuff. They come in different shapes and sizes, but they’re basically a single web page (which could be very long), which you will probably stumble across if you’ve clicked on an advertisement and the advertiser wants to present you with some very specific content.

Sunrise – It’s just as it sounds really. In the real world, we give the name Sunrise to a very brief period in the day when the sun rises! It is a brief period of time and it’s the dawn of a new day. In Dot Kiwi Land we too have a Sunrise, and this brief period of time is the first opportunity to buy domain names. The catch is, the only folks who can buy domains from us at this time are trademark who have registered in the TMCH. So if you don’t have a trademark, or you do and it’s not registered in the TMCH, then don’t bother getting up to watch the Sunrise in Dot Kiwi Land.

Landrush – Just like Sunrise but completely different. A Landrush is another very brief period in time when Dot Kiwi domain names are available to buy. Actually, the Landrush is the first unrestricted opportunity for people to buy .KIWI domains. Then why is it called a Landrush? Well, because it really suits the folks who are itching to buy the best .KIWI domains, and be the first ones there. The Landrush is a limited time only opportunity though, you have to be ready! The real fun starts when two people have one hand each on the same domain name, unlike “General Availability”, in the Landrush period we don’t sell domains on a first come first served basis. So at the end of the Landrush period (30 days) if two or more people have their hands on the same domain, being the civilised company that we are, instead of encouraging a fight to the death, we simply auction the domain off amongst those who had their hands on it.

Nameserver – Nameservers are really important to you if you have a domain name – at least if you want to actually use your domain name. Every domain name needs to have at least two Nameservers listed in the details of your domain. To do this, you’ll need to follow the instructions of, or get in touch with your domain name registrar (the good people you bought your domain from). Nameservers really act like a receptionist for your domain name, so when a computer wants to visit your website, or send an email to you, the computer first needs to check in with the Nameserver and find out where it needs to go to look at your site, or where to drop off the email – otherwise the computer wouldn’t know where to go!

IP Address – Every computer and device connected to the Internet needs an Internet Protocol Address. In the same way that every phone (that works) needs a phone number, so does your computer if it wants to connect to the Internet. Domain names use IP addresses in their zone files to ensure that your computer knows where to look to find certain information and services, such as websites and email.

NoRN – simply stands for Notification of Registered Name. The recipients of a NoRN are the people who registered their trademark in the TMCH. They receive one of these notices when someone else registers a domain name that matches the label/s for a trademark record in the TMCH. This is like a monitoring system for trademark holders, so they know who might be registering their trademark as a domain name. If you’re planning on buying a domain name, don’t worry, you yourself will be notified prior to purchase if you’re trying to register a domain name that will result in a NoRN being dispatched.

Phishing – Not half as much fun and wholesome as it sounds. Phishing is like virtual fishing where you are the fish, and the Phisher is trying to get you on the hook, using a piece of juicy bait – doesn’t sound like a good prospect does it. If you have an email address you’ve probably been exposed to phishing one way or another. Generally, a phishing email will bait you into clicking a link in their email to go and do something, such as enter your account details, credit card details, or login details. The email will always look like it is from someone that you trust, such as your bank. If you do follow their bait, they will record the details you give them and go to the real bank and login to your account. It’s dastardly clever, and can be very easy to fall for it. So if an email ever asks you to visit a website and provide confidential information, don’t click on the link – give your bank (or whoever it may be) a call using the number from the phonebook, and double check with them. Read here to find out what Dot Kiwi is doing to reduce Phishing incidents.

Pioneer – A Dot Kiwi Pioneer is a company or individual who has a special place in our hearts. They’re with us from the start, from the very first day that we launch the first .kiwi domain name on to the internet. The first .kiwi domains that are launched will be ours (naturally) and those of our Pioneers. There are a few different kinds of Pioneers that partner with us in different ways, and receive different kinds of benefits. Simply put, Pioneers are the folks that pioneer our domain name into the big wide world. We just love these people, because they know how big, important and exciting Dot Kiwi is and want to join us from day one. If you’re interested in being a Dot Kiwi Pioneer, we’d love to meet you and fit you in as one of our cherished Pioneers. View here for more details.

PPC – an acronym for the term Pay Per Click. Unless you’ve been living in an alien universe with an alien internet where advertising doesn’t exist, you’ll have seen PPC advertisements popping up all over various websites. Most commonly you’ll see them on the far right of the page on a Google search results page. Every time you click on one of these ads, it costs the advertiser anywhere from $0.01 to, well, any amount of money – hence the term Pay Per Click. Sometimes, as a website owner, you can agree to display PPC advertisements on behalf of Google (and many others), and Google (or one of the many others) will give you a commission on each click. This can be a pretty awesome way of making some money for doing nothing. Be aware though, you might need a lot of clicks to make some serious cash.

Premium Name – This is a rather boring term given to a rather exciting concept. The concept is so exciting we’ve actually dedicated an entire section of our website just to Premium Names. If we could (and we can’t) we’d call them the Bestest Names. Bestest Names are the crème de la crème of .KIWI domain names. The reason they’re so good is because they’re the most searched for words on the internet, the most commonly used words in the dictionary, or they hold such a special place in the hearts of Kiwis that we need to treat them with the respect they deserve. To find out more, just visit this section of our website.

RRA – meaning the Registrar Accreditation Agreement. If you want to be an ICANN accredited registrar, then you need to sign one of these. It’s not that easy though, so best first check with ICANN about the other gazillion things you have to do before you are even allowed to sign one of these bad boys.

Reseller – Unsurprisingly a Reseller is someone or something that resells a thing to someone else. In the domain name world, a Reseller is someone who can’t or won’t sign an RRA, so they have to buy their domain names from a Registrar rather than direct from the Registry. Therefore, they’re “reselling” domains to you that they bought from a Registrar. There’s nothing wrong with this at all, in fact it is very common practice. There are some implications to you the registrant though, so we suggest you read up and make sure that your Reseller is trustworthy..

Restricted Domains – there are some domains we aren’t allowed to create for various reasons – here are some examples of restricted domains:

· Two-character labels
· Registry operator domains (includes www, rdds, whois, Nic)
· Country and Territory Names
· International Olympic Committee; International Red Cross and Red Crescent Movement related names
· Intergovernmental Organizations
· Sensitive Names (includes the sensitive Maori terms, profanity, Government requests, etc.)

RGP – An acronym for Redemption Grace Period, which sounds pretty good doesn’t it. In reality, it is really good, especially if you’re a domain name registrant that forgot to renew your domain name. The RGP is a period of time, often between 30-90 days where you as the registrant can still renew your domain name after it officially expired, hence the name of Redemption Grace Period.

Root Server – This is the server that all servers descend from, it is the mother of all servers, without it there would be no internet. Actually this is not true, well, not all of it. A Root Server, used in the context of IANA/ICANN is a server that helps tell the internet about itself. It does this by holding lists of addresses of other servers that will help guide a computer on the internet to find what it is looking for. Think of a really large index in the back of the biggest book in the world, to find the location of the word “Elephant” you would first find the section of the index which lists all the words starting with “E”. You might say that a root server provides the A-Z list in the index, it then points you towards where you find the list of words starting with ‘E’. So as you can see, without Root Servers (plural), there would be no internet.

SEO – simply stands for Search Engine Optimisation. This is the art, and indeed it is an art, of configuring and refining certain aspects of your website (and things that your website relies on) to make sure that your website appears as high as possible in the list of search engine results. Interestingly, domain names do have a part to play in SEO - for example, if you want to rank better in results when someone searches for “wild monkeys”, having the domain name “wildmonkeys.kiwi” is better than “tame-chimps.kiwi”. In other words, make your domain name relevant to your content. For everything else SEO, talk to someone who knows about that stuff.

SMD – Firstly, SMDs have nothing to do with mass destruction. A Signed Mark Data file is a little like a key that allows you permission to take certain actions. SMDs are given to those who have registered their trademark in the TMCH. It’s very important that you keep your SMD safe and secure. When a new gTLD (such as .KIWI) launches their Sunrise phase and you wish to register your trademark as a .KIWI domain, you will need to supply your SMD (your key) so we can validate that you are the rightful owner of the trademark, and therefore the rightful applicant for that domain.

SMTP – An acronym for Simple Mail Transfer Protocol, this is vastly different from the Complex Femail Transfer Protocol. SMTP is an internet protocol that is widely used for sending email messages between servers. Most email servers that send mail over the Internet use SMTP for sending from one server to another, at which point an email client can retrieve the email. Often when configuring a mail account, you will be asked what your SMTP or sending mail server is – you’ll need to contact your email service provider to find out that juicy little fact.

Spam – Generally speaking, spam are unsolicited emails that are sent to your mailbox that are commercial in nature. Not all unsolicited email is spam though and different jurisdictions have different opinions on the matter. Since we’re .KIWI, the New Zealand opinion on the matter is considered most important to us. Department of Internal Affairs has this website to help you if you’re concerned about Spam that you’re receiving. Furthermore, if you’re receiving spam from a .KIWI domain name, please get in touch with our Abuse Team.

TCP/IP – An acronym for Transmission Control Protocol / Internet Protocol. In essence, TCP/IP are the pre-defined rules for how computers communicate with each other on and over the Internet. Think of it as a combination of social etiquette and language – unless you’re using the same etiquette and language, things can go wrong very quickly. So TCP/IP keeps the computers on the internet understandable and respectful of communication rules.

Trademark Claims Period – The Trademark Claims Period is the period of time that a gTLD registry will run the Trademark Claims Service. Each gTLD registry must run the Claims Service for a minimum of 60 days following the closure of Sunrise, however some registries may opt to extend the 60 day period further at their discretion.

Trademark PDDRP – Also known as the TMPDDRP. Being one of the longer acronyms it stands for Trademark Post Delegation Dispute Resolution Process. In basic terms, if a gTLD operator (that’s us!) is running a registry in a way that supports trademark infringement, then the PDDRP is a process that is an alternative to court action to resolve the issue. If you really want to know more, we suggest you consult with WIPO on their site here: http://www.wipo.int/amc/en/domains/rpm/

UDRP – An acronym for Uniform Dispute Resolution Process, before you wonder why there needs to be a dispute resolution process for uniform wearing folk (though granted some uniforms are better than others), this one is more specifically a Uniform Domain Name Dispute Resolution Process. It applies to trademark holders who believe that their trademark is being infringed, and the infringement involves a domain name. For more details regarding the process please refer to ICANN’s website here: http://www.icann.org/en/help/dndr/udrp

U-Label – Domain names are a series of labels separated by dots. The U-Label is the part of an IDN (Internationalised Domain Name) that appears in non-latin script.

URS – Meaning the Uniform Rapid Suspension System. The URS is a system that is there to help protect the rights of trademark holders whose rights are clearly being infringed by a third party. The URS is different from the UDRP, because it is lower cost and is a faster process for rights holders that are suffering infringement in the most clearest of cases. Further information on the URS is available here: http://newgtlds.icann.org/en/applicants/urs

Web Hosting – If you’re going to have a website for your domain name, you’ll need to also get yourself some web hosting. Web hosting is an allocated place on a server that can house your website for all to see. If a domain name is your address, web hosting is like the land on which you’d build your store – you can’t have a store without some real-estate to build it on!

Web Mail – There’s nothing fancy about web mail, it’s still email and has nothing to do with spiders. Webmail is another kind of email client that you can use to read and write emails. It is particularly useful because you can access your email account using a web browser from any computer that is connected to the Internet – you don’t need to be using your computer.

Web Server – A web server quite literally serves up the juicy portions of the web to you. The Internet is made up of millions of web servers that each has their own specific function. Most web servers host websites so that you can view and interact with websites, there are also other web servers such as gaming servers and application servers. It’s safe to say that without web servers the Internet would be a very boring place.

WHOIS – This is actually not an acronym, it really means (and is pronounced) “Who is”. WHOIS is yet another protocol used in relation to domain names. Aside from the technical this, that and the other, what it really does is provide a way for people to find out who owns a particular domain name – hence the name, “WHOIS the registrant of that domain name”? If you register a domain name you will need to provide various contact details, and these are required to be reliable contact details at which you can be contacted directly or indirectly. Think of WHOIS as a giant directory for domain names, you can use it to find the contact details of a domain name, and someone can use it to find the contact details of you if you own a domain name.

WIPO – An acronym for the World Intellectual Property Office. WIPO is the United Nations agency dedicated to the use of intellectual property. If you think that sounds boring, we’d tend to agree. That said, they play a rather important role in the world of intellectual property and love them or hate them, they tend to know a thing or two. They’ve also been particularly involved in the development of new gTLDs.

Please find below the group of policies applicable for registrants in the .kiwi Top Level Domain. If you registered your domain through a 3rd Party Registrar or Reseller, it is important for you to know and understand those policies contained within the section titled "Dot Kiwi ("Registry") Policies". If you have registered, or are in the process of registering your .kiwi domain through Domain Vault, please also refer to those policies within the section "Domain Vault ("Registrar") Policies".

If you have any questions regarding the policies, or how they apply to you, please contact info@hello.kiwi.

Dot Kiwi (“Registry”) Policies

General:

Acceptable Use Policy

Complaint Resolution Service

Dispute Resolution Service

IDN Policy

Naming Policy

Policy Overview

Privacy & Whois Policy

Registrant Agreement

Sunrise:

Sunrise Dispute Resolution Policy

Sunrise Policy

Domain Vault ("Registrar") Policies

1. Introduction

   This DNSSEC Practice Statement (“DPS”) is a statement of security practices and provisions made by the Canadian Internet Registration Authority (CIRA). These practices and provisions are applied in conjunction with DNS Security Extensions (DNSSEC) of in all gTLD zone(s) under CIRA’s services.

   This DPS conforms to the template included in draft-ietf-dnsop-dnssec-dps-framework-03 ¹. The approach described here is modelled closely on the corresponding procedures published in a corresponding DNSSEC Policy and Practice Statement published by .SE (The Internet Infrastructure Foundation) for the Swedish top-level domain ², whose pioneering work in DNSSEC deployment is acknowledged.

   DPS is subject to CIRA’s Policies, Rules and Procedures, which are available on CIRA’s website at: www.cira.ca/legal/policies/all-policies.

   1. Document Name and Identification

      Name:	CIRA-DPS-gTLD-EN
      Version:	1.0
      Version:	DNSSEC Practice Statement
      Date of Last Modification:	2016-07-25
      Document Available From:	https://hello.kiwi/resources#dnssec

   2. Community and Applicability

      The following functional subsets of the community to which this document has applicability have been identified.

      1. TLD Registry

         The Canadian Internet Registration Authority (CIRA) operates the Top Level Domain (TLD) registry as Back-End Service Provider (BESP). CIRA is responsible for the management of the registries, and consequently for the registration of domain names under the TLD.

         CIRA is responsible for generating cryptographic key material, for protecting the confidentiality of the private component of all key pairs and for publishing the public component of relevant key pairs for use as DNSSEC trust anchors.

         CIRA is also responsible for signing the TLD DNS zone using DNSSEC.

      2. TLD Registrars

         A registrar is a party responsible for requesting changes in the TLD registry on behalf of registrants. Each registrar is responsible for the secure identification of the registrant of a domain name under its sponsorship. Registrars are responsible for adding, removing or updating Delegation Signer (DS) records for each domain at the request of the domain’s registrant.

      3. TLD Registrants

         Registrants are responsible for generating and protecting their own keys, and registering and maintaining corresponding DS records through a registrar.

         Registrants are responsible for emergency key rollover if the keys used to sign their domain names are suspected of being compromised or have been lost.

      4. Relying Party

         The relying party is the entity that makes use of DNSSEC signatures, such as DNSSEC validators and other applications. The relying party is responsible for maintaining appropriate trust anchors. Relying parties who choose to make use of TLD-specific trust anchors must stay informed of any relevant DNSSEC-related changes or events in the TLD domain. Relying parties who make use of a root zone trust anchor should not need to make trust anchor changes in response to events in the TLD registry, since trust anchors are published by CIRA in the root zone as DS records.

      5. Secure Identification

         Each entity in the DNSSEC process will require an appropriate level of validation to ensure true identity, ownership, and responsibility. This will apply to CIRA staff, 3rd party service providers, and registrants.

      6. Trusted Role

         A person engaged in the support of DNSSEC infrastructure, deployment and management must be a full time employee of CIRA. Contractors may provide assistance for technology and process but should have restricted physical and logical access to any DNSSEC operational component. A contractor cannot act in a trusted role.

      7. Applicability

         Each registrant and relying party is responsible for determining an appropriate level of security for their domain and DNSSEC infrastructure. This DPS applies exclusively to the TLD zone. With the support of this DPS, registrants and relying parties can determine an appropriate degree of trust in the TLD zone and assess their own risk accordingly.

   3. Specification Administration

      This DPS is updated as appropriate to reflect modifications in systems or procedures.

   4. Specification Administration Organisation

      Canadian Internet Registration Authority (CIRA)
      979 Bank Street, Suite 400
      Ottawa, Ontario, K1S 5K5
      Canada

   5. Contact Information

      Chief Information Officer
      Canadian Internet Registration Authority (CIRA)
      979 Bank Street, Suite 400
      Ottawa, Ontario, K1S 5K5
      Canada

   6. Specification Change Procedures

      Changes to this DPS will result in new revisions of the entire document. The current version of this document is available at https://cira.ca/DNSSEC-DPS. Only the most recent version of this DPS is applicable.

      CIRA may amend the DPS without notification for changes that are not considered significant. Changes are designated as significant at CIRA’s discretion. CIRA will provide reasonable notice of significant changes.

      All changes to this DPS will be approved by the CIRA and be effective immediately upon publication.

2. Publication and Repositories

   Notifications relevant to DNSSEC at CIRA will be distributed by e-mail to dnssec-announce@cira.ca.

   1. Repositories

      CIRA publishes DNSSEC-related information at https://cira.ca/build-better-internet/dnssec-securing-domain-name-system.

   2. Publication of Key Signing Keys

      CIRA publishes Key Signing Key (KSK) for the TLD zone as DS records in the root zone.

   3. Access Controls on Repositories

      Information published in the CIRA DNSSEC repository is intended to be available to the general public.

3. Operational Requirements
   1. Meaning of Domain Name

      A domain name is a unique identifier in the DNS, as described in RFC 1034 ³ and RFC 1035⁴. For the purposes of this document a domain name is a name registered under the TLD top-level domain, and corresponds to a delegation from the TLD zone to name servers operated by or on behalf of the domain name’s registrant.

   2. Activation of DNSSEC for Child Zone

      DNSSEC for a child zone is activated by publishing a signed DS record for that zone. The addition of a DS record to the TLD registry for the corresponding domain name, establishes a chain of trust from the TLD zone to the child zone.

   3. Identification and Authentication of Child Zone Manager

      Identification and authentication of each child zone manager is the responsibility of the sponsoring registrar for the domain name.

   4. Registration of Delegation Signer Resource Records

      The TLD registry accepts DS records through an EPP interface according to RFC 4310 ⁵ and manually via our TLD Manager application. Any valid DS record will be accepted by the registry, and no checks are performed as to the accuracy of the trust anchor with respect to the child zone’s KSK. Domain registrants will be responsible for providing current and accurate information to registrars.

   5. Method to Prove Possession of Private Key

      The sponsoring registrar for a domain name is responsible for validating the registrant as the manager of a private key.

   6. Removal of Delegation Signer Record

      DS records are removed from the TLD registry using an EPP interface according to RFC 4310 ⁶ or manually via DCM. The removal of all DS records for a domain name will remove the chain of trust between the TLD zone and the child zone.

   7. Authority to Request Deregistration

      The registrant for a domain name has the authority to request removal of a DS record.

   8. Procedure for Removal Request

      The registrant of a domain name requests the domain’s sponsoring registrar to remove the DS record. The registrar transmits this request to the TLD registry using EPP or DCM. Once the transaction has been successfully received and processed by the TLD registry, the DS record will be removed from the TLD zone when the following revision of the TLD zone is distributed.

   9. Emergency Removal Request

      There is no provision for a registrant to be able to make an emergency removal request of the TLD registry. All DS record removals must be executed through the domain’s sponsoring registrar.

4. Site, Management and Operational Controls
   1. Physical Controls

      CIRA has implemented the CIRA Security Policy, which supports the security requirements of this DPS. Compliance with these policies is included in Section 7 Compliance Audit.

      1. Site Location and Construction

         CIRA has established two fully-operational and geographically-dispersed operation centres. Each site serves as a back-up to the other. Both sites are protected by multiple tiers of physical security that deters, prevents and detects unauthorized access attempts.

         Each site contains two independent instances of equipment which is able to sign the TLD zone, and one instance of audit and signed zone distribution machinery. All signing components are placed within secure containers.

      2. Physical Access

         Physical access to operation centres is restricted to authorised personnel. All entry to both operation centres is logged and the environment is continuously monitored. Access to secure containers is further restricted to personnel with trusted roles.

         The physical security system includes additional tiers of key management security which serves to protect both online and inline storage of signers and keying material. Online signers are protected through the use of locked cabinets. Access to signers and keying material are restricted in accordance to CIRA’s segregation of duties requirements. The opening and closing of cabinets or containers in these tiers is logged for audit purposes.

      3. Power and Air Conditioning

         Operation centres are equipped with multiple power sources, including battery and generator support to ensure an uninterrupted supply.

         Operation centres are cooled with redundant air conditioning systems to ensure a consistent, stable operating environment.

      4. Water Exposure

         Both operation centres implement flood protection and detection mechanisms.

      5. Fire Prevention and Protection

         Operation centres are equipped with fire detection and extinguishing systems.

      6. Media Storage

         All media containing production software and data, audit, archive, or backup information is stored within the operation centers. Secure off-site storage facility with appropriate physical and logical controls are leveraged to restrict access to authorized personnel and protect media from accidental damage (i.e. water, fire, and electromagnetic).

      7. Waste Disposal

         Sensitive media and other material that may contain sensitive information are destroyed in a secure manner, either by CIRA or by a contracted party.

      8. Off-Site Backup

         CIRA performs regular backups of critical data, audit logging data and other sensitive information. An off-site facility is leveraged for storage of backup media. Physical access to the storage facility is limited to authorised personnel. The storage site is geographically and administratively separate from CIRA’s other operational facilities.

   2. Procedural Controls
      1. Trusted Roles

         Trusted roles include all employees that have access to or control cryptographic operations that may materially affect:

         1. Generation and protection of the private component of the CIRA Zone Signing Key (ZSK) and Key Signing Key (KSK)
         2. Secure export and import of any public components; and
         3. Generation and signing Zone file data

         Trusted roles include; but are not limited to:

         1. Naming resolution operations personnel;
         2. Security personnel;
         3. System administration personnel;
         4. Executives that are designated to manage infrastructure
   3. Personnel Controls
      1. Qualifications, Experience and Clearance Requirements

         Candidates for any trusted role must demonstrate appropriate background and qualifications.

      2. Background Check Procedures

         Background checks for candidates for any trusted role are carried out by the Human Resources department at CIRA, and follow normal procedures for background checks on new hires. A successful background check is required for a role to be assigned.

      3. Training Requirements

         CIRA provides its personnel with training upon hire as well as on-going training need to for them to perform their job responsibilities competently and satisfactorily. CIRA reviews and enhances its training programs as necessary.

         CIRA provides training programs specific to job roles and responsibilities and will include the following as relevant:

         1. DNS/DNSSEC concepts
         2. Cryptographic principles
         3. Use and operation of deployed hardware and software
         4. Security and operational policies and procedures
         5. Incident and compromise reporting and handling
         6. Disaster recovery and business continuity procedures and testing
      4. Contracting Personnel Requirements

         CIRA may choose to use contractors to assist CIRA in the development and management of DNSSEC technology. Contractors are to have restricted access to cryptographic material at all times. Contractors are subject to the same responsibility agreements and background checks as CIRA trusted roles.

      5. Documentation Supplied to Personnel

         CIRA will supply all personnel with trusted roles with necessary documentation to allow the tasks designated to those personnel to be executed effectively.

   4. Audit Logging Procedures

      CIRA implements automatic log collection from CIRA computer systems, for the purposes of monitoring and statistical analysis purposes in the event that a security violation is suspected.

      Paper documentation relating to the execution of procedures is also collected for the purposes of auditing performance of those procedures.

      1. Types of Events Recorded

         CIRA manually or automatically logs the following significant events.

         All KSK and ZSK key life cycle management events, including:

         1. Key generation, backup, storage, recovery, archival and destruction
         2. Exporting of public key components
         3. Cryptographic device life cycle management events

         All network systems use a centralized time system to ensure events across all devices are synchronized for time and date information.

      2. Audit Collection System

         Automated audit data is generated and recorded at the application, network, and operating system level. Manually generated audit data is recorded by CIRA personnel and stored using current methods for physical and fire protection.

      3. Notification to Event-Causing Subject

         All authorized personnel are informed that logging is taking place, and that logs are being retained.

      4. Vulnerability Assessments

         Vulnerability assessments are conducted against all data center sites on a regular basis. Any issues identified result in a risk management issue and are resolved using project management techniques to resolve and track.

      5. System and Network Monitoring

         All network access is monitored in real-time to detect anomalies. These events shall be investigated to analyse potential vulnerabilities.

   5. Compromise and Disaster Recovery
      1. Incident and Compromise Handling Procedures

         All actual and suspected events relating to security that have caused or could have caused an outage, damage to computer systems, disruptions and defects due to incorrect information or security breaches are defined as incidents.

         All incidents are handled according to CIRA’s standard procedures.

      2. Corrupted Computing Resources, Software and/or Data

         Any defect which results in the generation of inaccurate data will be addressed by the deployment of multiple, independent signers. All such defects will trigger incident management procedures.

      3. Entity Private Key Compromise Procedures

         A suspected or actual ZSK compromise will be addressed by immediately removing the compromised ZSK from service, replacing it with a newly-generated or pre-generated replacement key.

         A suspected or actual KSK compromise will be addressed by immediately executing a controlled key rollover.

      4. Business Continuity and IT Disaster Recovery Capabilities

         CIRA’s organisation-wide business continuity and IT disaster recovery plans include measures to ensure continuity of operation for registry and zone distribution systems.

         Multiple live log collection, zone audit and signer components are deployed to ensure continuity of operation for DNSSEC systems.

      5. Entity Termination

         unsigned zone, the removal of DNSSEC will take place in an orderly manner with public notification.

         If operation of the TLD registry is transferred to another party, CIRA will participate in the transition so as to make it as smooth as possible.

5. Technical Security Controls
   1. Key Pair Generation and Installation

      Key generation takes place in signers using a Software Hardware Security Module (softHSM) that is managed by trained and specifically authorized personnel in trusted roles on dedicated hardened systems.

      The KSK, and ZSK are generated in a pre-planned key generation ceremony. The activities of this key generation ceremony are recorded, dated, and signed by the individuals involved. These records are kept for audit and tracking purposes.

      Private components of zone KSK and ZSK are not escrowed.

      CIRA KSK and ZSK key pairs do not expire, but are retired when superseded.

   2. Other Aspects of Key Pair Management

      Public keys are backed up and archived as part of CIRA’s routine backup procedures.

      The operational period of each KSK and ZSK ends upon its supersession. The superseded zone KSK and ZSK will be never be reused to sign a resource record.

   3. Computer Security Controls

      All production computer systems are housed in secure facilities. Physical access to computer systems is limited to authorized personnel. Remote (network) access to signing systems is not available. All attempts to access computer systems, successful and unsuccessful, are logged.

   4. Network Security Controls

      CIRA’s production network is logically separated from other components. This separation prevents network access except through defined application processes. CIRA uses firewalls to protect the production network from both internal and external intrusion and to limit the nature and source of network activities that may access production systems that are related to key signing activities.

      Data is transferred between audit/distribution systems and signing systems using transactions which are initiated on the signing system. It is not possible to transfer data to or from a signing system using a transaction initiated from a remote host.

      All firewall components generate logs which are collected, analysed and retained.

      Other techniques such as IPS/IDS will alert when attempts to modify system packages have been made.

   5. Timestamping

      All DNSSEC components are time-synchronised to diverse, reputable time servers using authenticated NTP. Timestamps are always generated in UTC.

   6. Life Cycle Technical Controls
      1. System Development Controls

         Applications are developed and implemented by CIRA in accordance with CIRA systems development and change management processes.

         All software deployed on production systems shall be traced to change management tickets.

      2. Security Management Controls

         CIRA has technologies and/or policies in place to control and monitor the configurations of its systems.

      3. Life Cycle Security Controls

         The signer system is designed to require a minimum of maintenance. Updates critical to the security and operations of the signer system will be applied after formal testing and approval. The origin of all software and firmware will be securely authenticated by available means. Critical hardware components of the signer system will be transported in tamper-evidence bags to their destination in the secure site. All hardware will be decommissioned well before the specified life time expectancy.

6. Zone Signing
   1. Key Lengths and Algorithms

      KSK Algorithm	RSA
      KSK Length	2048 bits
      ZSK Algorithm	RSA
      ZSK Length	1024 bits

   2. Authenticated Denial of Existence

      Authenticated denial of existence may be provided through the use of NSEC3 records as specified in RFC 4033-35 and RFC 5155 (TLD dependant)

   3. Signature Format

      Zone KSK and ZSK signatures are generated using RSA over SHA256 (RSASHA256, as specified in RFC 5702 ⁷).

   4. Zone Signing Key Rollover

      ZSK rollovers are carried out every 30 days

      Key Activity	Length	Description
      Active	30 days	The number of days a key is used to sign a zone before rolling over to a new key
      Emergency rollover post-publish	2 days	If a ZSK is believed to be compromised, an emergency rollover of the ZSK will result in the old key still being published in the zone for 2 days; ensuring resolvers do not malfunction but the zone is not signed with it.

   5. Key Signing Key Rollover

      KSK rollover is carried out every year.

      Key Activity	Length	Description
      Active	365 days	The number of days a key is used to sign a zone before rolling over to a new key
      Pre-publish	30 days	Before we begin to sign a zone with a key, we pre- publish the key in the zone for this period
      Post-publish	30 days	After the old key is rolled over, it is still published (however nothing is signed with it) in the zone for this period
      Emergency rollover post-publish	7 days	If a ZSK is believed to be compromised, an emergency rollover of the ZSK will result in the old key still being published in the zone for 2 days; ensuring resolvers do not malfunction but the zone is not signed with it.

   6. Signature Lifetime and Re-Signing Frequency

      Resource Record sets (RRSets) are signed with ZSKs with a validity period between six and eight days. Re-signing takes place every time a new TLD zone is generated.

      The apex DNSKEY RRSet is additionally signed with the KSK with the same validity period and re-signing frequency.

   7. Verification of Zone Signing Key Set

      Each signed zone is subject to an array of tests, all of which must pass before the signed zone is distributed to name servers. These tests include verification of the chain of trust from the root zone to signatures over the apex DNSKEY RRSet.

   8. Verification of Resource Records

      All resource records are verified prior to distribution. The integrity of the unsigned zone contents is also validated prior to distribution.

   9. Resource Records Time-to-Live

      SOA	86400 seconds (24 hours)
      DNSKEY	21600 seconds (6 hours)
      NS, A, AAAA	86400 seconds (24 hours)
      RRSIG	inherited from signed RRSet
      Delegation Signer (DS)	86400 seconds (24 hours)
      NSEC3	3600 seconds (1 hour)

7. Compliance Audit

   Audits are conducted using retained logs and other relevant information to ensure that proper procedures have been followed at all times, and that the procedures have been executed accurately.

   1. Frequency of Entity Compliance Audit

      CIRA conducts audits at least annually. Circumstances which might lead to additional audits being carried out include recurring anomalies, significant staff changes or changes in equipment.

   2. Identity and Qualifications of Auditor

      CIRA compliance audits are performed by security consulting firms that demonstrate proficiency in security and public key infrastructure technology, information security tools, security auditing and assessments.

      The auditor will demonstrate proficiency in IT security, DNS and DNSSEC.

   3. Auditor’s Relationship to Trusted Party

      CIRA will appoint an external auditor who is responsible for the audit’s implementation.

   4. Topics Covered by Audit

      Each audit will include a review of events which occurred during a specified audit period. The auditor will ensure that CIRA is informed and prepared prior to the audit, including details of the particular topic of the audit.

   5. Actions Taken as a Result of Deficiency

      The auditor will immediately inform CIRA of any observed anomaly and/or areas of risk which will be managed as part of CIRA’s risk management methodology.

   6. Communication of Results

      Results of each audit will be provided to CIRA in a written report no later than 30 days following the completion of the audit.

8. Legal Matters
   1. Fees

      No fees are charged for any function related to DNSSEC.

   2. Financial Responsibility

      CIRA accepts no financial responsibility for improper use of Trust anchors or signatures, or any other improper use under this DPS.

   3. Term and Termination

      This DPS applies until further notice.

      1. Term

         This DPS is valid until it is replaced by a new version.

      2. Termination

         This DPS is valid until it is replaced by a new version.

      3. Dispute Resolution Provisions

         Disputes among DNSSEC participants shall be resolved pursuant to provisions in the applicable agreements among the parties.

      4. Governing Law

         This DPS shall be governed by the laws of the province of Ontario and the laws of Canada applicable therein.