TLD Management Powered By Experience
- A reliable and secure global registry platform
- The power to handle extremely high volumes of transactions
- RFC-compliant WHOIS and DNS servers
Speaking of DNS, Neustar operates one of the world’s most dependable Anycast networks, supporting thousands of global businesses, including 30 TLDs representing some 20 million domain names. Our primary and secondary DNS solutions move Internet traffic quickly and safely while guaranteeing 100% uptime.
Besides protecting DNS from distributed denial of service (DDoS) attacks, we also support domain name security extensions (DNSSEC). Giving authenticated responses to DNS queries, DNSSEC provides a “chain of trust” by using digital signatures and defends Web traffic against various types of spoofed responses. This helps prevent “cache poisoning,” whereby criminals give false responses from recursive DNS servers and reroute traffic to malicious sites. Bank customers, for example, could have their personal data stolen, with disastrous consequences for the bank’s reputation.
Any registrant collecting customer information, especially payment data, wins with DNSSEC. Neustar’s Registry team has worked closely with the Internet Engineering Task Force (IETF) to develop DNSSEC standards. They are now a built-in feature of our DNS services, including those that power the domains we manage, .biz and .us.
The Neustar domain name registry is invested in the constant evolution of a secure, robust Internet experience. As new opportunities present themselves, Neustar responds in a methodical, but timely, manner with industry participation, as well as new product and service offerings.
DNSSEC (Domain Name Security Extensions) is a set of extensions to the Domain Name System (DNS). It provides an authenticated DNS query response that is passed through what is called a “chain of trust.” By adding a digital signature to DNS data, DNSSEC addresses a specific DNS vulnerability that exposes Internet users to cache poisoning attacks.
What is the vulnerability in the DNS?
The efficient work of storing a response that functions as a mid-way point between an end user’s computer and an authoritative server is performed by a caching name server, usually operated by an ISP (Internet Service Provider). The DNS was designed to allow this caching server to accept the first response it receives. It is possible, without the verification provided by DNSSEC authentication, for a malicious user to flood this caching name server with a spoofed response that is, most often, intended to dupe the end user into providing personal and or financial information to what appears to be his or her intended destination.
The result is that the caching name server does not just pass this spoofed response to the end user who initiated the query, but to any other user whose request for the same address passes through that same ISP’s caching system. Normally, a cached response expires after a reasonably short period of time – 24-48 hours. However, the malicious user is able to set an expiration date on the cached response that permits it to be displayed for a much longer time, increasing the likelihood that many more users will interact with the spoofed response.
How does DNSSEC work?
DNSSEC works through a system of keys. At each stage in supplying a DNS query response through the chain that takes it back to the initiator’s machine, a known key and a private key must be matched. In this way, the response to the query is authenticated and the response validated.
How do registrants DNSSEC-enable their domain names?
Benefits of DNSSEC
When properly implemented from end to end, DNSSEC is effective in preventing cache poisoning, or “am in the middle” attacks. These attacks are capable of compromising the personal and/or financial information of thousands of Internet users. For example, without DNSSEC, a major ISP’s caching server might see thousands of queries a day from users trying to reach a major bank. If that query response has been spoofed, those users will reach a malicious Web site in its place. This affects not only the end users, but the brand and reputation of that financial institution.
Challenges of DNSSEC
The challenges and expense of DNSSEC implementation are immense. DNSSEC data requires active maintenance and regimented key changes. The process also requires that trust anchors are maintained by the recursive name servers. Despite these challenges, the vulnerability presented by the security hole that DNSSEC addresses makes developing a solution imperative.
Who should DNSSEC-enable their domain names?
Any registrant who wishes to guarantee an authentic DNS query response to end users. Registrants who collect personal information and, in particular, those who gather payment information are good candidates for DNSSEC. These registrants would submit additional record information, called Delegation Signer (DS) information, to their registrar in order to enable DNSSEC for their domain names.
Cache Poisoning, also known as a “Man in the Middle” attack, explained

Internet user enters an intended destination in his or her browser. This generates a DNS query which first looks for a response from the nearest possible source, a recursive (or “caching”) name server. A name server’s function is to match the URL, e.g.,: www.neustar.biz, to a series of numbers which are its IP address.
If any other Internet user who shares that recursive name server, usually based on Internet Service Provider (ISP), has recently entered the same URL, the answer will be stored with that caching server. Rather than sending the query on to an authoritative name server, the cached response will be provided to the user.

If the cached response for that URL has been replaced, or poisoned, through the repeated replacement of the actual answer with a spoofed answer by a malicious actor, often referred to as a “black hat,” the user will see what appears to be the intended destination, but is not. This can result in the end user providing personal and/or financial information to an unintended recipient, and can compromise the reputation of the intended destination.
From registrants to registrars to the registry, and from ISP’s to hardware vendors to browsers, such as Internet Explorer, Firefox, and Safari, all have a role to play in making DNSSEC a success.
Neustar recommends that network managers test to ensure that their network can handle the larger DNS responses that DNSSEC requires using publicly available tools such as:
Reply-size test available at DNS-OARC: https://www.dns-oarc.net/oarc/services/replysizetest
Ripe Labs’ ‘Test your DNS Resolver’ http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues

