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 24 hours to remit the fee, after which the application expires and must be resubmitted if payment is made. Payment can be made online 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.
If you want to do this in a program use EPP check:domain or RDAP domain availability check. These lookups are rate-limited at 7200 queries per 30 min.
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.
A contact can also have a representative that manages the registration on their behalf.
Note that each contact can change their own registration information, but only the domain's registrant and administrative contact can change the domain's contacts.
- 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's NIC-handle?). 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 require registrant approval if the registrant is an active contact. 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 registrant 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 primary 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.
- Representative (U) for the registrant is a contact that manages the contact registration for the contact.
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:
Operations on domains
Registrant Administrative Contact Technical Contact Billing Contact Zone contact Representative Modify registrant info Yes Yes No No No Yes Registrant transfer Yes Yes (d) No (d) No (d) No Yes Substitute contacts Yes Yes No (a) No (b) No No Renew registration (BC is not DNSP) Yes Yes Yes Yes No No Renew registration (BC is DNSP) No No No Yes No (e) No Redelegate domain
- Modify DS recordsYes Yes Yes No No (c) No Delete domain Yes Yes (d) No (d) No (d) No No Autorenewal (on/off) (BC is not DNSP) Yes Yes No Yes No No Autorenewal (on/off) (BC is DNSP) No No No Yes No (e) No Resign as contact No Yes (b) Yes (a) Yes (b) No - a) AC and BC can withdraw their services (resign) R automatically substituted.
b) TC can withdraw their services (resign) AC automatically substituted.
c) ZC of domains hosted with a registered DNS hosting provider can redelegate and manage DS records.
d) TC and BC can request registrant transfers and deletions, R or TC must approve. AC can do registrant transfers and deletions if R is not an active contact.
e) All DNSP contacts can also renew the domain.
Operations on contacts
Representative Lookup info Yes Update info Yes Transfer to new representative No Delete contact No
The annual renewal fee is €31.90. The first year's fee (the registration fee) must be prepaid before registration can proceed. See the domain charges page.
ISNIC does not provide website nor email hosting service. DNS hosting is often provided by website and email hosting providers. All your services can be hosted at different providers.
ISNIC DNS Hosting is for those that only need basic DNS setup for their domain or need forwarding service.
Step 1
Login to your account.
Step 2
Go to My page and click on the shopping cart icon under the column Renew for the domain you want to pay for.
Step 3
Choose a billing method and click on Purchase. Enter your card information on the billing site and renew your domain.
The registrant, admin- and billing contacts can register domains for automatic payments on the subscriptions page.
When domains are registered for automatic renewal, card will be charged for the annual renewal fee 45 days prior to the expiry date.
Registering your domain to self renewal can be done at checkout, by selecting "Use payment card", "store card" and "Automatic renewal using the selected payment method", next click "Purchase".
Registering your domain to self renewal can also be done at "My page". There you can click on this button for the domain you want to register for self renewal.
It is important to keep information in WHOIS correct for domains which are automatically renewed. Contact e-mail addresses are particularly important to keep current as receipts for those domains are only sent in e-mail.
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). At 13:00 UTC the day after the expiration date, the domain is deactivated and removed from the ".is" zone.
The domain now enters a 30 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. If the domain fee has still not been paid after 30 days, the domain is deleted at 13:00 on the following day and made available for re-registration.
ISNIC can not provide definite 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) at 13:00 UTC the day after its expiration date.
A domain on hold is not available for registration. The registrant now has 30 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 30 days, making the domain available for registration immediately.
If the domain registration fee remains unpaid after 30 days, ISNIC deletes the domain at 13:00 UTC the following day, making it available for reregistration.
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.
Names of contact objects can not generally be changed. You must register a new contact using the new name, obtain a new NIC-handle and use that to do a "Registrant Transfer" (if the registrant has changed names) or "Change contacts" on the relevant domains (selected on "My page").
Contact names of objects registered using Icelandic National Identity Numbers ("Kennitala") are automatically updated if a change is made in the National Registry (both for individuals and for corporations).
Contacts (billing, tech and admin) can resign from their associated domain. When they resign tech will become admin and billing and admin vill become registrant.
You must begin by logging in to the ISNIC web using your NIC-handle and password and select "My page". Then select ("Resign as contact") from domain drop down list. Select domains that you want to resign from and click "Submit".
By default, most of the personal information on individuals (registrants and contacts) is withheld from publication. Note that the country is always published. You can decide to explicitly publish the rest of your information by going to "My settings" and toggle "Publish in WHOIS" to "Yes". Please remember that this only applies to individuals.
Note the circumstance's in Release of hidden Registration Data from ISNIC's Whois
Contacts are automatically removed if not used. But a contact can be removed if it is not used by a domain or a host. After the contact has been marked expired it will eventually be deleted. After a contact has been marked expired it will immediately be removed from ISNIC's public whois database. But if the contact logs in before it is deleted the contact will be reactivated. See the button Delete contact on "My Settings".
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.
A domain’s registrant, admin-, and technical contacts can point domains to a host by changing the domain’s nameservers.
Step 1
Login to the appropriate NIC-handle on isnic.is.
Step 2
Go to My page. Click on the icon under Control Panel and select Redelegate under Nameservers. You’ll see Parking, DNS and Nameservers, choose Nameservers.
Step 3
Type in the nameservers your hosting provider has set your domain up on, or choose the appropriate DNS hosting provider in the drop-down list of registered DNS hosting providers at ISNIC and click on Submit.
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 nameservers 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. Please do not contact ISNIC in these cases as we can not modify your domain's configuration with your DNS provider.
A competent DNS service provider will understand these basic requirements and will not have problems setting up your domains, or explaining to you how you can use their systems to host ".is" domains according to these requirements.
For every domain there are 3 contacts, a long with the registrant and zone contact: Administrative contact, Billing contact and Technical contact. Each contact has a different role and authority, as displayed here. The Registrant and the Administrative contact of a domain can change a domain’s contacts.
Step 1
Login to the registrant's or the admin contact's NIC-handle on isnic.is.
Step 2
Go to My page, click on Domain and select Change contacts from the drop-down list.
Step 3
Select the domain/s you want to change contacts for and type in the NIC-handle/s in appropriate columns, depending on which contacts you want to change. If the new contact does not have a valid NIC-handle at ISNIC, they must first register a contact and obtain a NIC-handle. Click on Submit to save your changes. The contacts will change immediately.
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 RFC4033 .
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 "Edit DS records", 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.
Note: The "24 hour" recommendation assumes common TTL (time-to-live) settings. If you have configured longer TTLs for your zone, you may need to wait longer.
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 an entire 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 [RFC1033 ] 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.
Note: As of november 2017 ISNIC does not require PTR records on nameservers.
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.
To delete (deregister) your ".is" domain, you begin by logging on to the ISNIC web using your NIC-handle on "My page" you click "Domain delete" under drop down list domain. Select the domain(s) you wish to delete and click Submit.
Please note that the domain's registrant (or administative contact) will receive e-mail from ISNIC asking them to confirm this action. If no confirmation is received within three days, the domain will remain registered.
If the domain's renewal fee is not received by ISNIC by the expiration date of the domain, the domain will be disabled, and deleted after a 30 day grace period.
Closing a ".is" domain based on domain's usage (e.g. content of a website pointed to by the domain, e-mail content sent to or from the domain and so on) can be requested by a formal court order from an icelandic court, or a request from relevant icelandic authorities. ISNIC can also decide to close a domain by referring to article 10, chapter 2 of the ISNIC registration rules.
ISNIC is not responsible for the registrant's usage of his/her domain. It is ISNIC's duty and prime function to maintain uninterrupted service to all ".is"-domains and be sure that the registration information of a domain is correct so that the current registrant for a domain can always be identified.
Other than that, there are three reasons for closing a domain:
- non-payment of the domain's fees,
- the domain's technical setup is not according to ISNIC's requirements for extended periods,
- if ISNIC considers the registration information wrong or incomplete.
Note that it is at ISNIC's sole discretion wether the information provided about the registrant is adequate or not. Once a domain has been closed (put on hold) due to incomplete registrant information, ISNIC reserves the right to ignore any further attempts by the registrant to correct the registration.
If the monthly test reveals that a domain does not comply with ISNIC's requirements, the following Misconfigured Domain Parking is initiated:
- Warning e-mails are sent weekly to the domain's contacts. First only the zone contact but eventually zone, tech and admin contacts and finally the registrant is added.
- If the problem persists for 8 consecutive weeks, the domain is suspended: it is marked inactive in the registry and its DNS records are removed from the ".is" zone file
- After the domain has been put on-hold it will be tested daily and activated if found to comply with the requirements.
- After another 30 days the domain is moved to the ISNIC parking servers (the DNS server settings for the domain are changed).
If the domain setup is brought into compliance (issues are resolved) before the domain is transferred to the ISNIC parking servers, the domain will be re-listed in the ".is" zone automatically and no further action need be taken.
If the domain setup is brought into compliance (issues are resolved) after the zone has been moved to ISNIC's parking servers, then one of the domain's contacts will need to use this website to redelegate the domain to the correct name servers.
You must begin by logging in to the ISNIC web using your NIC-handle and password. Next go to "My page", there select "Change contacts" under drop down list domain. Select domains that you want to change, enter contact NIC-handle to billing field and click "Submit" to submit changes.
When a contact object (registrant, admin, technical or billing contact) is registered with ISNIC an e-mail is sent to the registered e-mail address requesting that the contact (person or other) confirm their willingness to register, and the validity of the e-mail address. This e-mail 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.
Step 1
Login to your account at isnic.is.
Step 2
Go to My settings and select Notifications.
Step 3
Switch the toggle button on or off to enable or disable notifications.
A domain can be transferred from one registrant to another via the ISNIC web interface.
Step 1
Login to the current registrant’s NIC-handle on isnic.is.
Step 2
Go to My page, click on Domain and select Registrant Transfer from the drop-down list.
Step 3
Select the domain/s you want to transfer and type in the NIC-handle of the new registrant in the column below. The new registrant must have a valid NIC-handle. If they do not, they must register a contact and obtain a NIC-handle for the domain to be transferred to.
Step 4
The current registrant must confirm the change of registrants by following a link in an email sent to the registrant’s email address and clicking on Confirm to confirm the change of registrants. Note that you must be logged in as the current registrant when you follow the link, or login to the registrant's NIC-handle after following the link in the email, for the confirmation button to appear.
If the domain's current registrant does not have a confirmed e-mail address, the domain's administrative contact will receive the confirmation email to confirm the request.
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 contacts?) The registration management is transferred by changing some or all of these contacts. See also How do I change nameservers on a domain? (Point to another hosting provider).
If a registrant or contact supplies ISNIC with an Icelandic 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.
Account statements and invoices are accessible on My page, logged in as the domain's billing contact.
Step 1: Login
You can use Ice Key login (Íslykill) of a company. See instructions on how to login here.
Step 2: Account statement
Go to My page, click on Payments and choose Invoices from the drop-down list.
Choose the time period that you want to get invoices for and click on Submit or Submit sid. to receive the account statement for all NIC-handles registered on the kennitala, if they are more then one.
Step 3: Open invoices
Open the downloaded PDF file and click on the blue-colored SR-numbers in the account statement to open each invoice on PDF.
Lookup your domain on our main page to see the registered contacts. If you have lost your password you can :
- Use "lost password" to reset the password through e-mail.
- If the e-mail is unavailable, use "lost password" with the SMS option to reset the password via a registered mobile number.
- If the contact has a kennitala you can use island.is login.
- Otherwise you need to fill out a form.
For a contact with an icelandic kennitala it is easiest to use island.is login.
Otherwise fill out "Change contact authentication information" form and ISNIC has to verify the contact and for that service ISNIC charges a fee (see prices).
Note: for this to be possible at all, the contact's registration information must be as accurate as possible.
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 ISNIC's technical requirements, and the domains zone as set up on those nameservers meets ISNIC's delegation requirements.
A DNS hosting provider 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 ISNIC's delegation requirements.
A DNS hosting provider can additionally apply for status as a registered ISNIC DNS Service Provider (DNSP/ISP) for ".is" domains. DNSPs have additional control and access. Please see the application forms for the terms and conditions of such registration.
ISNIC offers EPP access to everybody that have shown competency against our development environment.
A registered DNS service provider (DNSP) is a 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 DNSP is listed with ISNIC, and has access to the DNSP portal on the ISNIC web.
Note: This status is not needed to register nameservers. See How do I register my nameservers with ISNIC?.
Note: ISNIC registered DNSPs used to be called ISPs. The name was changed to clarify what kind of hosting services they provide (DNS hosting, as opposed to web- or e-mail hosting).
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 e-mail and no websites will be active. If you choose to park a domain you select the option "Parking" from the DNSP's dropdown list. The registrant can park or unpark a domain at any time (via the ISNIC web -- see How do I change nameservers on a domain? (Point to another hosting provider)).
Domain parking is a free service.
If you need e-mail services for your domain, you must contact a service provider which can accept e-mail on your behalf. You need to establish such services before you can change the MX records for your domain.
If you do not have DNS services for your domain, you can configure DNS records for e-mail using ISNIC DNS Hosting. See How do I add DNS records?
Web Forwarding is when a visit to a domain is redirected towards a different URL.
To activate Web Forwarding, you delegate your domain to ISNIC DNS Hosting, (see How do I add DNS records?). On the domain's settings overview page you can find Web Forwarding and add a complete URL in the column Complete URL.
Adding a CNAME record for www is an option, but if not added, it will be added automatically for you, directing at @.
You can also enter a URL or a server name. Valid URL's are for example: https://www.isnic.is and https://www.isnic.is/en/faq.
Web Forwarding does not handle HTTPS and the ones that need HTTPS should contact their web hosting provider for forwarding service.
See also: How do I add DNS records?
The following instructions are made for those who want to use ISNIC’s DNS service to connect their domain to Microsoft 365. The instructions do not apply if a domain is setup on nameservers of a 3rd party DNS hosting provider.
Step 1: Set up Microsoft 365
In the Microsoft 365 setup page, Microsoft recommends using a TXT record to verify your domain. The TXT record usually looks something like this: MS=ms12345678 (the numbers are variable). Copy the record and go back to ISNIC’s page.
Step 2: Set your domain up on ISNIC’s nameservers
Login to isnic.is, go to My page and click on the icon under Control Panel in the domain table. In the Control panel you click on Redelegate under Nameservers. There you choose ISNIC DNS Hosting and click on Submit. Now your domain will be setup on ISNIC’s nameservers, it could take up to 10 minutes.
Step 3: Add DNS records
a. When the domain has been setup on ISNIC’s nameservers, you can add the DNS records from Microsoft to your domain. Go back to the Control Panel for your domain and click on Change under ISNIC DNS Hosting. On the DNS page, you choose Microsoft 365 from the drop-down list on the top of page and the DNS records from Microsoft will appear.
b. Paste your TXT Verification code in the required field and click on Submit.
Step 4: Verify Microsoft 365
Go back to your Microsoft 365 setup page and click on Verify. Your domain will now connect to your Microsoft 365 account.
The following instructions are made for those who want to use ISNIC DNS Hosting. The instructions do not apply if a domain is setup on nameservers of a 3rd party DNS hosting provider.
ISNIC provides DNS hosting for .is domains. To be able to add DNS records to the domain, it must first be setup on ISNIC’s nameservers.
Step 1: Set domain up on ISNIC's nameservers
Login to isnic.is, go to My page and click on the icon under Control Panel in the domain table. In the Control Panel you click on Redelegate under Nameservers. There you choose ISNIC DNS Hosting and click on Submit. Now your domain will be setup on ISNIC’s nameservers, it could take up to 10 minutes.
Step 2: Add DNS records
When your domain has been setup on ISNIC’s nameservers, you can add DNS records. Go back to the Control Panel for your domain and click on Edit under ISNIC DNS Hosting. From there you can add new DNS records and edit existing records.
a) Add single DNS records
In the drop-down list on top you can choose Single DNS record. Choose the Type of DNS record you want to add and insert appropriate Name (Host) and Value (Data, Content) and click on Submit.
- If a DNS record’s Name is left empty it will automatically be set as @ which will work as the domain’s root.
- When adding a DNS record for www.yourdomain.is you only type “www” as the Name (host), not “www.yourdomain.is”.
b) Ready-made templates for common services
You can choose ready-made templates to add DNS records from popular mail services, website builders and hosting providers. Choose your service provider in the drop-down list and you’ll see the DNS records that will be added as well as those that will be removed, if any. Click on Submit to add the DNS records.
If your domain is hosted by a 3rd party DNS hosting provider and setup on their nameservers, you can add DNS records on their end but no changes are made through ISNIC.
It depends on the hosting provider how these changes are made, but the most common way is to login to the hosting provider’s website and add the DNS records through their interface. Contact your hosting provider if you have trouble adding the records to your domain.
If you’re not sure who your hosting provider is, you can see which nameservers your domain is setup on by typing the domain name in ISNIC's WHOIS Database
The following instructions are made for those who want to use ISNIC’s DNS service to connect their domain to Squarespace. The instructions do not apply if a domain is setup on nameservers of a 3rd party DNS hosting provider.
Step 1: Squarespace setup
The first step is to follow Squarespace's instructionsto connect a domain. When you see a picture of your DNS records from Squarspace, go to isnic.is.
Step 2: Set your domain up on ISNIC's nameservers
Login to isnic.is, go to My page and click on the icon under Control Panel in the domain table. In the Control Panel you click on Redelegate under Nameservers. There you choose ISNIC DNS Hosting and click on Submit. Now your domain will be setup on ISNIC’s nameservers, it could take up to 10 minutes.
Step 3: Add DNS records
a. When the domain has been setup on ISNIC’s nameservers, you can add the DNS records from Squarespace to your domain. Go back to the Control panel for your domain and click on Change under ISNIC DNS Hosting. On the DNS page, you choose Squarespace from the drop-down list on the top of the page and the DNS records from Squarespace will appear.
b. Squarespace provides you with a Name (host) for a CNAME record with the Value (data) verify.squarespace.com. Copy the Name and paste it in the required field and click on Submit.
Step 4: Confirm
When all the DNS records from Squarespace have been added, you can click on the Refresh button on your Squarespace site, where your DNS records are shown. Your domain will now connect to Squarespace.
The following instructions are made for those who want to use ISNIC DNS Hosting to connect their domain to Google Workspace. The instructions do not apply if a domain is setup on nameservers of a 3rd party DNS hosting provider.
Step 1: Set up your Google Workspace account
First you sign up for Google Worspace and go through the first steps in their setup process. When you see a MX Verification code, copy the code and go to ISNIC’s page.
Step 2: Set domain up on ISNIC's nameservers
Login to isnic.is, go to My page and click on the icon under Control Panel in the domain table. In the Control panel you click on Redelegate under Nameservers. There you choose ISNIC DNS Hosting and click on Submit. Now your domain will be setup on ISNIC’s nameservers, it could take up to 10 minutes.
Step 3: Add DNS records
a. When the domain has been setup on ISNIC’s nameservers, you can add the DNS records from Google to your domain. Go back to the Control Panel for your domain and click on Change under ISNIC DNS Hosting. On the DNS page, you choose Google Workspace from the drop-down list on the top of page and the DNS records from Google will appear.
b. Paste your MX Verification code in the required field and click on Submit.
Step 4: Activate Gmail
Go back to your Google Workspace setup page and click on Activate Gmail. Your domain will now connect to your Google Workspace account.
The following instructions are made for those who want to use ISNIC’s DNS service to connect their domain to Google Workspace. The instructions do not apply if a domain is setup on nameservers of a 3rd party DNS hosting provider.
Step 1: Setting up Google Sites
First you need to create Google Sites page and access it's settings . There you choose Custom domains, click Start setup, and enter www and your domain (e.g. www.yourdomain.is ).
Step 2: Validate your domain: get the code
A link asking you to "verify your ownership" appears if your domain hasn't been validated. Click it. There you must choose Domain name provider : other and copy the code displayed on their page and looks similar to:
google-site-verification=gwF5euksRmSXEwRdq7A04kuFFkZbVJweB6j0nE6iJQl
Step 3: Delegate your domain to ISNIC's nameservers
Login to isnic.is, go to My page and click on the icon under Control Panel in the domain table. In the Control panel you click on Redelegate under Nameservers. There you choose ISNIC DNS Hosting and click on Submit. Now your domain will be setup on ISNIC’s nameservers, it could take up to 10 minutes.
Step 4: Validate the domain
a) Insert the code into ISNIC's interface
When the domain has been setup on ISNIC’s nameservers, you can add the DNS records from Google to your domain. Go back to the Control Panel for your domain and click on Change under ISNIC DNS Hosting. On the ISNIC DNS Hosting page, you insert a single DNS record with type: TXT, host: www and copy and paste the code from step 2 in the large text field. Click the "add" button.
b) Run validation at Google
Now go to the Google page and click the Verify button. By doing that Google checks if it finds the TXT record with the correct code and host.
Step 5: Add the domain at Google
Go back to the Google page's settings , choose Custom domains and Start setup. Enter the domain and click next.
Step 6: Connecting the domain to the website
a) Remove the validation code
In DNS settings of the domain at isnic.is you will need to remove the validation code. Click the button next to the validation code which you entered before. Then click the button.
b) Connect the site to www
On the ISNIC DNS Hosting page, you insert a single DNS record with type: CNAME, host: www and put
ghs.googlehosted.com.
into the big text field. Click the "add" button.c) Forward the domain to www
Now typing the domain prefixed with www into browser works, but not if www is missing. In order to fix that you can use our Forwarding service. Copy the URL that works. On the ISNIC DNS Hosting page you can select DNS templates: Forwarding, URL redirecting, and enter the URL that works (e.g. https://www.yourdomain.is/) and click "Submit".
The domain is now connected to your Google Sites via www, and anyone that enters your domain without www in the browser will be forwarded to the domain prefixed with www.
The following instructions are made for those who want to use ISNIC DNS Hosting to connect their domain to Google Workspace. The instructions do not apply if a domain is setup on nameservers of a 3rd party DNS hosting provider.
Step 1: Set domain up on ISNIC's nameservers
Login to isnic.is, go to My page and click on the icon under Control Panel in the domain table. In the Control Panel you click on Redelegate under Nameservers. There you choose ISNIC DNS Hosting and click on Submit. Now your domain will be setup on ISNIC’s nameservers, it could take up to 10 minutes.
Step 2: Add DNS records
a. When the domain has been setup on ISNIC’s nameservers, you can add the DNS records from Shopify to your domain. Go back to the Control Panel for your domain and click on Change under ISNIC DNS Hosting. On the DNS page, you choose Shopify from the drop-down list on the top of the page and the DNS records from Shopify will appear.
Step 3: Change Shopify settings
According to Shopify's instructions, you go to Domains under Settings and click on Connect existing domain. There you type in your domain name and click on Verify connection. Now your domain will connect to Shopify.
The following instructions are made for those who want to use Wix's nameservers. Note that if your domain is already setup on different nameservers, that connection will be lost when you make the change.
Step 1: Set domain up at Wix
Login to your Wix account and follow Wix's instructions. Under Domains you'll find Add An Existing Domain and click on Connect a domain you already own. Follow Wix's instructions on to step 2.
Step 2: Find Wix's nameservers
Step 2 in Wix´s instructions is logging in to your domain host provider, which is ISNIC in this case. Click on I logged in, then click on I found my domain settings and I found the nameservers. Copy the nameservers provided by Wix and Log in to your account at isnic.is.
Step 3: Connect the domain to Wix
Go to My page, click on the wrench icon under Control panel for your domain in the domain table. Click on Redelegate next to Nameservers Under Nameservers you'll enter the first nameserver into Primary nameserver and the second Wix nameserver into the second text input and click on Submit.
On Wix's page you can click on I’ve replaced my nameservers and your domain should connect to your Wix site.
Transactions for payment cards, put into storage with ISNIC before law about payment service, nr. 114/2021 (the PSD2 directive from the European Union) was put into effect, can be denied. The solution is to delete the card from the ISNIC storage and put it back again.
Late December 2015, issues with ns2.bluehost.com triggered automatic notice to .is Registrants. The nameserver doesn’t respond to DNS queries.
Bluehost says this is part of a DDoS protection, and that it’s being repaired, and that there is no known ETA of a fix, and that customers should use 3rd party DNS servers and point to their Bluehost IP Address (in the interim or instead).
ISNIC deactivates domains which have a broken DNS configuration after 8 weeks.
After a recent problem with Dyn.com (search news stories for “DDoS against Dyn DNS”), several big DNS providers took additional precautions with one or more of their primary DNS servers. This includes moving them so that they are not hosted by *one* provider. This is generally a good thing and ISNIC has promoted operating your DNS servers on separate IP Networks, and separate AS numbers for resilient operations.
Some providers have moved their services to Cloudflare – which should be fine – however, some of them haven’t yet gotten their PTR RRs (Resource Records), also known as Reverse DNS, into the appropriate in-addr.arpa zone.
Cloudflare does know how to operate DNS services, and they do know how to add PTR RRs. As to why they’ve not applied them to these services are reasons unbeknownst to ISNIC. You must contact your DNS provider and ask them!
If they say all is well, use the ISNIC Zone Check – and forward the results to your provider. If they still continue to claim all is well, ask for better support – and someone who knows what “in-addr.arpa” means (and don’t think it’s an URL…)
If your DNS provider is Bluehost, ask them what this means:
dig -x 162.159.24.80 +trace # results in a loop, which ends in:
24.159.162.in-addr.arpa. 86400 IN NS ns2.cloudflare.com.
24.159.162.in-addr.arpa. 86400 IN NS ns3.cloudflare.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 209 bytes from 162.159.0.33#53(ns3.cloudflare.com) in 41 ms(162.159.24.80 is the IP Address of ns1.bluehost.com, which is now hosted by Cloudflare)
If you continue to receive notices or information from Bluehost that your domain isn’t OK, move your DNS services away from Bluehost, since they no longer support .is domains for a period of more than 6 weeks (the counter in the e-mail from ISNIC should not exceed 8!) then you must take action.ISNIC has been in contact with DNS specialists from Bluehost and Cloudflare – which
shouldresulted in appropriate repairs (29th Nov). However, from 27th January we’ve received information that this has happened again. And PTR errors were resolved by Bluehost on 14th march 2017.
Bluehost has also recommend the A RECORD solution – since they will not support .is domains in their DNS solution.If you have issues, and Bluehost suggest A RECORDs, then you can go to www.isnic.is and in “Web Forwarding” enter the IP Address provided from Bluehost for your server (ping your domain may reveal this) – this will make ISNIC’s Web Forwarding service act as DNS Provider for your domain. If you also have e-mail active for your domain make sure to enter the correct mail server name! If Bluehost is also your mail server host, then you just type in your domain name in the mail server field.
The following instructions are made for those who do not have DNS hosting for their domain and want to use ISNIC’s forwarding service to connect to G Suite in accordance to Google’s help page.
G SUITE
Log in on isnic.is, select your domain and click web forwarding. Under advanced settings you will find Mail Server (MX). According to Google’s help page the value you write in the mail server field is ASPMX.L.GOOGLE.COM. You will need to enter any valid URL or IP address in the top field, that could be another domain you already own.
DOMAIN VERIFICATION
You can use the TXT method through ISNIC’s forwarding service to accomplish this. We assume you are still on the web forarding page from the instructions above, with advanced settings opened. Go to Google’s help page (Add a TXT verification record (any domain host)) about domain verification and find your unique TXT record. Note that the code includes “google-site-verification=” and then is followed by 43 random characters, see an example:
google-site-verification=wwifazIdB2QmF20KYwfPQfrD2RJkEiK9us5xobBk8i0Put the entire text into the TXT record field on the web forwarding page. After the domain has been verified you can remove the TXT record from the web forwarding page.
If you do not see our messages, like password reset, and you use Gmail – check your archive folder or your “other” Gmail reader!
Gmail may be archiving the messages, please read this document regarding Gmail and archiving options – one of which will most likely be the reason for this behavior.
The direct URL to your archive folder is here.
You can mark or flag hostmaster@isnic.is as Very Important or assign it to the special folders in Gmail and indicate where this e-mail should go! Remember this applies to any and all messages which Gmail is sorting in this manner and is most definitely not only relevant to ISNIC!
Google Apps work very well with .is domains. However, you must go through some steps, with Google, to verify that you manage your domain.
ISNIC gets requests about this – and they are actually intended for your DNS operator. Although ISNIC offers “Web Forwarding” as a quick method of getting your domain up and running, we’re not your Registrar, we are the .is Registry!
To follow Google’s instructions, available here – you can follow the HTML advice if you’re already running a website – but the TXT or CNAME instructions must be done with a DNS hoster.
See a list of DNS hosters/providers on the ISNIC website and note that you may find FreeDNS services from some of them (like x.is and 1984.is).
These information are informational only, and not meant as a suggestion or endorsement of any company mentioned here.
Your .is domain can easily connect to most website hosting providers by our simple web forwarding or using their name servers, but some providers such as Squarespace require more. This guide will use Squarespace as an example of how to use 3rd party DNS hosting.
SET UP YOUR DOMAIN
First step is always to set up the domain on the webhost’s site. Look at Squarespace’s help page, starting from step 1.
DNS HOSTING
After setting up the domain we need to find a DNS provider; here is a list of popular providers. You can find number of free DNS with any search engine. Note that your provider does not need to be an official provider on ISNIC’s website.
Setting up the domain on the DNS provider’s website varies greatly. Normally you will have to create an account and set up a new domain, they may want to sell you a domain, but just select to set up a domain.Start by removing any A records if there are any, then add a new DNS record with the following setup.
Type: A
Host: @
TTL: use default value (common values are 3600 and 86400)
Points to: (copy IP to here)Do this for each A record your website provider requires. Use Squarespace’s help page to see all 4 A records they require and get the IP addresses.
When all A records have been set up in accordance to your webhost’s requirements you will do the same as above but with CNAME records, making sure the fields are correctly filled out in accordance to your webhost’s instructions.REDELEGATE YOUR DOMAIN TO THE DNS HOST
Log into your relevant isnic.is account, select your domain, click redelegate, and either pick the service provider from the list of providers or enter the name servers manually.
FINISH
You may need to wait some time, but Squarespace provides you with a tool (described in step 8 of their help page) to see if they have received updated information about the domain. After putting the domain on queue for redelegation you may want to hit that refresh button every half an hour.
We are now entering the time of permanent IPv6 presence. 6th june is ‘IPv6 Launch Day‘ and following this, we’ll expect quite a large number of companies enabling IPv6 on their services, lots of ISP’s will make IPv6 available to their customers and you need to ask now, are you ready to accept the new and improved, the unknown and available, secure and open network standard now, later or never?My first impression of IPv6 after reading some material was, ‘yes and no’, and it still is. I’ve made steps to improving my setup, I’ve tested and tested and still remain hesitant because I cannot suggest to anyone, neither home users or companies that they implement IPv6 now… But if your decision is to try and test, I can make some suggestions…Whatever they say about stuff included with IPv6, IPsec, protocol differences etc., remember it’s only as secure as your least secure item on the network – so find your lowest common denominator and figure out how you’ll apply security and some will find easy ways of doing monitoring and auditing, while others will quickly notice that they’ve got none at all.Lots of users will have hands on experience with their loggers, Event Viewer, syslog, console log etc. But there will be new issues with IPv6. My immediate realization and my experience:
- Mostly not reading the log *all the time* and missing most stuff… for my parts, it’s ok since it’s mostly firewalled and ACL’s in the appropriate location
- Firewalls and AntiVirus apps, not knowing anything about IPv6
- IPv6 traffic which *I* don’t know anything about, like toredo tunnels and others (HE.NET, Freenet…)
- Services defaulting to IPv6 servers with variable reliability and added delays, DNS issues with PTR records, hosts.allow messed up, all accurate responses to unexpected queries and traffic
Several accidental issues popped up after IPv6 enabled services where introduced, i.e. the service is implemented and tested and the AAAA record is added to the DNS and the service starts to popup *and failing*, why?
- Routing and response issues, local firewall not accepting the new traffic. The new traffic isn’t as easy as “tcp port X is opened, and we respond”, oh no, we’ve got to worry about advertisments and neighbour discovery and this will be your issue if you’ve got rogues on your network because you’ll have to trust your neighbours or use software and correct configuration to ensure your traffic is secure. After configuring neighbour discovery and accepting the correct packages from the router, traffic starts to flow and ACL’s drop traffic again.
- IPv6 addresses in ACL’s are commonly wrapped with []’s and the subnet mask *following*, i.e. [2001:470::]/32 (Hurricane Electric).
- IPv6 isn’t correctly supported on all operating systems. Our users had MacOSX Leopard, which had problems with manual configuration and Snow Leopard which doesn’t correctly allow neighbour advertisments with ip6fw unless you strip PowerPC code from the binary…
- On any network with a router advertisment daemon, any linux, MacOSX and many Windows Vista and all Windows 7 machines will popup with and IPv6 address. Windows XP machines shouldn’t do it unless specifically enabled.
- Operating Systems *don’t* block IPv6 traffic by default. Your firewall may be *oblivious* to IPv6 traffic. You may have services which are enabled, fully protected on IPv4 – but they’ll be visible on IPv6 and may be hacked, even if they *are* the secure services. Do you watch your laptop or work machine for attempts to authorize users, the SSH daemon or SMB/CIFS services? Usually we just *block* access to authentication services but there are always servers which will allow this and if you don’t start dropping connections, you may be opening up a system for infinite hack attempts on generally secured services.
If you think you’re part of a network which is *too large to scan* – because your smallest network is 64 bits large, and your machine or server is hidden somewhere – remember many devices are servers, and will present AAAA records and PTR records may give away some information. A local machine will be able to discover the neighbours, so your immediate danger of ‘scanning’ is already a part of your neighbourhood. Also, this is all about discovery and when you start accessing services, you’ll start to leave your footprints and your digital fingerprint will be all over the internet and a port scanning device, sniffer or data mining tools will start collecting IPv6 addresses and information. Remember that the default setup for router advertisments will use your network cards MAC address (ethernet address) and when you move to a new network, you’ll already carry a identifier which can be datamined. IPv6 does have some methods of randomizing your IPv6 address for security. This will of course make it more difficult to maintain AAAA and PTR records and some services will refuse connection from addresses missing the PTR records or have a mismatch between AAAA and PTR (RFC931).One contingency plan was to make the address space enourmously large, but it will be filled. Several vendors, users and companies will simply make lots and lots of networks, spend their CPU cycles in routing and ACL’s for a simpler setup, but it’s not a good solution. It’s an situation where a secure webserver may be hosted in a dedicated /64 network because we can’t as yet break it down to /120 and then manage that by ACL on the routing level BUT we can do it on a local level – if you implement strict policies, know your devices and have trustworthy management and auditing, but it’s a management nightmare which needs solutions. There will be many views on how to implement security and they are all important because security will be required.
My suggestions?
- If you have a System Administrator, make sure he’s up to date, and that he’s met IPv6 people and knows what’s what.
- If you don’t have a System Administrator, get advice – should you do it and how.
- Get into the habit of audit and monitoring, free tools include ntop and cacti
- Realize that there are holes which you cannot cover, since they may be your published application
- Backup, backup and backup
- Your system may be viable for separating services and users, this will make ACL’s and firewalls manageable… sort of
- Remember your digital footprint. You may want to reduce it and if so, use the privacy extensions but it’s an addon to security, it’s not “the security”
- Because native IPv6 will create a direct connection between nodes, each node should include security of some sort. Although you can implement a firewall on your routers, it’s not a solutions but an interim fix while you apply your internal IPv6 deployment and solve your internal issues.
Björn R. (My opinions are my own)
If you are moving your web or DNS to WIX, but it fails through the ISNIC web – it’s possible the WIX nameservers haven’t been registered with ISNIC.
It’s ideal if WIX registers their nameservers with ISNIC, but the Zone Contact for WIX is EP29-IS (ISNIC NIC handle).