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.

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. After the domain has been verified you can remove the TXT record from the web forwarding page.

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.

 

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!

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.

Bluehost – Janúar 2016 – ns2.bluehost.com

Seint í desember 2015 kom upp vandamál tengt ns2.bluehost.com og fengu rétthafar .is léna fljótlega eftir það tölvupóst vegna þess frá ISNIC.

Bluehost segir að ns2.bluehost.com sé undir DDoS vernd, og unnið sé að viðgerð, þótt ekki sé hægt að fá áætlaðan tíma frá þeim. Á meðan, er hægt að færa lén til þriðja aðila, en passa að setja inn réttar upplýsingar í nafnaþjónustu þar.

ISNIC óvirkjar lén sem eru á biluðum nafnaþjón í meira en 8 vikur.

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.

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

WIX DNS Þjónusta

Ef þú getur ekki flutt .is lénið þitt til WIX, en ert búin að setja það upp þá gæti þurft að skrá þá nafnaþjóna WIX hjá ISNIC.

Best er að láta WIX skrá nafnaþjónana sína en NIC Auðkenni tengiliðs WIX er EP29-IS.

IPv6 kvöl eða hvati

 Við erum að nálgast þann tíma sem IPv6 verður varanlegur hluti af netinu. 6 júni er ‘IPv6 Launch Day‘ og eftir hann má búast við að fjöldi fyrirtækja muni virkja IPv6 þjónustur hjá sér, þjónustuaðiliar munu veita viðskiptavinum sínum aðgang að IPv6 umferð og þú þarft að spyrja þig hvort þú sért tilbúinn að taka á móti hinu nýja, óreynda, örugga opna neti, hvort sem það er núna, seinna eða aldrei.
Fyrstu kynni mín af IPv6 fengu mig til að hugsa bæði já og nei, og ennþá er ég með efasemdir. Ég hef bætt uppsetninguna hjá mér, ég hef prófað og prófa og sumt hefur gengið vel, annað þurft meiri aðlögunartíma. Ennþá get ég ekki af heilum hug sagt neinum að innleiða IPv6 strax… En ef þú ætlar þér að kanna þetta og prófa, þá fylgja hér nokkur ráð…
Mundu að netið þitt er eingöngu jafn öruggt og það sem er minnst öruggt á netinu hjá þér. Finndu þennan punkt og upp frá honum, hvernig öryggi þarf að vera til staðar og hvernig þú munt fylgjast með og hafa eftirlit með netinu þínu. Margir komast að því núna að eftirlit þeirra er lítið eða ekkert og verkfærin ekki til staðar.
Margir notendur kannast við eftirlitskerfin hjá sér og Event Viewer, syslog, console log, e-ð sem kíkt er reglulega í. En það koma upp ný mál með IPv6 og fyrstu kynni mín sýndu mér:
  • Log skrár ekki lesnar stöðugt og fullt af tilkynningum fara fram hjá manni… fyrir mig var þetta ekki hættulegt þar sem mest allt hefur viðeigandi eldveggi, aðgangslista og eru traustar þjónustur.
  • Margir eldveggir og vírusvarnir hafa ekki hugmynd um IPv6
  • Falin umferð, t.d. teredo göng, freenet o.fl. Þá mynda sumar Windows vélar svona göng án þess að notandi hafi hugmynd, jafnvel þótt lítil eða engin umferð verði til.
  • Þjónustur sem verða sjálfkrafa IPv6 og allskonar hlutir verða hægvirkir, t.d. útaf DNS uppflettingum, allskonar vesen þar sem stuðningsþjónustur eru ekki réttar og vissar stillingar semð IPv4 rúllar í gegnum hætta að virka.
Nokkur dæmi um þjónustur sem urðu fyrir vandræðum eftir að vélar fengu AAAA nafnið lýstu sér í hægagangi og töfum. Stundum vantaði bara skilgreiningu í eldvegg, stundum vantaði DNS færslur og í einstaka tilfellum var þjónustan ekki að hlusta á IPv6.
  • Beinar voru stundum til vandræða, stundum eldveggir eða aðgangslistar. Nýja umferðin er nefnilega ekki eins og í IPv4, “opnum tcp port X, og fáum svar”. Nei, einnig þarf að tala Neighbour discovery/solicitation, router advertisments o.fl. sem tala á handahófskenndum IPv6 tölum (við fyrstu sýn) og ef eldveggurinn svarar ekki rétt þá virkar ekkert rétt! Hér var tcpdump/wireshark málið.
  • Aðgangslistar voru oft vitlausir og hjálpaði að skilja að IPv6 tölur eru ekki skrifaðar á sama máta og IPv4, oft eru tölurnar á þennan máta: [2001:470:;]/32
  • Stýrikerfi hafa misgóðan stuðning við IPv6. Notendur höfðu upphaflega MacOSX Leopard, sem erfitt var að stilla í gegnum “Network” hlutann, en hægt að setja IPv6 tölur í gegnum Terminal hlutann (handvirkt), síðan Snow Leopard sem leyfði ekki neighbour advertisments í gegnum ip6fw eldvegginn nema eftir að búið var að strippa út PowerPC hluta forritsins (of gamall TCP stakkur).
  • Ef þú kveikir á Router Advertisment daemon, munu Linux, MacOSX vélar og margar Windows Vista og allar Windows 7 vélar byrjar að tala IPv6. Windows XP vélar gera þetta ekki án sértækra stillinga. Ath. að gera ráð fyrir að almennar vélar hafa engar IPv6 aðgangsstýringar og líklegar að allt sé opið. Þótt sumar þjónustur séu ekki að útvarpa, þá fjölgar þeim sem gera það end SMB/CIFS tilkynna sig, Bonjour talar mikið… Þessar þjónustur er hægt að tala við og reyna að innskrá sig, án þess að notendur verði varir við það og má búast við innskráningartilraunum út í hið óendanlega…