Important Dates
Neustar’s Role
Neustar’s Registry team has been working with the Internet Engineering Task Force (IETF) on the development of DNSSEC standards and related changes and updates for many years. Neustar is currently in the final stages of implementation across the zones it operates, and we are methodically testing and refining our systems.
Neustar is committed to an increasingly secure, stable Internet and continues to invest in both our operational infrastructure and our commitment to participation in the community. Going forward, ICANN has mandated that all new TLD’s be DNSSEC-enabled. Successful signing of .BIZ and .US will position Neustar as a proven partner.
Neustar’s service offerings underscore our position in the community, and include DNSSEC, Registry Lock, and the proactive monitoring of the zones we operate to identify malicious behavior and maintain integrity.
Read more about our plans and involvement here
To learn more, please contact Support at +1 (888) 415-0365.

The .US zone was signed on December 8, 2009 and began accepting records on June 7, 2010.
Below are the DNSSEC keys used to sign the .US zone. The key information is useful for DNSSEC-aware resolvers to verify the zones.
Bind Style
trusted-keys.txt | (PGP Signature)
Zone File Format
trust-anchors.txt | (PGP Signature)
Zip File
DOWNLOAD keys and anchors
Also, the PGP signature was generated using PGP Key ID 2C603A2129125555

The .BIZ zone was signed on July 8, 2010 and began accepting records on June 15, 2010.
Below are the DNSSEC keys used to sign the .BIZ zone. The key information is useful for DNSSEC-aware resolvers to verify the zones.
Bind Style
trusted-keys.txt | (PGP Signature)
Zone File Format
trust-anchors.txt | (PGP Signature)
Zip File
DOWNLOAD keys and anchors
Also, the PGP signature was generated using PGP Key ID DD19A228
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 5910: DNSSEC Mapping for the Extensible Provisioning Protocol (EPP)
RFC 4641: DNSSEC Operational Practices
RFC 5074: DNSSEC Lookaside Validation (DLV)
RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
What is DNSSEC?
DNSSEC stands for Domain Name System (DNS) Security Extensions, which enable DNS clients (resolvers) to (1) validate origin authentication of DNS data; (2) confirm data integrity; and (3) authenticate denial of existence.
What problem does DNSSEC solve?
When implemented end-to-end, DNSSEC protects end users from exposure to DNS cache poisoning. Cache poisoning is a corruption of the DNS that enables the spread of viruses, worms, and other malicious files/content. Cache poisoning occurs when data is provided to a caching name server that did not originate from an authoritative Domain Name System (DNS) source. Once a DNS server receives non-authentic data and caches it for future use, it will then supply that non-authentic data to its client servers. The impact of cache poisoning on end users is that they may be directed to IP addresses they did not intend to reach, and may not be aware of the associated risks.
Which problems does DNSSEC NOT solve?
DNSSEC does not solve Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks on any system. DNSSEC does not prevent incorrect data entry into a zone (if the IP address is entered wrong, it will not be corrected). DNSSEC’s improvement to other applications is limited to ensuring that applications get correct/authenticated information and nothing more. Phishing attacks are still possible through carefully crafted email and spam delivery, sensitive information such as credit card numbers on a web server are encrypted via secure socket layers (SSL), and not through DNSSEC.
How does DNSSEC work?
DNSSEC uses cryptographic electronic signatures (referred to as public and private keys) to determine the authenticity of data. DNS clients that are DNSSEC-enabled will validate any DNS response received by automatically checking the authenticity of the cryptographic signatures. If the key is missing or not recognized, the response is not validated and the DNS will not pass the false information on to the user.
What’s the process for implementing DNSSEC?
At this time, Neustar has fully deployed DNSSEC for both the .BIZ and the .US TLDs, and is accepting submissions, known as DS records, in both zones. Our .US and .BIZ-accredited registrars will be able to register DNSSEC information on their customers’ behalf in the Neustar registry.
Did DNSSEC at the TLD registry-level impact the signing of the root zone, and vice-versa?
Neustar’s signing of the .US and .BIZ TLD zones did not impact or interfere with the signing of the root zone. The signing of the root zone on July 15, 2010 represented a seamless transition that did not require incremental development work by registries, registrars, or registrants.
When will DNSSEC be available to .US and .BIZ registrars?
Neustar first offered DNSSEC to.US registrants through accredited registrars effective June 7th 2010, and .BIZ as of August 1, 2010. Please contact Neustar Registrar Support at support@neustar.biz for more information.
Is there a requirement that registrars implement DNSSEC?
.US and .BIZ-accredited registrars are not required to implement DNSSEC at this time. Support for DNSSEC is optional but recommended to help secure and prevent cache poisoning in the .US and .BIZ domains.
When will DNSSEC be available to registrants for their domain names?
.US and .BIZ registrants should contact their registrar of record to determine if and when the registrar will support DNSSEC.
How is a DNSSEC query formed?
A DNSSEC query is formed by a DNS resolver. Recent versions of BIND have already been forming DNSSEC queries but have not been reacting to the resulting DNSSEC responses. In order to react to the DNSSEC responses in a way that makes use of DNSSEC, resolvers need to be configured with the root’s DNSSEC public key.
How does a registrant sign a zone?
If the registrant is using a DNS managed service provider, they should contact the provider for instructions to turn on DNSSEC. If the registrant is operating their own DNS set up, there are a number of steps to perform. First, make sure the tools in use are capable of DNSSEC. This may mean upgrading the DNS software. Second, after preparing and documenting a plan, create cryptographic key pairs and enter them in the zone. Third, run a DNSSEC zone signer (dependent on the tools in use) to generate the first signed zone. The process of signing will have to be repeated as the signatures will have a limited lifetime. The final step is to publish the zone. The managed service provider should be able to provide guidance along the way.
If you operate a country code TLD, our gateway services help you grow beyond your national market by connecting you to our global registrar and DNS networks. You also get instant access to a worldwide customer base eager to establish a presence within your TLD. Neustar will custom-build an interface to your registry, allowing our growing roster of registrars to connect using standard protocols. We pass all transactions to your registry, plus sign up registrars and fully manage those relationships.
Anybody pursuing a new gTLD — for instance, .yourbrand or.yourcity — can depend on Neustar’s experience and comprehensive solutions. Organizations throughout the world are relying on our services to take full advantage of this major opportunity.
Neustar is a leading provider of Internet Addressing Registry services. Our leading edge technology and comprehensive suite of domain name services can provide your business with a competitive advantage in the Top Level Domain marketplace. We offer full backend registry solutions, gateway services, and primary and secondary DNS services. We currently provide domain name registry services for .biz, .us, kids.us, .cn, .tw, .travel, .tel and 4U.com. In addition, we operate the global XRI registry.
Formed in 2001 to operate the .BIZ TLD, NeuLevel was a joint venture between Neustar and the domain registrar Melbourne IT. In 2006, Neustar acquired 100% ownership in the NeuLevel joint venture. Neustar’s Registry is now operated solely under the Neustar name.
Neustar is a leading provider registry and DNS services. We are the registry operator for .biz and .us. We provide registry gateway services for .cn and .tw, and the registry back-end for the .travel, .tel, and 4u.com. In addition, we provide primary or secondary DNS for over 20 other TLDs.
An Internet domain name Registry is an entity that receives domain name system (DNS) information from domain name Registrars, inserts that information into a centralized database and publishes the information in Internet zone files on the Internet so that domain names can be found by users around the world via applications such as the World Wide Web and e-mail. In short, the Registry creates and maintains the database of domain names for a given top-level domain.
Registrars are the officially accredited retailers of domain names. The Neustar Registry does not offer domain registrations directly to the public. All registrations are done through accredited registrars who connect to the registry. A list of accredited registrars for the TLDs we offer may be found here.
A registrant is the official holder of a domain name. The registrant of record may be found by performing a Whois query on a domain name.
A TLD is a name at the top of the DNS naming hierarchy. They appear in domain names as the string of letters following the last (rightmost) “.”. Examples of TLDs include .biz, .com, and .us.
A Registry provides direct services to Registrars only, not to the end users of a Registry’s services. An Internet domain name Registry is an entity that is responsible for delegating Internet addresses such as domain names, and keeping a centralized database of those addresses and the information associated with their delegation. A Registry is responsible for providing the DNS infrastructure to resolve domain names.
A Registrar provides direct services to domain name Registrants. Registrars process name registrations for Internet end users and then send the necessary DNS information to a Registry for entry into the centralized Registry database and ultimate distribution over the Internet. There are multiple Registrars providing registration services through the Neustar Registry.
No. Historically on the Internet, Registry and Registrar functions were most often provided by the same organization. More recently, these functions for some of the Internet’s top-level domains have been split to allow for competition in the registration services business.
Neustar’s primary customers are the registrars who have signed contracts with Neustar to provide domain name registration services in the TLDs we offer.
The Shared Registration System (SRS), developed by the Neustar Registry, gives Registrars the ability to add, modify and delete information associated with domain names, name servers, contacts, and Registrar profile information on a real-time basis. Registrars may administer domains, manage name servers, manage their Registrar information and generate reports. It is important to note that each Registrar may only effect information about domain names for which it is responsible. In addition, telephone and e-mail customer support is available for all Registrars associated with the Neustar Registry.
The most important service that the Neustar Registry provides is the creation of the top-level domain (TLD) zone files, and the publication of those files to the Internet’s TLD servers. These files are the master “white pages” of the Internet, and enable a domain name to correlate to an Internet Protocol (IP) number.
The most visible Neustar Registry service that is available to Internet end users, besides general information provided on the Neustar Registry Services web site, is the Whois databse. This service is available to anyone. The available information includes the registrant, billing, technical and administrative contacts, name servers, and domain status.
Domain names may be registered through any registrar accredited in the TLD you are interesting in registering. Neustar does not offer domain registrations directly to the public. The list of registrars can be found here.
The list of accredited registrars can be found here.
WHOIS provides information on individual domain registrations. The information provided may vary from TLD to TLD, but it typically includes the domain name, sponsoring registrar, key dates, name server information, and contact information.
An <AUTHINFO> code is a six to 16-character “password” assigned by a sponsoring Registrar. This code is used in various situations to verify that the registrant has authority over the domain name. The most common use of the <AUTHINFO> code is to authorize the transfer of a domain from one registrar to another. No domain name transfer request can be successfully executed without this password. Registrars are contractually required to provide this code upon registrant request. Registrants are advised to protect their <AUTHINFO> codes to avoid unauthorized transfers of domain names.
Neustar provides access to the .BIZ Zone file. Please complete and sign the .BIZ Zone Access agreement found here. We will review the application for eligibility and issue the necessary credentials for access to the .BIZ Zone File.
Neustar reserves the right to deny any application that is deemed ineligible for any reason, including but not restricted to a previous cancellation of credentials due to abuse.
Please contact Registry Customer Support {support@Neustar.biz} with additional questions.
If you have already registered and have a User ID and Password, simply click here to download the .BIZ Zone File
A Neustar Registrar has access to all the resources you need to prepare to sell the TLDs we offer, including documentation and toolkits, technical support, advance notice of upcoming products and marketing materials. These resources include co-marketing and joint PR opportunities and online account management.
The process for becoming a Registrar varies from TLD to TLD, but in general an applicant will need to sign an agreement with the Registry and complete the following:
Registrar Information Package
Financial Qualification
Technical Certification
Business Requirements
For gTLDs administered by ICANN, applicants must first become accredited through ICANN. To get more information on becoming a Neustar Registrar, please contact the Neustar Registrar Relations Team at registrarsignup@Neustar.biz.
The Neustar Registrar Extranet is Neustar’s premier web site for organizations that offer our TLDs and services. The web site provides Registrars with information on our products and services as well as events, marketing resources and certification program information.
IDNs are domain names that are spelled using native language, non-ASCII characters that may not appear in the English alphabet. The .biz registry currently offers IDN registrations in 15 languages, for your convenience and use. More will be coming in the future.
Typically, when a browser sees a host name, it sends a request to the DNS resolver service. The resolver service then sends a request to a domain name server to return an IP address corresponding to that host name. When the IP address is returned, a connection is made to the appropriate Web server.
In the case of IDNs, when a browser sees either (1) a non-ASCII character host/domain name in its location bar, or (2) a URL with a non-ASCII domain part embedded in a web page, the application is required to convert the non-ASCII characters into a special encoded format (Punycode) using only the standard ASCII subset characters. Punycode is the official IETF standard that has been approved for converting IDN domains into machine-readable and resolvable ASCII domains.
Punycode is required for IDN conversion because a restriction (that only a subset of ASCII characters be used in URL/URI at the network protocol level) is still enforced, even though IDNs have been introduced.
When a compliant browser receives input for an IDN, it converts the native language IDN into Punycode. In other words, the native language IDN is converted into an ASCII string (prefixed with xn--) that can then be looked up at the TLD nameserver to determine the location of the website. The xn-- prefix was accepted as the IDNA standard by the Internet Assigned Numbers Authority (IANA) on February 14, 2003.
Browsers which support this functionality include Netscape 7.1, Mozilla 1.4, Opera 7 and Firefox 1.0. It is anticipated that all later versions of these browsers will also support IDNs.
The registrant must first contact an ICANN-accredited registrar and submit the IDN request.
The name(s) to be registered in the IDN database must be converted into the alphanumeric representation based on the Punycode IDN standard. (The registrar performs the conversion of the IDN local language characters into the equivalent Punycode.)
The unique IDN is placed into the Neustar registry IDN database.
In a compliant browser (e.g., Netscape 7.1, Mozilla 1.4, Opera 7, Firefox 1.0), simply type the IDN in the address bar or click an active link. The browser does the necessary conversions and the IDN resolves to the desired site.
Neustar’s IDN solution does meet the ICANN guidelines. Our implementation is a standards-compliant service that enhances the user experience and does not deviate from adopted standards.
Neustar’s IDN implementation is compliant with ICANN IDN guidelines and the approved IETF standards (RFCs 3490, 3491, and 3492). Other registries that launched IDNs prior to the adoption of these standards may or may not be compliant.
Registrars that support various IDNs in the .BIZ domain can be found here.
Neustar’s web-based Whois and Port 43 Whois output will display both the registered Punycode name (Unicode HEX sequence representing the registered IDN) as well as an HTML-encoded display of the IDN name in its native language form.
Registering a domain name solely for the purposes of (1) selling, trading or leasing the domain name for compensation, or (2) the unsolicited offering to sell, trade or lease the domain name for compensation does not constitute a “bona fide business or commercial use” of that domain name.
.BIZ is the world’s first Internet-based environment dedicated exclusively to the business community. It is much more than just another domain name.
.BIZ domains may be registered through accredited registrars. A list of accredited registrars may be found here.
Yes, Neustar offers .BIZ IDN registrations in a number of languages. New languages are periodically made available. View the Neustar IDN Language Support Guide to see a list of the current languages offered in the Neustar.
Yes, Neustar’s .BIZ IDN solution is fully compliant with ICANN’s Guidelines for Implementation of IDNs Version 2.2.
The .BIZ web-based Whois and Port 43 Whois output will display both the registered Punycode name (Unicode HEX sequence representing the registered IDN) as well as an HTML-encoded display of the IDN name in its native language form.
.BIZ IDNs may be registered through participating accredited registrars. Not all registrars offer IDNs. A list of participating registrars may be found here .
The registrant of a .BIZ domain may be found by performing a Whois query on the domain. The official .BIZ Whois may be found here.
To obtain access the .BIZ Zone file, you must complete, sign and return the Zone File Access Agreement to obtain FTP access credentials. This agreement should be faxed to 571-434-5758. If you have additional questions please email support@Neustar.biz.
A list of upcoming domain deletions from the registry can be obtained from Report 2 for each TLD found here.
Yes. The .BIZ domain can only be used for a “bona fide business or commercial use”. A bona fide business use is one of the following:
Yes, certain domain names have been reserved by ICANN and/or Neustar. These domain names are not available for registration. The current list of reserved domains can be found here.
In general, there are two dispute-resolution policies in effect for .BIZ:
All domain name Registrants are bound by the Restrictions Dispute-Resolution Policy. This policy may be invoked by a third party in order to resolve a dispute with a Registrant over the registration or use of the Registrant’s domain name in violation of the .BIZ domain name registration restrictions. Such a violation would include complaints that the domain name is not being, or will not be, used primarily for a bona fide business or commercial purpose.
The provisions of the Uniform Dispute-Resolution Policy bind all Registrants in the .BIZ top-level domain. According to ICANN, under the UDRP, most types of trademark-based domain name disputes must be resolved by agreement, court action, or arbitration before a Registrar will cancel, suspend, or transfer a domain name. Disputes that arise from abusive registrations of domain names (e.g., cyber squatting) can be addressed by expedited administrative proceedings that the trademark holder initiates by filing a complaint with an approved dispute-resolution service provider. To invoke the policy, a trademark owner should either (a) file a complaint in a court of proper jurisdiction against the domain name holder (or where appropriate an in-rem action concerning the domain name) or (b) in cases of abusive registration, submit a complaint to an approved dispute-resolution service provider.
Domain name transfers fall in one of two categories:
Registrant Transfer or Name Change – Each Registrar has unique requirements for making changes to the registrant field of a domain name. Registrants must contact the sponsoring Registrar for information regarding Registrant Name Changes and/or Transfers. The sponsoring Registrar appears in line 3 of each domain name’s WHOIS record Registry Whois
Registrar-to-Registrar Transfer – ICANN rules require that a domain name be registered for a minimum of 60 days, and be in OK status with the current sponsoring Registrar before it can be transferred to another Registrar. If your domain name meets these requirements, contact your current sponsoring Registrar and request the <AUTHINFO> code. The <AUTHINFO> code is needed to initiate a transfer. To initiate transfer request contact the NEW registrar and follow their transfer procedures. They will require the <AUTHINFO> code and they may also require further authorization from the registrant or other domain contact. This is often done via email. Once the transfer request is submitted to the Registry, the domain will be place in pendingTransfer status. The domain may stay in pendingTransfer status for up to 5 days.
To modify name server, contact or registrant information, please contact your Registrar directly. As the Registry, Neustar cannot make modifications submitted by domain name registrants.
Contact your Registrar and ask a supervisor or manager to contact Neustar at support@Neustar.biz, with an explanation as to why they are not able to access your domain name record. The Registry Customer Support team will work with the registrar to ensure they have access to your domain name.
Domains that do not have at least two name servers are automatically placed in “inactive” status. An inactive status means that domain will not be published in the zone file and will not resolve on the Internet. Once the domain is updated to have at least two name servers, the domain will automatically be taken off inactive status.
Some sponsoring registrars use the “clientTransferProhibited” status to protect their customers’ domains from potential unauthorized transfers. If you wish to transfer your domain to another registrar, you will need to contact your current registrar to remove this status before your new registrar can successfully transfer your domain.
A domain name goes into “pendingDelete” status any time it is deleted after the first 5 days of registration. A domain that is deleted within the first 5 days of registration will be released immediately and made available again for registration. A domain name that is “pendingDelete” is also either “RESTORABLE” or “SCHEDULED FOR RELEASE”. The registrar of record can restore a “pendingDelete” domain within 30 days from the delete date. A “SCHEDULED FOR RELEASE” domain name is not restorable, and can only be re-registered after it deletes from the registry. To restore a “pendindDelete (RESTORABLE)” domain name, please contact the domain’s registrar of record for assistance.
The Redemption Grace Period (RGP) is a period of time after a domain is deleted in which it may be recovered (restored). Only domains deleted after the initial five days of registration may be restored. The RGP in .BIZ lasts for 30 days from the time of deletion. Following the RGP the domain will remain in pendingDelete status for an additional five days before being released. During this five day period, the domain may not be restored. To determine if a domain is restorable check the Neustar Whois. A domain that is restorable will show a status of “pendingDelete (Restorable).” To restore your domain contact your registrar.
Neustar provides access to the .BIZ Zone file. Please complete and sign the .BIZ Zone Access agreement found here. We will review the application for eligibility and issue the necessary credentials for access to the .BIZ Zone File.
Neustar reserves the right to deny any application that is deemed ineligible for any reason, including but not restricted to a previous cancellation of credentials due to abuse.
Please contact Registry Customer Support {support@Neustar.biz} with additional questions.
If you have already registered and have a User ID and Password, simply Login Here
On December 4, 2002, President George W. Bush signed into law the Dot Kids Implementation and Efficiency Act of 2002. This Act requires that Neustar, “as the administrator of the .US country code top-level domain (ccTLD), establish a kids.us domain to serve as a haven for material that promotes positive experiences for children and families using the Internet, provides a safe online environment for children, and helps to prevent children from being exposed to harmful material on the Internet.” Neustar currently maintains and operates the second-level kids.us domain as a safe place on the Internet for children aged 13 or younger. For more information on kids.us domain names, please visit www.kids.us
.US domains may be registered through any accredited registrar. A list of .US accredited registrar may be found here.
Yes. Registration of .US domains is limited to individuals or organizations who meet the .US Nexus policy. Any U.S. citizen or resident, as well as any business or organization, including federal, state, and local government with a bona fide presence in the United States can register a .US domain name.
One of the following eligibility requirements must be met:
a) A natural person (i) who is a citizen or permanent resident of the United States of America or any of its possessions or territories or (ii) whose primary place of domicile is in the United States of America or any of its possessions, or
b) Any entity or organization that is incorporated within one of the fifty (50) U.S. states, the District of Columbia, or any of the United States possessions or territories or (ii) organized or otherwise constituted under the laws of a state of the United States of America, the District of Columbia, or any of its possessions or territories, or
c) An entity or organization (including federal, state, or local government of the United States, or a political subdivision thereof) that has a bona fide presence in the United States. See Section B.3.1 of the Neustar proposal to the Department of Commerce for details concerning what constitutes a “bona fide presence.”
To obtain access the .US Zone file, you must complete, sign and return the Zone File Access Agreement to obtain FTP access credentials. This agreement should be faxed to 571-434-5758. If you have additional questions please email support@Neustar.biz.
.US does not currently offer IDN registrations. However, we suggest you periodically check the official .US website for updates.
Additional information about .US, including information on kid.us, policies and FAQs can be found on the official .US website.
A list of upcoming domain deletions from the registry can be obtained from Report 2 for each TLD found here.
DNSSEC stands for Domain Name System (DNS) Security Extensions, which enable DNS clients (resolvers) to (1) validate origin authentication of DNS data; (2) confirm data integrity; and (3) authenticate denial of existence.
When implemented end-to-end, DNSSEC protects end users from exposure to DNS cache poisoning. Cache poisoning is a corruption of the DNS that enables the spread of viruses, worms, and other malicious files/content. Cache poisoning occurs when data is provided to a caching name server that did not originate from an authoritative Domain Name System (DNS) source. Once a DNS server receives non-authentic data and caches it for future use, it will then supply that non-authentic data to its client servers. The impact of cache poisoning on end users is that they may be directed to IP addresses they did not intend to reach, and may not be aware of the associated risks.
DNSSEC does not solve Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks on any system. DNSSEC does not prevent incorrect data entry into a zone (if the IP address is entered wrong, it will not be corrected). DNSSEC’s improvement to other applications is limited to ensuring that applications get correct/authenticated information and nothing more. Phishing attacks are still possible through carefully crafted email and spam delivery, sensitive information such as credit card numbers on a web server are encrypted via secure socket layers (SSL), and not through DNSSEC.
DNSSEC uses cryptographic electronic signatures (referred to as public and private keys) to determine the authenticity of data. DNS clients that are DNSSEC-enabled will validate any DNS response received by automatically checking the authenticity of the cryptographic signatures. If the key is missing or not recognized, the response is not validated and the DNS will not pass the false information on to the user.
At this time, Neustar has fully deployed DNSSEC for both the .BIZ and the .US TLDs, and is accepting submissions, known as DS records, in both zones. Our .US and .BIZ-accredited registrars will be able to register DNSSEC information on their customers’ behalf in the Neustar registry.
Neustar’s signing of the .US and .BIZ TLD zones did not impact or interfere with the signing of the root zone. The signing of the root zone on July 15, 2010 represented a seamless transition that did not require incremental development work by registries, registrars, or registrants.
Neustar first offered DNSSEC to.US registrants through accredited registrars effective June 7th 2010, and .BIZ as of August 1, 2010. Please contact Neustar Registrar Support at support@Neustar.biz for more information.
.US and .BIZ-accredited registrars are not required to implement DNSSEC at this time. Support for DNSSEC is optional but recommended to help secure and prevent cache poisoning in the .US and .BIZ domains.
.US and .BIZ registrants should contact their registrar of record to determine if and when the registrar will support DNSSEC.
A DNSSEC query is formed by a DNS resolver. Recent versions of BIND have already been forming DNSSEC queries but have not been reacting to the resulting DNSSEC responses. In order to react to the DNSSEC responses in a way that makes use of DNSSEC, resolvers need to be configured with the root’s DNSSEC public key.
If the registrant is using a DNS managed service provider, they should contact the provider for instructions to turn on DNSSEC. If the registrant is operating their own DNS set up, there are a number of steps to perform. First, make sure the tools in use are capable of DNSSEC. This may mean upgrading the DNS software. Second, after preparing and documenting a plan, create cryptographic key pairs and enter them in the zone. Third, run a DNSSEC zone signer (dependent on the tools in use) to generate the first signed zone. The process of signing will have to be repeated as the signatures will have a limited lifetime. The final step is to publish the zone. The managed service provider should be able to provide guidance along the way.
A general collection of information on DNSSEC can be found above.
The .CN Gateway is an EPP registration system provided to registrars located outside of China. It provides registrars with the ability to connect to the Registry and submit EPP transactions. Support, billing, and reporting are provided by Neustar.
CNNIC is the official administrator of the .CN Registry.
China Internet Network Information Center (CNNIC) is the state network information center of China, which was founded as a non-profit organization in June, 1997.
CNNIC takes direction from the Ministry of Information Industry (MII) to conduct daily business, while it is administratively operated by the Chinese Academy of Sciences (CAS). The Computer Network Information Center of Chinese Academy of Sciences takes the responsibility of running and administrating CNNIC. The CNNIC Steering Committee is a working group composed of well-known experts and commercial representatives in the domestic Internet community which supervises and evaluates the structure, operation and administration of CNNIC.
CNNIC has partnered with Neustar to provide Registry gateway services for the .CN domain. CNNIC is the administrator of the domain, setting policy and service levels, running the .CN TLD Whois and generating the .CN TLD zone file.
.CN offers registrants the protection of a well-established brand name in what has become one of the most lucrative marketplaces in the world. In addition, .CN can put Chinese customers at ease, giving them the security of dealing with businesses that have a substantial, “localized” Chinese presence as well as an international one. Finally, .CN enjoys widespread notoriety and recognition among the Chinese population, and is a simple and memorable Web domain.
No. Neustar only offers .CN domain names through .CN accredited Registrars who are located outside of China.
Yes. .CN domains may be registered at the second level, in addition to various third level options.
There are many third-level registration options available. The most common third-level options are com.cn, net.cn, and org.cn. In addition, the following options are offered:
| ah.cn | bj.cn | cq.cn |
| fj.cn | gd.cn | gs.cn |
| gx.cn | gz.cn | ha.cn |
| hb.cn | he.cn | hi.cn |
| hk.cn | hl.cn | hn.cn |
| jl.cn | js.cn | jx.cn |
| ln.cn | mo.cn | nm.cn |
| nx.cn | qh.cn | sc.cn |
| sd.cn | sh.cn | sn.cn |
| sx.cn | tj.cn | tw.cn |
| xj.cn | xz.cn | yn.cn |
| zj.cn |
For additional information, contact your registrar.
Yes. Chinese language IDNs are available at the second level, under .CN. Domains may be registered in either Simplified or Traditional Chinese, or a mixture of both. Variants of the registered domain will automatically be blocked. For additional, information contact your registrar.
The official .CN Whois, operated by CNNIC, may be found here.
No. A company or an organization does not need to have a subsidiary in China.
.CN registrations are intended for business and organizations.
Users may elect to utilize the Chinese Dispute Resolution Process to resolve disputes through CNNIC-designated arbitration providers. This process is very similar to the UDRP arbitration process. Of course, as is the case in all TLD disputes, users may also elect to pursue resolution in the courts.
.CN domains may be transferred from one registrar to another, regardless of whether the registrars are domestic or international. To initiate a transfer, contact the gaining registrar (the registrar you wish to transfer to) and follow their transfer procedures.
Modifications to your .CN domain may be done through your registrar. Contact your registrar for assistance.
Contact your Registrar and ask a supervisor or manager to contact Neustar at support@Neustar.biz, with an explanation as to why they are not able to access your domain name record. The Registry Customer Support team will work with the registrar to ensure they have access to your domain name.
Domains that do not have at least two name servers are automatically placed in “inactive” status. An inactive status means that domain will not be published in the zone file and will not resolve on the Internet. Once the domain is updated to have at least two name servers, the domain will automatically be taken off inactive status.
Some sponsoring registrars use the “clientTransferProhibited” status to protect their customers’ domains from potential unauthorized transfers. If you wish to transfer your domain to another registrar, you will need to contact your current registrar to remove this status before your new registrar can successfully transfer your domain.
Domains that are deleted during that auto-renew grace period are automatically placed in pendingDelete status for 15 days.
Yes. Contact your registrar for additional information and procedures for restoring a domain.
The .TW Gateway is an EPP registration system provided to registrars located outside of Taiwan. It provides registrars with the ability to connect to the Registry and submit EPP transactions. Support, billing, and reporting are provided by Neustar.
The .TW Registry is operated by the TWNIC (Taiwan Network Information Center).
The TWNIC (Taiwan Network Information Center) is the unique neutral and non-profit organization that takes charge of the domain name registration and IP address allocation in Taiwan. Besides offering full range network services, the TWNIC participates in various related international conferences, in hopes to provide the best services for network service providers in Taiwan through pubilc participation and constant improvements, which are the biggest goal of the TWNIC.
Neustar does not sell domains retail. TW domain names are offered through .TW-accredited Registrars.
As the next frontier of global e-business, .TW presents companies everywhere with an unprecedented opportunity to make inroads into the Taiwan marketplace. Now is an ideal time for companies to protect their brand identities in .TW.
Yes. Chinese language IDNs are available at the second level, under .TW. Domains may be registered in Traditional Chinese only. Variants of the registered domain will automatically be blocked. For additional, information contact your registrar.
The official .TW Whois, operated by TWNIC, may be found here.
Although .TW policy is permissive in terms of registration, and enforcement is generally in reaction to a complaint (as opposed to proactive review), registrations that are not associated with an organization or business may be subject to deletion. This does not in any way prevent an individual from registering a .TW domain name for a business operating as a sole proprietorship.
No, a local presence is not required.
Yes. Domains may be registered at the second level or third level
Third-level domains may be registered under com.tw, org.tw, idv.tw, club.tw, game.tw, and ebiz.tw.
TWNIC has posted a policy regarding IP disputes on its website. The policy is very similar to the Uniform Dispute Resolution Policy (UDRP) common in other Web domains. Visit http://www.twnic.net.tw/english/dn/dn_04.htm to learn more.
.TW domains may be transferred from one registrar to another, regardless of whether the registrars are domestic or international. To initiate a transfer, contact the gaining registrar (the registrar you wish to transfer to) and follow their transfer procedures.
Modifications to your .TW domain may be done through your registrar. Contact your registrar for assistance.
Contact your Registrar and ask a supervisor or manager to contact Neustar at support@Neustar.biz, with an explanation as to why they are not able to access your domain name record. The Registry Customer Support team will work with the registrar to ensure they have access to your domain name.
Domains that do not have at least two name servers are automatically placed in “inactive” status. An inactive status means that domain will not be published in the zone file and will not resolve on the Internet. Once the domain is updated to have at least two name servers, the domain will automatically be taken off inactive status.
Some sponsoring registrars use the “clientTransferProhibited” status to protect their customers’ domains from potential unauthorized transfers. If you wish to transfer your domain to another registrar, you will need to contact your current registrar to remove this status before your new registrar can successfully transfer your domain.
Your Domain name has expired. When this happens, TWNIC will put the name in the pendingDelete status for 33 days, after which time, the name will be deleted. During that 33 day period of time the name can be renewed which adds a year to the original expiration date and removes pending delete. The registrant should contact their registrar to update the domain name registration.
The .TW TLD does not have a Redemption Grace Period process.


