ISNIC Registry: ISNIC

Jan 11, 2019 - Setting up a domain for Shopify

Setting up a domain for Shopify

your .is domain easily connects to Shopify via ISNIC's forwarding service. Notice that if the domain is hosted on other name servers then the following instructions do not apply.

Setting up the domain

First step is to set up the domain in Shopify, see Shopify's instructions. There under online store you can find domains and there is connect existing domain.

Connecting a domain to Shopify

In order for the .is domain to connect to your Shopify website the domain has to be configured on isnic.is.

Log in
Select the domain
Click Web forwarding

In the top text field where it says Complete URL or IP address you insert the IP number „23.227.38.32“ and then „shops.myshopify.com“ where it says CNAME record, according to Shopify's instructions. Then finish by clicking the submit button.

Run validation

The domain should be correctly set up now and you will only need to check if Shopify will confirm the afformentioned changes. Go to the verification page and run the test. Notice that you might need to wait until Shopify can see the updated domain information.

Mar 13, 2018 - G Suite and domain verification

G Suite and domain verification

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=wwifazIdB2QmF20KYwfPQfrD2RJkEiK9us5xobBk8i0

Put the entire text into the TXT record field on the web forwarding page. You can run Google's verification test now, but take note that it may take up to a day for Google to see the changes to the domain. After the domain has been verified you can remove the TXT record from the web forwarding page.

Mar 13, 2018 - Squarespace and 3rd party DNS hosting

Squarespace and 3rd party DNS hosting

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.

Nov 28, 2016 - DNS Moving to Cloudflare?

DNS Moving to Cloudflare?

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 ~~should~~ resulted 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.

Oct 3, 2016 - Gmail and missing messages from ISNIC

Gmail and missing messages from ISNIC

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!

Sep 6, 2016 - Google verification for .is domains

Google verification for .is domains

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.

Jan 8, 2016 - Bluehost January 2016 problems with ns2.bluehost.com

Bluehost January 2016 problems with ns2.bluehost.com

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.

Oct 1, 2015 - WIX DNS Services

WIX DNS Services

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).

Jun 5, 2012 - The IPv6 digital dilemma

The IPv6 digital dilemma

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)

The domain is available. Register domain

Blog