Ef þú telur að IPv6 netið þitt sé einfaldlega of stórt til að skima eftir vélum, þar sem minnsta netið er 64 bitar að stærð og vélarnar eru “faldar” inn á milli, þá eru samt þjónar og þjónustur sem þú ert að kynna með AAAA færslum og PTR færslur geta gefið upplýsingar um netið. Staðbundnar vélar geta skimað eftir nágrönnum (neighbour discovery og solicitation), og mesta hættun eru því þær vélar sem þegar geta tengst við netið þitt. Einnig munt þú skilja eftir stafrænt fótspor út um allt á netinu þegar þú byrjar að tengjast við þjónustur á IPv6 netkerfum og gera má ráð fyrir að upplýsingar um notendur safnist upp á endanum hjá mis-óprúttnum aðilum sem gætu hagnast á að deila upplýsingum um notendur… Hefðbundin uppsetning virkar þannig að IPv6 talan þín inniheldur MAC vistfangið á tölvunni þinni (einkvæmt númer á hverju einasta netkorti í heiminum…) og með því að hamstra upplýsingum um IPv6 notendur er jafnvel hægt að fylgjast með þér flakka á milli IPv6 net og netkerfa þar sem síðasti hlutinn í IPv6 tölunni er einkvæmt fingrafar tölvunnar þinnar! Hægt er að nota viðbætur við IPv6 sem gera þessa tölu handahófskennda, en bætir ekki upp fyrir öryggisholur eða rekjanleika nema að litlu leyti. Með þeim vibótum er einnig erfiðara að koma við AAAA og PTR færslum á netinu á áreiðanlegan og traustvekjandi máta. Mörg netkerfi munu hafna tengingum frá vélum sem ekki hafa samsvarandi A/AAAA og PTR færslur (sjá RFC931).
Ein leið sem IPv6 nýtir sér er að búa til óheyrilega stórt net – sem á endanum verður samt fyllt (ekki endilega vel nýtt, en klárast). Margir framleiðendur, notendur og fyrirtæki munu einfaldlega búa til fleiri og fleiri net, eyða tíma og orku í beinum og aðgangslistum til að “tryggja” sitt kerfi, en það er ekki góð lausn. Það mun leiða af sér uppsetningu þar sem vefþjónninn þinn situr einn í /64 neti því við getum ekki með góðu móti tryggt aðgang með /120 bita stýringum í beinum eða á staðarneti nema með tiltölulega flóknum reglum og uppsetningum þar sem þú eða kerfisstjórinn þurfið að hafa gott eftirlit með tækjum og umferð. Það eru margar lausnir til og það er mikilvægt að hafa öryggi að leiðarljósi í þeim – ef þú finnur einfaldar leiðir þá deilir þú þeim.

 

Mínar uppástungur?
  • Ef þú ert með kerfisstjóra, sjáðu til þess að hann viti hvað hann er að gera og hafi aðgang/hitt fólk sem þekkir IPv6 og veit hvað skal gera.
  • Án kerfisstjóra, þá þarft þú að fá ráðgjafa og þjónustu – sem þú þarft að velja eða hafna og skipuleggja
  • Lærðu að fylgjast með kerfinu, notaðu verkfæri sem auðvelda það, frí verkfæri eru t.d. ntop og cacti
  • Sættu þig við að sumar þjónustur eru illviðráðanlegar, t.d. hugbúnaður sem er aðgengilegur (t.d. vefsvæði)
  • Afrit, afrit og meira afrit
  • Mögulega er kerfið þitt aðgreinanlegt í netþjóna og notendur, þar með verður aðgangslistinn viðráðanlegri…
  • Þekktu hugtakið fingrafar og fótspor þegar kemur að netinu. “Privacy Extensions” geta hjálpað til að að minka fótspor þitt á netinu, en það er viðbót við aðrar öryggisvarnir en ekki “öryggið”.
  • Þar sem IPv6 myndar samband á milli tveggja staða, þarf öryggi að vera til staðar. Þótt þú getir sett upp eldvegg á beinum, þá er það tímabundin lausn á meðan þú útfærir uppsetningu innandyra hjá þér.
Björn R.