Yes, you can register a .IS domain!
For further information see Domain Registration in ISNIC's rules.
If you have your own nameservers, you must have configured the domain and the nameservers must be registered with ISNIC. If you do not have any nameservers yet, you can park your domain with ISNIC until you have decided on where to host your domain. See "Domain->Requirements" and "Nameserver->Requirements" . You must also have available the NIC-handles of the domain's contacts, and you yourself must be logged in via "Contacts->Login" . If contact handles are unavailable, you must first register the contacts (and/or yourself) via "Contacts->Register" on the left.
Once logged in, proceed to the registration page ("Domains->Register") and follow the instructions. Your application will be queued, pending payment of registration fees. Note that you have two days to remit the fee, after which the application expires and must be resubmitted if payment is made. Payment can be made on-line using the login information of the Administrative contact or Billing contact of the domain.
All .is domain's are registered in the ISNIC domain registry and their registration information is available via the ISNIC web. However, the registration WHOIS lookup is rate-limited and does not include pending domains. Use a suitable whois client on port 4343 to determine if a particular domain is available for registration. (Or use http://whois.isnic.is:4343/domain.is). These lookups are not rate-limited.
Usually, a domain's adminstrative contact is simply the registrant. If the registrant wants someone else to have full change-control over the domain, a third party can be appointed administrative contact.
Please note that the admin contact has full, web-based control of the domain, including the ability to transfer the domain to a new registrant. It is the registrants responsibility to ensure that proper contracts exist between a third-party administrative contact and the registrant.
Domains can have up to four different contacts (NIC-Handles) in addition to the registrant. Each contact serves a different role and holds different change-authority over the domain. The contacts and the registrant use their NIC-Handles to log into the ISNIC web to modify their own, and their domain's registration.
Note that each contact can change their own registration information but only the domain's registrant and administrative contact can substitute the domain's existing contacts for new ones.
- The Registrant (R) has full change-control over the domain, if the registrant contact has been activated (see How do I activate a contact object). The registrant can change all aspects of the domain's registration, including transferring the domain to a new registrant and deleting the domain.
- The Administrative Contact (AC) has full change-control over the domain and exercises this control on behalf of the registrant. The AC can change all aspects of the domain's registration, including requesting the transfer of the domain to a new registrant or deletion of the domain. Transfers and deletes need registrant approval. If the registrant decides to delegate all management of the domain to a third-party, that party should then be registered as the domain's administrative contact. See What is the role of the domain's administrative contact? The AC can withdraw their services and the registrant will then automatically become the AC.
- The Technical Contact (TC) handles the technical aspects of domain management, it's DNS hosting, web hosting etc. The TC is most often with the domain's network provider. The registrant or the administrative contact can substitute the TC for a new one. The TC can withdraw their services and the AC will then automatically become the technical contact.
- The Billing Contact (BC) is the recipient of the domain's billing information. The domain's invoices are addressed to the BC. Most often the BC is the registrant himself. The domain's R and AC must make sure that the appropriate party is registered as the domain's BC at all times. Only the R and AC can substitute the BC for a new one. The BC can withdraw his services and the R will then automatically become the billing contact. Bills are never re-issued to the new BC. Upon request, a receipt will be issued to the new BC after the domain's fees have been paid.
- The Zone contact (ZC) is the technical contact for the domain's nameservers. The ZC owns the domain's master nameserver and is responsible for the domain's compliance with the .is technical delegation requirements. The ZC must be willing and able to configure the nameservers according to these requirements. The ZC is automatically updated when the domain is redelegated to a new set of nameservers.
The same party can perform all these functions, i.e. the same NIC handle can be registered as the domain's R,AC,TC,BC, and even ZC. However, if they are not the same, the set of available operations depends on who is logged in to the ISNIC portal according to the following table:Contact Operation R AC TC BC ZC Modify Registration Yes Yes Yes Yes No Registrant Transfer Yes Yes No No No Substitute Contacts Yes Yes No(+) No(#) No Renew registration (BC is not ISP) Yes Yes Yes Yes No Renew registration (BC is ISP) No No No Yes No(~) Redelegate domain Yes Yes Yes No No(*) Modify DS records Yes Yes Yes No No Delete domain Yes Yes No No No Autorenewal (on/off) Yes Yes No Yes No Resign as contact No Yes(#) Yes(+) Yes(#) No + (AC and BC can withdraw their services (resign) R automatically substituted.) # (TC can withdraw their services (resign) AC automatically substituted.) * (ZC of domains hosted with a registered service provider can redelegate) ~ (All ISP contacts can also renew the domain)
The annual renewal fee is EUR 29.90. The first year fee (the registration fee) must be prepaid before registration can proceed.
Please note that the first year fee must be prepaid within two (2) days of sending in the application. The application will not be processed unless the registration fee is paid.
The last step of the registration process allows the registrant to select to pay the fees using a creditcard. The registrant can also register the card details with ISNIC and register his/her domains for automatic renewal. In this case the renewal fee will be debeted to the card 60 days prior to its expiry date, automatically.
Existing domains can similarly be registered for automatic renewal. The domain's administrative or billing contact logs on the ISNIC web, selects Automatic renewal, and clicks Register for automatic renewal for the each domain where automatic renewal is desired, either selecting to use their already registered creditcard, or registering one for the renewal. The domain will then be renewed 60 days prior to its expiry date, automatically every year while the card is valid. Note that the domain's administrative contact must then explicitly Delete the domain if the registration is no longer desired.
If a domain remains unpaid on it's expiration date, ISNIC informs the domain's billing contact (and the domain's administrative contact) that the domain is about to be deactivated (put on hold). Once the ISNIC staff has verified that no payment has been made, the domain is removed from the .is zone and marked "on-hold" in the whois-registry. This usually happens on the next working day after expiry.
The domain now enters a 60 day grace-period where the domain remains registered but inactive. During this period the registrant can reactivate the domain by paying the renewal fee. No further communications/warnings are issued by ISNIC during this period. After 60 days, the domain is deleted and available for re-registration.
ISNIC can not provide any information on when (exact date) a expired domain will be released for registration again. A .is domain that is not renewed by it's expiration date is put on hold (closed). This is only done after ISNIC has made sure no payment has been recieved and can take a few days.
A domain on hold is not available for registration. The registrant now has 60 days to remit the registration fee, and if the registration fee is recieved by ISNIC the domain is reactivated. Please note that the registrant can explicitly delete the domain any time during these 60 days, making the domain available for registration immediately.
If the domain registration fee remains unpaid after 60 days, ISNIC again takes a few days to make sure no payment has been received and if not, deletes the domain making it available for reregistration. Please note that this process can take a few days (e.g. domains are not deleted on holidays).
In short, it is not possible to know the exact date when a .is domain becomes available for registration again.
Modifications are web-based. You must begin by logging in to the ISNIC web using your NIC-handle and password and select "My page". You will then get a list of domains and nameservers for which you are registered and over which you have change-control. Select the domain/nameserver you wish to modify and follow the instructions. Use "My Settings" for your NIC-handle. In cases where the NIC-handle is also a Registrant, changes will also be visible in the Whois form in relation to the Registrant of those domains.
In general, no. Registrants and contacts who are individuals can withhold the publication of their physical address (home address). Note that the name, country and email address is always published. You can withold the address by going to "My settings" and toggle "Address withheld" to "Yes". Please note that this only applies to individuals (contacts and registrants).
The domains zone contact is the first (master) nameserver's technical contact. It is automatically modified, when the domain is redelegated to a new set of nameservers. The zone contact can thus only be changed by changing the technical contact of the domains current nameserver as registered with ISNIC, or by redelegating the domain to a different set of nameservers.
Delegation record modifications are web-based. Log on to the ISNIC web using your NIC-handle (you must use either the NIC-handle of the registrant, the administrative contact or of the technical contact). On "My page", select the domain you wish to move (change nameservers for), click "Redelegate" on the menu, and follow the instructions.
Note that you can only move your domain to a new set of nameservers if the domain has already been set up on the new nameserver according the ISNIC's technical requirements. Please contact your prospective DNS provider (the operator of the new nameservers) if you experience problems/errors when trying to redelegate your domain.
DNSSEC is an extension to the DNS system which makes it possible to sign DNS records with a key (DNSKEY). Resolvers can verify that the authenticity of the responses. DNSSEC is defined in RFC 4033.
First, the records in your domain have to be signed. For this you can use extensions to popular DNS software such as BIND or 3rd party solutions.
Once the records have been signed and the signatures published in the zone, the DS records for the keys have to be submitted to ISNIC for inclusion in the .is zone. To do that, you go to My page, select the domain from the list and click "Edit DS records".
All nameservers should be set up to validate their answers before giving them to their users. To test if your nameservers (i.e. the ones you are using to navigate the net) are validating try clicking on the following links:
Special care must be taken when modifying delegation records of a DNSSEC signed domain. DS records that are published in the .is zone point to DNSKEY records in the signed domain, and if they are missing, validating resolvers will fail to resolve names in the domain. To safely modify the delegation records of a DNSSEC signed domain, please follow these steps (we assume no access to the private key used to sign the zone. If there is access to the private key, it can simply be moved to the new nameservers along with the domain and be used to continue signing the zone):
- Transfer all domain records (then zone) from the old nameservers to the new nameserver, including DNSKEY records and sign it with the new key
- Copy the new DNSKEY records to the old nameserver
- Add a DS record with ISNIC correspondig to new KSK
- Wait for at least 24 hours. This ensures all resolvers see the new DNSKEY and DS records
- Re-delegate the domain to the new nameservers
- After 24 hours delete the domain from the old nameservers and remove the old DNSKEY records from the new nameservers. Also remove old DS records from ISNIC
It is important that nameservers are registered with ISNIC by the nameserver operator/owner or their technical representative. The nameserver's technical contact becomes the zone contact for all .is domains delegated to the nameserver and therefore must be whoever administers the nameserver. ISNIC contacts the domain's zone contact in case of technical difficulties with the nameservers and this contact must have proper access to the nameserver and be able to fix DNS-technical problems.
To register a nameserver you must have available the nameserver's intended technical contact handle (nic-handle). If that is not available the server administrator must begin by registering a contact object for the nameserver. Once you have obtained and activated the NIC handle assigned you can login to our site and proceed with the nameserver registration by clicking on "Register" under the "Nameservers" heading.
The only way to test a particular UDP service is to query the service that listening on the particular port. Thus the only way to test if a DNS server is running on UDP port 53 is to make a DNS query. As there is no way of knowing which zones are served by that host, so a query for the root zone NS records is made. A secondary query is also made, in case the root zone fails.
To verify that a nameserver is running, a reply is required. It can be any RCODE as long as some reply is sent. A timeout is not acceptable.
According to RFC1035 the RCODE should be one of those below: (RCODE names are from BCP42/RFC2929)SERVFAIL 2 Server failure - The name server was unable to process this query due to a problem with the name server. REFUSED 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data.Or the reply can be NOERROR, with the root zone NS records, but not replying at all is not an option.
It is important to realize that TTL is not an attribute of a domain (zone). TTL is an attribute of each record in the zone. ISNIC only requires a minimum TTL on the nameserver records within the domain (NS resource records).
The value of the TTL field in the NS records affects the query-rate on the .IS nameservers, therefore there is a certain minimum enforced. Please note that this minimum TTL requirement only applies to the NS records.
It is possible to debate as to what precisely the minimum value should be, but experience in recent years suggests that these values should only be lowered from rather high defaults if some changes are planned. According to RFC1912:"Popular documentation like [RFC 1033] recommended a day for the minimum TTL, which is now considered too low except for zones with data that vary regularly. Once a DNS stabilizes, values on the order of 3 or more days are recommended. It is also recommended that you individually override the TTL on certain RRs which are often referenced and don't often change to have very large values (1-2 weeks). Good examples of this are the MX, A, and PTR records of your mail host(s), the NS records of your zone, and the A records of your nameservers."and according to RFC1030:"Most host information does not change much over long time periods. A good way to set up your TTLs would be to set them at a high value, and then lower the value if you know a change will be coming soon. You might set most TTLs to anywhere between a day (86400) and a week (604800). Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place, and then put it back up to its previous value."
A recent study on DNS performance concludes that"It is not a good idea to make the TTL values low on NS records, or for A records for name servers. Doing so would increase the load on the root and [g]TLD servers by about factor of five and significantly harm DNS scalability."from DNS Performance and the Effectiveness of Caching by Naeyeon Jung, Emil Sit, Hari Balakrishnana and Robert Morris ACM Transactions on Networking, Vol. 10, NO. 5 October 2002.
This applies to all TLD servers, both gTLD- and ccTLD-servers as well as to the root servers.
Also see news article ISNIC published on the matter.
The delegation requirements for .is domains were decided on by the .is community many years ago. One of the primary goals was that the .is domains would only be delegated to properly set up and properly managed nameservers. Statistically, the owners and operators of such nameservers have had no problem satisfying the PTR record requirement. This requirement makes various DNS abuses harder to achieve using .is domains (such as poisioned glue records, double-flux domains and others). This requirement originates from the same sentiments as a similar requirement on mailservers - which is now more-or-less universal as a method to reduce the risk of various kinds of misuse.
Of course there will be nameservers that are properly managed, but their operators decide not to correctly deploy PTR record sets. And there will be nameservers that are badly managed but with correct PTR records. However, the intent here is to increase the level of trust in the nameservers to which .is domains are delegated. Thus, the .is requirements apply to all and no provision is made for exceptions.
While RFC1912 "Common DNS Errors" is not a standards track document, ISNIC decided long ago to adopt many of it's recommendations as part of ISNIC's delegation requirements for .is domains.
From RFC1912 (Common DNS Errors):"Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME."
From RFC2181 (Clarifications to the DNS Specification)"10.2. PTR records Confusion about canonical names has lead to a belief that a PTR record should have exactly one RR in its RRSet. This is incorrect, the relevant section of RFC1034 (section 3.6.2) indicates that the value of a PTR record should be a canonical name. That is, it should not be an alias. There is no implication in that section that only one PTR record is permitted for a name. No such restriction should be inferred."
According to RFC5966:" ....any DNS server needing to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header. When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead."And in section 4 of RFC5966 states:" All general-purpose DNS implementations MUST support both UDP and TCP transport. o Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet."Accordingly, ISNIC requires nameservers hosting .is domains to support queries over TCP.
All .is domains are checked for compliance with the ISNIC technical requrements once a month. Those that fail this compliance test (which you can execute at Domains->Check Setup any time) are then tested weekly and their technical- and zone contacts informed via email about the nature of the problem. If the technical/zone contact fails to remedy the situation and the domain fails these tests for eight consecutive weeks, the domain is deactivated (removed from the .is zone, put on hold).
The domain now enters a 60 day grace-period where the domain remains registered but inactive. No further communications/warnings are issued by ISNIC during this period.
If, during the grace-period, the registrant arranges for the domain to become compliant again (by fixing the nameserver setup, redelegating to a compliant set of nameservers or by parking the domain) it is automatically reactivated.
After 60 days, the domain is automatically reactivated as a parked domain.
Closing or deleting a .is domain based on the domain's usage (e.g. the content of a website pointed to by the domain) would require a formal court order from an Icelandic court or a decision by the ISNIC board referring to article 9, chapter III of ISNIC registration rules.
ISNIC is not responsible for the registrant's usage of his/her domain, the contents of email sent from the domain's email addresses or the content of the domain's web pages. It is ISNIC's duty and prime function to maintain uninterrupted service to all .is-domains, at all times, anywhere in the world. Only Icelandic authorities, armed with a court order, can order ISNIC to delete or close down a particular .is domain.
Other than that, there are three reasons for closing and subsequently deleting a domain; non-payment of the domain's fees, wrong or incomplete registration or if the domain's technical setup is not according to ISNIC's requirements for extended periods.
When a contact object (registrant, admin, technical or billing contact) is registered with ISNIC an email is sent to the registered email address requesting that the contact (person or other) confirm their willingness to register, and the validity of the email address. This email contains an URL that must be followed to activate the NIC-handle.
Alternatively, the NIC-handle can be activated by setting a password. Visit here and type in your NIC-handle and then select the "Lost password" link.
The domain is transferred from one registrant to another via the ISNIC web interface. One of the domains contacts logs on using his/her NIC-handle and password, selects the domain to transfer, and selects "Registrant Transfer". The contact will be prompted for the NIC handle of the new registrant. The new registrant must have an active NIC handle. If he does not, he must first register as a user. The domains current registrant will then be asked to confirm the transfer request, and once that is received, the request is queued for processing. If the domains registrant does not have a valid email address, the domain's administrative contact will receive the email to confirm the request.
It is often simplest for the current administrative contact to change the admin-c to that of the new registrant (or his representative). The new admin contact can then effect the transfer and other changes that need to be made to the domain's registration when it is transferred from one registrant to another.
Please note that if the new registrant is a foreign party, special rules apply and manual confirmation may be required.
ISNIC does not operate a registry/registrar model. The registrants (or their representatives) interact directly with the .is registry. Each domain has up to four contacts with varying degree of control over the registration. (See Why are there multiple domain contacts? The registration management is transferred by changing some or all of these contacts.
If a registrant or contact supplies ISNIC with a national identification number ("kennitala") when registering a domain or a contact, ISNIC sets the name according to the national registry. If the contact selects to synchronize their address with the national registry as well, ISNIC will set the address in the WHOIS database to the offical address in the national registry. In this case the Registration Certificate published by ISNIC will contain the sentence "Registration verified by ISNIC" - Example.
The corresponding non-IDN domain is constructed from the IDN domain according to the following table:þ -> th á -> a í -> i æ -> ae é -> e ó -> o ö -> o ý -> y ð -> d ú -> u
ISNIC does not have any official registrars. The registrants have direct access to the .IS registry and deal directly with the registry. Anyone can host .IS domains as long as their nameservers meet ISNICs technical requirements, and the domains zone as set up on those nameservers meets ISNICs delegation requirements.
A company that agrees to host .IS domains for their customers, needs to register their nameservers with ISNIC, see "How do I register my nameservers with ISNIC?", and make sure they are willing to meet ISNICs delegation requirements.
A company can additionally apply for status as an official ISNIC service provider (ISP) for .is domains and/or status as an agent for registrants. ISP's have additional control and access.
An agent is a person or company that has applied for and been granted an agent status with ISNIC. Usually the agent simply manages the domain's registration with ISNIC on behalf of the registrant. Please see the application forms for the terms and conditions of agent registration.
A ISNIC service provider is a hosting provider that has registered with ISNIC as such and is willing and able to host .is domains according to ISNIC's technical delegation requirements. The ISP is listed with ISNIC, and has access to the ISP portal on the ISNIC web. Please see the application forms for the terms and conditions of such registration.
Domains can be parked, i.e. temporarily delegated to a special set of parking nameservers. A registrant may park a domain if e.g. the zone is not ready at the time of registration or the production nameservers have gone offline for a long period of time and the domain is in danger of being deleted. While a domain is parked it will not receive any email and no websites will be active. If you choose to park a domain you select the option "Parking" from the ISP's dropdown list. The registrant can park or unpark a domain at any time (via the ISNIC web -- see "How do I change my domains delegation records in the IS zone?" ). Domain parking is a free service.
Web Forwarding is a service provided by ISNIC to direct your domain to a IP address or a pre-defined web URL. If you choose to use an IP address, the webserver should be configured to display your website - you should contact your webserver administrator to make sure this is possible.
You can also enter a URL or a server name. Valid URL's are for example: http://www.isnic.is and http://www.isnic.is/faq.
Web Forwarding is a free service.
If you need email services for you domain, you must contact a service provider which can accept email for your domain. You need to establish such services before you can change the MX entries for your domain. If you do not have DNS services for your domain, you can add a single mail server name in ISNIC's "Web Forwarding".