Support >Onboarding Checklist >Onboarding

Onboarding

DNS, Domains and the Hive

Learn about DNS, domains and how they relate to configuring a Hive with a custom domain.

A long story short(er)....

There are a few domain records to change and a number of domain records to check to launch the hive.

The records you need to change to launch a hive will include:

  1. Primary A record
  2. www CNAME record
  3. TXT record for the SPF entry

Let's go with an example, and say your website domain you want to use is "example.com"

  • The primary A record for example.com will need to be set to your Hive's IP address (which will be provided by the support/onboarding team)
  • The www CNAME should point to your base/primary domain, in this case www.example.com should point to example.com using a CNAME record. If the www record is an A record, delete it and recreate it as a CNAME record that points to the base/primary domain.
  • Finally a TXT record for your spf should be edited/created to include your mail service, the primary A record and sendgrid (which the Hive will use to send emails).
    If you were using google gsuite/workspace for your email, your spf TXT record would look like "v=spf1 a include:sendgrid.net include:_spf.google.com ~all". Make sure you only have one spf TXT record entry, multiples of these records may confuse email systems and may not be honored.

If you currently have more than one A record for your base domain, you should delete the extra records and just have one which points to your hive ip address. The same goes for the www CNAME record, just one should remain that points to your base domain. Similarly, if you have more than one TXT record with an entry for spf (all spf records start with "v=spf1"), you should delete those and have only one spf record that contains the appropriate entries for your mail service and the Hive services (particularly the A record should be included on the spf and include:sendgrid.net should be present on the spf record).

Some frequently asked questions

What is a domain name?
Fundamentally, it is a human readable address for your website. Like www.example.com, www.bobsgym.com, www.facebook.com, etc.

How do I get a domain name?
You purchase one from a domain registrar. Popular domain name registrars include but are not limited to: GoDaddy, Namecheap, and Domain.com

What is a domain registrar vs what is a dns record/nameserver?
A domain registrar is where you purchase your domain and also where you set the nameserver addresses. Nameservers ultimately hold the actual DNS records. DNS records are the entries that tell computers where your services are ultimately located (such as email and your website itself). As a simple analogy, you can view the registrar as the index card at the library that tells you where a book is located, and you can view the namserver as the actual book itself that has the actual information.

Where are my domain records?
Just because you register a domain with GoDaddy, doesn't necessarily mean that GoDaddy is where your dns/domain records are being hosted. If you check your domain at your registrar, look for the "nameservers" settings. These will tell you where the domain records are being hosted. If the domain records are with your registrar, it should indicate that. Otherwise it will tell you what nameservers the domain records are residing on.

My registrar does not provide domain/dns record hosting, what should I do?
Some registrars (such as Reg.ca) do not provide domain record hosting services with your domain. If you don't have anywhere to host your domain records, contact our support/onboarding team. FitHive can host your dns records for you.

How is a hive launched on a domain?
The first step is to make the necessary domain record edits. Then we must wait for them to propagate (it takes time for them to be made effective, the amount of time it takes depends on your dns host and TTL configuration). After the records have propagated, the FitHive support/onboarding team can initiate the domain change on your Hive. The records must be ready before the domain change on the Hive can be done, because the SSL/encryption certificate used to secure the data transmission for your Hive can only be acquired after the domain name points to the Hive itself.

The nitty gritty - a deeper look

What are all these records?

There are a handful of record types you are likely to encounter or need to change. There are also a number of types that you should not change. Here is a deeper explanation as to what those are and what to look out for when you change your dns records.

For most small businesses, there are only two services that are tied with their domain name that are critical to their business: website and email service.

Let's say you have a domain name "example.com". If you use email addresses that end with @example.com, then your email service is tied to your domain name and needs to be considered carefully when changing your domain name records. If you use an email address from another provider, and your email address does not end with @example.com - then your email service is not tied with your domain name.

Common email services that are not tied to your domain name might end in @gmail.com, @yahoo.com, @aol.com, @outlook.com, etc. If the email addresses you use for your business do not end with @yourdomain.com, then your email service is not with your domain name.

