Previously on the CogitActive Saga:
I decided to keep my domain name and my web hosting separate.
Registering a domain name with a registrar separate from the hosting provider is the recommended way to go as it is more secure and gives you greater flexibility (see Self-hosting: a hard egg to crack). However, in contrast to the convenience of having both services together, this approach requires some extra configurations in order to make your website available via your domain name. You have to point your domain name to your web hosting by editing your Domain Name System (DNS) records. While it may sounds intimidating, I was reassured that it’s not that difficult, anyone can do it
. Really?
Understanding DNS
As stated above, directing your domain name to your website requires manipulating your DNS. Before doing so, however, it is important to be acquainted with the terminology. Without going into detail on how DNS works1, let me cover some basics, and more importantly, which DNS records you need to worry about.
How DNS works
Every device attached to the Internet has a unique Internet Protocol (IP) address. Indeed, the server – on which your website is – has an IP address. Greatly simplified, domain names are associated with these IP addresses and thus point to a unique location on the web. This is made possible through DNS, which translates human-readable domain names into computer-usable IP addresses. Actually, there exist computers designated to translate domain names into IP addresses, namely Name Servers. Given the amount of information to deal with, that information is distributed, in a hierarchical fashion
2.
Hence, DNS, at its core, is a distributed and hierarchical system. At the top, there are Root Name Servers, which handle requests for information about top-level domain (TLD). They don’t have the information about the domain name. Instead, they are able to direct the requester to the TLD Name Server that handles the specifically requested TLD (e.g. .com or .org). The TLD servers don’t have the information about the domain name either. However, they have the IP address of the Domain Name Server responsible for each secondary domain within that TLD. Only this last server has the information about the domain name, i.e. the mapping between the domain name and IP addresses.
This is how DNS works: from least to most specific. This is also why, when you type a web address (i.e. URL as in Uniform Resource Locator) into your browser, your computer actually reads the address from right to left
3.
DNS records
What matters, here, is that the Authoritative Domain Name Server holds what is called a Zone File, which defines the resources available under a specific domain. Within the zone file, there are a series of records, called Resource Records (RRs). They provide information about where to find the various services and parts of your website. The Zone file is quite extensive – each service has its own type of record – but only a few of these DNS records are of importance for the topic at hand.
A Records: These records – A standing for Address – allow to map a domain name to its corresponding IP address and therefore to direct visitors to the right place.
CNAME Records: These records – CNAME standing for Canonical NAME – map an alias onto a canonical name for your server, that is one defined by an A Record.
NS Records: These records – NS standing for Name Server – indicate which servers are responsible for the zone file4.
MX Records: These records – MX standing for Mail Exchange – point to the mail servers where the e-mails for the domain name should be delivered.
TXT Records: These records – TXT standing for Text – are used to store text-based information related to your domain.
Take-home message
Now that you are familiar with some of the terminology involved with DNS, let me get to the point. As I said, all the DNS records for your domain name are stored in its zone file. The Domain Name Server, or “nameservers” as you will often see, determines where this file is located. Typically, the nameservers will be those of the company you registered your domain name with, namely the registrar. There are generally at least two nameservers – a primary (e.g. ns1.registrar-server.tld) and a secondary (e.g. ns2.registrar-server.tld) – to provide redundancy.
Logically, the RRs within the zone file are mapping your domain name to the resources or services of the company where the Domain Name Server is located. This makes sense because their servers will generally handle these services.
When you purchase a domain name, you get the right to determine the Authoritative Domain Name Server and the contents of the RRs associated with the domain.
Several ways to point your domain to your website
In their previous Wiki documentation (not accessible anymore, except via the Wayback Machine), my registrar (i.e. Gandi) was describing three methods to make your website available via your domain name.
Using web forwarding
As explained in Gandi’s (new) documentation5, web forwarding is used when you want your domain name to automatically redirect visitors to another URL
. Not only, this method was qualified by Gandi (in their older documentation) as poor
for search-engine ranking, but also it is not the correct way to proceed. It redirects your domain instead of pointing it. In fact, SiteGround – my hosting provider – is not even referring to this option in their How to point my website to SiteGround? article.
Changing the nameservers
According to Gandi old Wiki, this is the classic configuration for hosted websites
. They also commented about this method being the easy way as your host configures your DNS for you
. Indeed, you just have to replace the nameservers of your registrar by those of your hosting provider. From there on, you will have to manage all the DNS records from the web hosting account (not the registrar account anymore). However, this also means that the RRs will now point to the services of your hosting provider (not those of the registrar anymore). I will come back to this point later.
Editing the RRs (A Record)
Alternatively, you can edit the A Record by replacing the IP address with the one of the web host server (where your website is located). Quoting again Gandi old Wiki, this approach for experienced users
is highly configurable and flexible
. Furthermore, you keep managing your DNS records from your registrar account. However, this method can sometimes cause problem, especially with shared . . . hosting, which might have dynamic IP addresses
2. This issue is indeed suggested in Gandi’s documentation5:
A Records are ideal for pointing your domain (or subdomain) at a server that has a static (does not change) IP address.
When things become more complicated
Putting aside the first method (web forwarding), I had to choose in between two approaches to point my domain name to my website. Which one is the best?
Clearly, the third option was looking great – highly configurable and flexible
– despite the issue with the dynamic IP address6. More importantly, it would allow me to keep all my DNS records at Gandi. Why this matters? Because, in addition to having my domain name registered with Gandi, I was using their dedicated e-mail hosting service (see Registering my domain name).
As for the second option – updating the nameservers – it would resolve the RRs to those of the hosting provider and thus set up the mail servers of SiteGround (instead of those of Gandi) in the zone file. Not only I didn’t want to host my e-mail with my hosting provider (see Self-hosting: a hard egg to crack), but also I was determined to keep the two mailboxes offered by Gandi.
How to point my domain name to my hosting provider (website), but keep my e-mail at my registrar?
Istarted to search for the way to accomplish this everywhere: in books, tutorials, and forums. Clearly, I was not the only one asking this question. Unbelievably, there were several so-called professionals wondering how to do this – as one of [their] clients requested this configuration
.
What the f***! How could they ask people to pay for their services when they are not competent? How could they be so shameless to build a business on skills they do not master?
Now, I might be even more capable than them, still, I would not call myself a professional. Granted, I am not a careerist and I may never make a fortune, but I will remain a man of high principles!
While I could barely find any information on that topic, the few forums addressing this issue were suggesting using the third option – editing A Records – as the other approach would indeed interrupt the services associated with the domain name, such as e-mails. However, through my readings, I discovered that, if I were to opt for that option, I would also have to update the CNAME Records along the A Records. Apparently, A and CNAME Records should be kept together as a rule
. A quote from the old Gandi Wiki kept echoing in my mind: syntax errors will cause your domain name ‘not to work’, both for e-mails or for your website
. Moreover, the issue with the static IP address was repeatedly stressed, suggesting that the other approach – changing the nameservers – was perhaps a better solution.
Updating the nameservers was possibly the best way to point my domain name to my website, but this configuration was disconnecting my domain from the e-mail services of my registrar. Therefore, to keep the latter, I should instead edit the A and CNAME Records, but this configuration was not ideal given the aforementioned static IP address issue. Moreover, the nameservers method was apparently better for other matters, such as subdomain management, SSL certificates… HELP!
Searching for some answers online was bringing no result. It was time to tackle the problem myself. Therefore, I started at the beginning: I studied how DNS works. Following CogitActive’s modus operandi, I read as much as I could to have a better understanding of the subject matter. In the process, I learned that my e-mails did not have to be on the same server as my website and that it was possible to use an external mail server
3 (i.e. any third party e-mail service).
Which server processes your e-mail is controlled by what are called MX records.Peter Pollock
The solution was rather evident7. I didn’t have to use Gandi’s DNS to use their e-mail service, I just needed to have their MX records. Actually, I eventually found in the old, yet valuable, Gandi’s documentation that if you want to use Gandi Mail while keeping the DNS of your current provider, then you will need to . . . change your MX records
. It is unfortunate that the new documentation was not as explicit; knowing this procedure earlier would have spared me some trouble.
Time for action
The procedure on itself – once I figured it out – was supposed to be straightforward.
Updating the nameservers (at Gandi)
As my current configuration was with the nameservers of my registrar, I logged into my Gandi Account. I navigated to my domain name via the Domain section on the left side of the dashboard, selected Nameservers from the menu, and clicked on Change (the pen icon) to edit my settings. My namerservers were indeed default to Gandi’s LiveDNS namersevers; there were three entries (DNS 1, DNS 2 and DNS 3).
As explained earlier, I just had to replace those three pre-filled Gandi nameservers by those of SiteGround. To access the latter, I logged into my SiteGround User Area, navigated to My Accounts and then to the Information & Settings tab. There were two namerservers, under Account DNS:
ns1.us131.siteground.us ns2.us131.siteground.us
I copied the first nameserver (without the IP address in parenthesis) from my SiteGround User Area and pasted in the DNS 1 entry in my Gandi Account (thus, replacing the first Gandi nameserver). I proceeded the same way for the second nameserver to update the DNS 2 entry. As SiteGround has only two namerservers, I could not update the DNS 3 entry. Therefore, I deleted it (following Gandi’s recommendation), keeping only SiteGround nameservers as DNS 1 and DNS 2. I clicked on Save and logged out from my Gandi Account. I was done for this part.
My domain name was now pointing to my hosting provider.
I just had to wait for the changes to propagate.
Changing MX records (at SiteGround)
Actually, I didn’t wait for the nameservers propagation to be completed. I directly proceeded with the second part of my configuration, i.e. replacing SiteGround MX records by those of Gandi. Given my new configuration – using SiteGround nameservers (see above) – any DNS record modification had to be done from my SiteGround Account (not from my Gandi Account anymore).
As I was still in my SiteGround User Area (see above), I accessed my cPanel by clicking on the Go to cPanel button. I clicked on the Advanced MX Editor icon (located in the Mail section), selected my domain (in the drop down menu) and I let Email Routing set to Automatically Detect Configuration (recommended)
. Below the Add a New Record section, the MX records section was showing the MX records of SiteGround:
10 mx10.mailspamprotection.com
20 mx20.mailspamprotection.com
30 mx30.mailspamprotection.com
I had to replace these three entries with the MX records of Gandi:
@ 10800 IN MX 10 spool.mail.gandi.net.
@ 10800 IN MX 50 fb.mail.gandi.net.
To do that, I headed back to the Add a New Record section, set the Priority to 10 (the number immediately after MX in the first record shown above) and the Destination to spool.mail.gandi.net (i.e. with a Fully Qualified Domain Name). I did the same for the second record, with Priority set to 50 and Destination as fb.mail.gandi.net. Once done, I deleted the three SiteGround MX records (as recommended in SiteGround Knowledge base: make sure that you remove any previous MX records
).
MX Records
What about the rest of the record? I indeed input only two things – Priority and Destination – whereas the MX records provided by Gandi have six constituent parts. What are they and why I didn’t have to provide them?
@: this sign is a shortcut for the domain name (defined somewhere else). This entry (Domain) would normally looks like domainname.tld. (the trailing dot being very important).
10800: this number indicates how many seconds the requester should wait before checking back to see if the record has changed. It is the Time To Live (TTL).
IN: this two-digit code is the Class and stands for InterNet.
MX: this is the Record Type
10: this is the Priority – the lowest number is the highest priority (0 being the highest possible priority).
spool.mail.gandi.net.: this is the name of the server that the mail will be hosted on, namely the Hostname. Importantly, this is a name – not an IP address.
Although I didn’t input directly these information, I assume that the Advanced MX Editor tool resolved them. For instance, I provided my domain name at the beginning of the procedure. In addition, the tool will obviously default to IN (as the Class) and MX (as the Record Type). I also assume it used 14000, the TTL used by SiteGround.
However, I was more concerned with the Hostname. As explained in the box above, it is a name – not an IP address. Normally, MX records point to a hostname on the same server as the domain name, and – in the zone file – there must be a corresponding A Record resolving the name to an IP address. What if the MX records are configured to an external server?
Do I have to add an A record for Gandi MX records to point to the actual IP address of Gandi mail servers?
In practice, MX records must indeed be used in conjunction with A records. The MX record always points to a hostname and the A Record (for that hostname) points to the mail server(s). This A Record was nowhere to be found in my zone file! Besides, Gandi did not provide any IP address – just their MX records. HELP!
I could not find any answer to this new issue, but I supposed that the Email Routing configuration was the key. Indeed, the latter can be set to:
- Automatically Detect Configuration (recommended)
- Local Mail Exchanger
- Backup Mail Exchanger
- Remote Mail Exchanger
As stated earlier, I used the recommended configuration and the server automatically configured my domain name as Remote. This means that all incoming [e-mails] for the domain name will be routed to the server where the MX records point
. How the tool resolved the Hostname to an IP address, I do not know. The fact that SiteGround MX records were also pointing to a third party service (i.e. SpamExperts) has perhaps something to do with it. Anyway, I did not add any A Record, and yet it worked correctly: my e-mails were delivered to my Gandi account.
To sum up, it is important 1) to have only one set of MX records and 2) to have the Email Routing configured to Remote (or Automatic with Remote being detected).
“Done!”
“Are you sure? What about the TXT Record?”
“What TXT Record?”
“The one Gandi has in its MX Records”8.
Indeed, there was another Record listed with Gandi MX Records (in Gandi new documentation):
@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"
This TXT record is the Sender Policy Framework (SPF) record for Gandi Mail. However, as SPF records are depreciated
, Gandi used TXT Records instead. As explained in SiteGround Knowledge Base, this record is important for fighting spam and e-mail forgery
as it ensures mail servers will accept [e-mails] sent from your domain only if they are sent from a list of trusted servers
.
To add this extra record, I had to use the Advanced DNS Zone Editor (located in the Domains section of my cPanel). Fortunately, there was already a similar record (the one of SiteGround) that I could use as a template to add the one from Gandi – in the Add a Record section. For the name entry, I did not use @, but directly my domain name with the trailing dot – cogitactive.com. – and obviously choose the TXT Record Type. I also remembered (from my studying DNS) that the TTL should be the same for all TTL Records. As SiteGround default its TTL to 14400, I used 14400 instead of 10800. Last but not least, I entered the Address as:
v=spf1 include:_mailcust.gandi.net ?all
That is without the quotation marks. I clicked on Add record and that is it. I did not delete the similar TXT (SPF) record from SiteGround. Actually, I don’t know if this matters. I was tired of all these extra difficulties. The procedure (pointing my domain name to my hosting provider, while keeping my e-mail at my registrar) ended up not being straightforward at all!
Anyway, now, I just had to wait for all these changes to take effect, i.e. to propagate!
To be continued…
1 If you want to delve into this topic, you may consider starting with this introductory article by Justin Ellingwood. ^
2 Frank Moraes (2018) Beginners Guide To Domain Names. Who Is Hosting This. ^
3 Peter Pollock (2013) Web Hosting For Dummies. Hoboken, New Jersey: John Wiley & Sons. ^
4 Wait a second! What is the point of having a NS Record in the zone file? The zone file resides on this Domain Name Server, anyway. It is a little confusing, but your nameservers must be listed in the zone records held on your nameservers
3. ^
5 Not so long ago, Gandi released their new platform (#gandiV5). At the same time, their former Wiki Documentation was replaced with their new Gandi’s Online Documentation. ^
6 It is possible to upgrade your dynamic IP address (from a shared hosting plan) to a static IP address. On a shared server, actually, a static IP address is called a dedicated IP address. SiteGround “offers” a dedicated IP service, as long as you order it and pay for it. ^
7 If you have understood my explanation about DNS, you may already have the answer. Actually, you may wonder how come I (or any of those “professionals”) didn’t figure this out earlier. ^
8 Again, a conversation with my geeky little bird (see Getting my web host). ^