When your email service is configured, it is important that it is configured in a way that makes it independent of your website configuration, as far as your domain name is concerned. This will make it possible to point your email service to a different provider than your website service. Some inexpensive website/email hosting companies setup all your services by default to be interconnected - which means it will be more difficult to change domain configuration without interrupting your email service. Consult your domain registrar or email service to determine the correct settings to separate your email service from being dependent on your website service.

Here are the 4 dns record types that you will come across that are most common and will have to be checked and/or potentially modified to change your website service.

  1. A records - address record, ultimately points a service to a specific computer using a computer routable address (IP address)
  2. CNAME - canonical name, point one record to another record by name. For example, if you point www.example.com to example.com, that is a CNAME record. One record points to another record, but ultimately the chain of records must encounter an A record eventually in order to be usable.
  3. MX - mail exchange, designates another record or address that handles email service for this domain. Typically there are multiple records listed and they have a priority setting that goes with them.
  4. TXT - arbitrary text records, stores text values on a domain record. primarily used for spf records, domain verification, and DKIM keys for email signing. You will need at least one of these for your SPF entry

Records to never modify on your domain records:

  1. PTR - do not edit or delete these records, these are potentially used for reverse lookups by IP address
  2. NS - nameserver records, do not alter these, they will be set by the DNS hosting service

Uncomon record types:

  1. SRV - uncommon for small business, only configured for very specific services/technologies, watch for these to verify no interdependence on records that will be changing
  2. AAAA - address record with ip address for version 6 ip addresses (very long address), not widely used yet and not used by FitHive, delete when present for primary domain records being used with the hive (ones that have A records used for the hive).

Your domain service may be configured with an explicit SPF type on your spf record. This should be setup as a TXT record and then the record with the "SPF" type should be deleted. SPF types are not supported anymore. SPF record type support was discontinued as they were not widely adopted. Instead TXT is the preferred record type for spf records. For more detailed information see the specification RFC 7208 - direct quote from the specification: "SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued."

TTL - time to live on domain records. This is a count of seconds which serves a suggestion to other services about how long your dns records should be cached and not refreshed/refetched. We recommend most of your records should be set to 1 hour (3600 seconds).

Some common things to watch out for

Unintentional record interdependence is something that can cause you some headache. For example, lets say that currently your website host also providers your email service. For the purposes of this example, let's say your domain is "example.com" and your MX records point to mail.example.com domain record. If your mail.example.com record subsequently points to your primary A record (where your website will live), if you were to change your primary A record to change your website service - you would unintentionally also be pointing your email service to that new place as well.

To prevent this unintentional email service change - you first need to recognize in your records that this situation exists. You would follow the breadcrumb trail from the MX record all the way to a resolved ip address record (A record). If that breadcrumb trail takes you to the same records that serve your website, then a dangerous cross interdepdence of your domain records exists.

To fix the cross dependence, you would create new records for the mail service to point to that do not ultimately depend on the same records that your website service uses. In this example with "mail.example.com" we could change the "mail.example.com" record from being a CNAME record pointing to the primary record to just being an A record with the current value held in the primary A record.

Here is a before and after snapshot of this example:

Before:

example.com = 1.2.3.4 ip address
MX record = mail.example.com
mail.example.com = CNAME pointing to example.com

After:

example.com = 1.2.3.4 ip address
MX record = mail.example.com
mail.example.com =1.2.3.4 ip address

With this change, you can now change the primary A record for example.com to be another service without affecting your email configuration.

Another thing to watch out for is your email program/client's configuration. Following this example, if you (or your staff) have configured your phone or computer to connect to example.com to retrieve your new email messages so you can read them and respond to them, then you will need to reconfigure your email programs (phone and/or computer) to connect to mail.example.com instead. Because when your website service changes away from "1.2.3.4 ip address" to another address, then the system it points to is no longer the same system that was providing your email service.

Ultimately the goal is to eliminate unwanted cross dependence in your domain records so that you can potentially separate your website and email services successfully.

 

Further Reading

If you just love learning about dns/domain records, here are some suggested articles:


Category > Section:Onboarding Checklist >Onboarding