Plesk to Plesk Migration

Migrating from one Plesk installation to another is easy with the Plesk Migrator Tool! The Plesk team has done a great job creating an easy to use interface for migrating entire installations of Plesk to a new server.

If you need to move files, users, subscriptions, FTP accounts, mail and DNS servers setup through Plesk, this guide will help you successfully navigate the process and come out victorious!

We will be splitting this tutorial into three sections:

Continue reading “Plesk to Plesk Migration”

Install Poweradmin on Ubuntu 16.04

What is Poweradmin?

Poweradmin is a web-based graphical user interface to interact with PowerDNS. It is released under the open source GPL license. It makes it easy to create and edit zone files and interacts directly with the SQL server. Poweradmin has full support for most PowerDNS features, including all zone types (master, native and slave), supermasters, for automatic provisioning of slave zones and full support for A, AAAA, CNAME, HINFO, MX, NS, PTR, SOA, SRV and TXT record types, validation against RFC’s. It also has user and permission management setup for controlling user permissions with templates.  In this tutorial, we’ll be showing you how to install and configure Poweradmin as well as some records.

Continue reading “Install Poweradmin on Ubuntu 16.04”

Gmail Blacklist

As one of the most trusted email providers, Google keeps top-notch security by maintaining their own blacklist and security information. With the numerous users the company provides email accounts to, there is an overwhelming amount of data that Google can scrutinize for spam or malicious emails. By gathering this valuable information, rules are created to filter problem content. These rules are highly sophisticated, and as this data is compiled, specific IP addresses are flagged and sorted into what is called a blacklist.

The Gmail blacklist is designed to prevent unwanted spam, malicious content and excessive amounts of emails. Some of the most common reasons for getting blocked are as follows;

  • Large amounts of emails sent from a new IP address.
  • Sudden changes in email volumes.
  • High bounce rates.
  • Spam reports from Gmail users.
  • Incorrect DNS settings.
  • Low sender scores.
  • IP listing in public blacklists.

Gmail’s blacklist may also take information from several public blacklists in order to block malicious/unwanted/compromised IP addresses prior to having any complaints from them. This is a preventative measure intended to keep the lowest amount of spam possible. All things considered, this is the reason your Gmail address will likely have far less unwanted emails or better filtering rules.

 

There are several effects to being on the Gmail blacklist, and the most obvious is that all email from the IP address sending mail will be blocked. This means everything including personal communication, bulk messages, email lists, etc. Not only will it block the problem domain or user, but everything else on the SMTP server attempting to use that IP address.

This poses a large issue for shared IP addresses on any server. But there is hope! Both in the form of preventative measures as well as ways to redeem your IP address and clear it from the blacklist. Before clearing your IP address we highly suggest you review the information to make sure nothing has been compromised. Blacklists often mean an email has been hacked, or there are just poor emailing practices.

Preventatively, you can protect the IP you are using with SPF records should you have no current issues. These records will assist in providing additional verification for the IP address you are using and help keep your IP clean.

 

If you’re already experiencing issues with Gmail delivery, then the first step is to diagnose the SMTP server. If this is a managed environment, it’s best to contact your hosting provider and ask them to review the specific email address having issues. Be sure to include example messages, any bouncebacks you’ve received and any specifics you can remember. (Subject lines, recipients, time of email, etc.) This should help in the retrieval of data.

You can actually get a full copy of the headers of any messages having issues directly from your email client. If you need information on how to do this, you can always check out this article. View full e-mail headers.

If you are having trouble delivering mail and can’t find any fault on your SMTP server, then it’s time to search some blacklists to test the waters. One of the most reputable places to start is mxtoolbox.com. Although Gmail does not state what mechanisms they use to blacklist, this site allows you to search your domain and query a large number of blacklists that should tell you if there are issues coming from your server. Along with cleanup instructions and links to each blacklist, this site is a handy tool for anyone looking to admin their own email.

There are several other sites that can be referenced for blacklist checking, but unfortunately, the only one way to get information from Google specifically. If you are not on a blacklist and there are no issues coming from the SMTP server, then it’s time to fill out a Delivery Problem Form. This form asks for basic information as well as any technical information you can provide. The more information you can provide, the easier your process will become for a listing check and possible removal or de-listing.

From there, Google should help you through the rest of the process or provide further information that will move the issues along. But that still leaves us with one question….

 

Well, the guidelines differ depending on what you are using email for. As some of us just use email for personal use the rules are pretty simple. Don’t send malicious content, make sure you don’t attempt to use huge files or send to everyone in your address book every thirty minutes for no reason, etc. These are all suspicious behaviors or hard rules that will either fail or cause issues.

Really we can boil the best practices down to a few important rules of thumb.

  • Do not spam.
    • This includes redirects. Google has specific best practices for pulling email from other accounts, so setting up forwarders in other SMTP servers to shovel all mail over to Google addresses will simply count as spam.
  • Follow the bulk mail guidelines.
  • Pull, don’t push.
    • Meaning import messages or set Google to pull from third party, don’t forward to Google automatically. (Manual forwarding to share information is perfectly fine.)
  • Use SPF records.
    • SPF records are great added security and verification.
  • Change your passwords frequently.
    • Remember, passwords are vital and knowing the best practices for safe passwords is very important.
  • Watch for, and read, bounceback emails.

Following the few suggestions above will keep your SMTP server healthy and happy. When all information intended for Google is pulled via their methods, the likeliness of being blocked for false positives (meaning blocked for legitimate practices done incorrectly) will go down exponentially.

 

Change Primary Domain in WHM

If you use multiple aliases ( previously called parked domains) within a cPanel account, you may find yourself wanting to change the main domain used for the cPanel account containing these domains. Changing the primary domain is desirable for multiple reasons and many times occurs when the site in use switches from one TLD to another (i.e., .net to .com). You may desire to change this if the name of your company or site changes. It can also occur when a domain is no longer used, or when the domain is removed from an account. Sometimes the wrong site name was set to be the primary domain, to begin with (we all make mistakes, right?). Whatever the reason for changing the primary domain, the change is relatively simple to make. However, it does make some potentially significant changes on the account that could create the need for additional changes for site functionality, so it is best to understand what these changes are before making this decision wholeheartedly.

Email & DNS

This change will modify multiple factors of the domain including (if you so choose) the cPanel username (which is usually not advised), the FTP username and MySQL users. Making this change will delete any custom DNS records if you are using custom nameservers setup within WHM and hosting your DNS. If using custom nameservers be sure to go into the DNS editor and take a screenshot of your DNS for the domain or copy the records to a text document before making this change. An additional effect is that all e-mail accounts change to reflect the new domain, for example changing the primary domain from yourdomain.com to newdomain.com will change admin@yourdomain.com to admin@newdomain.com. You may then need to update the e-mail address and username (for both incoming and outgoing servers within your e-mail client) on any devices that e-mail account is set up on.

Aliases

If you already added an alias ( a parked domain which shares content) or addon domain (which has its content apart from the main domain), you need to remove it first. Meaning you may need to save the content and site data for addon domains elsewhere on the server until after this change. You will also want to remove any subdomains of your primary domain name before you can change it as well. The following can be used as a basic guide to remove these as the process for each is the same:

Log into cPanel: yourdomain.com/cpanel
Navigate to and click on ‘Aliases’ (this may be listed as parked domains on older versions of WHM) (or you could locate subdomains or addon domains)
Locate the alias you want to be removed and click remove.

SSL Certificates

If you have an SSL certificate applied to this account, you will end up revoking the SSL installed for the current primary domain by removing it. In these cases a new SSL is necessary. If you are using AutoSSL, you may need to re-run to ensure all sites have an SSL installed appropriately. If you have purchased an SSL, you will need to order a new SSL for the new domain name.

Changing the primary domain may require modifying the siteurl if you are using WordPress and this could break the installation until you change the URL.

Hostname

Often changing the primary domain is confused with the hostname of the server, these are separate changes. However, for clarity, this does not change the hostname of the server (your server name) and does not change the name of the server within your manage.liquidweb.com account either. Changing the primary domain will only change data related to the cPanel account and its associated user. While most changes are made within the cPanel account for the user, this change can not be made within the cPanel account for the domain. Changing the primary domain is done via WHM which requires root level access.

Backups

Before making any significant changes on your server, its advised to have the ability to revert in case of mistakes. Create a full website backup via cPanel for the account you want to modify. You can find instructions on how to do this here.

Ensure that you have available backups for the domain within the backup restoration area in WHM. These will be available if you already have backups configured within WHM. If you use alternate means to back up your accounts, ensure you have available backups before making this change.

To change the primary domain, you will need to do this within WHM.

  1. You can access WHM by using the servers IP followed by the port 2087, or if DNS is set up for the hostname, you can access WHM by using the hostname/whm. Another method is to use a domain name on the server followed by /whm:Examples:
    • 192.168.1.1:2087 (replace the IP with your servers IP)
    • https://hostname.com/whm
    • https://domainname.com/whm
  2. To change the primary domain login to WHM using the root user and root password:To change the primary domain log in to WHM using root.
  3. After logging the top right of your window is a search bar (you may need to expand this menu). Access List Accounts via the search bar and click on the link it displays.Find the primary domain in WHM by searching for "List Accounts".
  4. Find the user you want to modify by typing in the name of the account in the new search bar that opens. Then click the + symbol next to the user:In the WHM account click the "modify account" button to change the primary domain.
  5. Finally, click the Modify Account button:The 'modify account' button changes the primary domain in WHM.
  6. Change the Primary Domain to the domain you want in its place:WHM screen indicates where to change the primary domain.
  7. Decide if you’re going to adjust options. You could decide to modify the databases associated with the domain to include new prefixes, for example, changing the Username.
Note:
If you are not familiar with what these changes mean. It’s highly recommended NOT to change the cPanel username. Since the username is tied to the database name, you may get database errors when altering. Changing the username requires further site coding and configuration by your developer. Your WordPress or CMS configuration file will need to be updated if the username is changed creating new database names.

After making this change, you may find that you want to keep the old e-mail addresses used by the old primary domain. If this is the case, the fix is simple. Park the old domain on the new one via an alias and create new e-mail accounts under the old domain name within CPanel’s e-mail accounts section. This way you can still use your existing e-mail accounts and also change the primary domain.

You have successfully changed the primary domain for this account! Our Support Teams are filled with talented admins with an intimate knowledge of multiple web hosting technologies, especially those discussed in this article. If you are Fully Managed VPS customer and you are uncomfortable with performing the outlined steps, we are a phone call, chat or ticket away from assisting you with this process

A Beginner’s Guide to Managed WordPress

Thank you for choosing Managed WordPress at Liquid Web! We hope this guide will help you get started in making the most of your experience with the Managed WordPress Portal. There are some great features in the portal, and we’ve worked hard to make sure site maintenance is a cinch.

 

Quickly Jump To A Subject By Clicking its Link:

Login to MWP Portal and the WordPress Backend
Forgotten Password
Add a User to the MWP Portal
Granting SFTP Access
Migrate a Site
Create a New Site
Taking a Site Live
Managing DNS
Backups

 

Login to MWP Portal and the WordPress Backend

The fastest and easiest way to log into the Managed WordPress Portal is to first log in to your Liquid Web account at https://manage.liquidweb.com.

Once logged in you will see that you are on the Overview page. Here you will see your Managed WordPress server. Just click the plus sign next to that server to reveal the LOGIN button and click it.

Hint:
The Managed WordPress Portal uses the same credentials as your Liquid Web account so once logged into Liquid Web click the login button.

Liquid Web's WordPress control panel reveals how to login.

Once logged into the Managed WordPress Portal you will see the Welcome Screen which will ask you for a nickname and an email address to create your first site. Just be sure to follow the guidelines on what characters you can or cannot use in a nickname.

When the site is finished deploying, the portal will now show one default WordPress installation that you can work with pictured below. This WordPress instllation is called MyNewSite.You can simply click on the WP-Admin button, and that will take you directly to the WordPress login page for the new default site.Alternatively, click the blue link and append the default site URL with /wp-login.php.  In the above example this would be: https://mynewsite.m9n7y4ka-liquidwebsites.com/wp-login.php

When you create a new site in Managed WordPress Portal, you will be emailed an administrative user and password so you can access the site right away. It is recommended that you login and change the password immediately for security reasons.

 

Forgotten Password

If you forget your password, you can always access the login page and click on the “Lost Your Password” link under the login area. Clicking that link will send an email used to create the new default site, allowing you to change your password.

Click on the "Lost Password?" link to retreive WordPress Credentials.

As a best practice, you will always want to make sure you never use default usernames like “admin” or “user” or simple passwords (like English words) as they can be easily guessed using brute force methods. We have created some best practice for securing WordPress to help you add some extra security to your site.

 

Add a User to the MWP Portal

Since you will be working with different areas that can be confusing we’ll be using the following terminology to differentiate between them.

  1. Managed WordPress Portal – the custom control panel for your WordPress sites in Managed WordPress. The Portal is where you will add sites, work with those sites, access and adjust the setting for your websites. It’s also where you can find your backups!  The Portal will have a URL that begins with the word “app,” uses a custom string, and ends in “liquidwebsites.com” Example = https://app.m9n7y4ka-liquidwebsites.com/
  2. WordPress Dashboard – the traditional term for the back end of all WordPress sites. When you login into a specific WordPress site to perform maintenance on pages or plugins, you are accessing the WordPress Dashboard for that site.
  3. Liquid Web Account Management – this is the primary account area at Liquid Web where you log in to view all your products and services at Liquid Web, such as your invoices, your credit card payment, DNS zones, and other settings or tools that we provide for you.

You can add users to Managed WordPress Portal by logging into the Portal and then clicking on Users in the left menu. On that page, you will find a default “liquidweb_staff” user, used by our support staff, but feel free to add on any co-workers who need access to all the sites.

To add a new user click the blue Create User button to the far right.

Managed WordPress lets you add users to access sites.

Hint:
Any user you add to the Managed WordPress Portal area will be able to work with and make changes to ALL THE SITES including the ability to deleting sites from the portal.

If you want to restrict site access for a single team member, it’s best to create a WordPress Dashboard user (a WordPress user) allowing access only to that specific WordPress site.

Granting SFTP Access

If you wish only to give SFTP access to a team member (and not portal access or WordPress Dashboard access) you can provide the SFTP credentials to that team member.

  1. You can find those SFTP credentials by logging in to the portal and clicking on the blue Manage Site button for the specific site.Retrieve SFTP credentials in the Manage Site section.
  2. You will now find many portal tools and settings for that specific site. Scroll down the page until you come to the SFTP/SSH Credentials area. This area will initially provide the user, IP, and port information for accessing the site over SFTP.
  3. Click on the blue Generate New Password button.  When the popup window appears and asks, “Are you sure?” click the OK button.
  4. The page will refresh, revisit the SFTP/SSH Credentials area to find a new password was generated for that specific site.SFTP credentials are regenerated within the Manage Site section.

 

For your convenience, sse the blue COPY links to copy the information. When you are ready to revoke SFTP access for a team member access the SFTP/SSH Credentials area again and click the blue Generate New Password button to reset the password to something new.  Here are some things to know regarding SFTP.

  1. Passwords can be changed at any time.
  2. Each site in Managed WordPress portal only comes with one SFTP user and that username cannot be changed.

 

Migrate a Site

We have a custom plugin that will allow you to migrate any live, public-resolving site into Managed WordPress Portal.  You can find the plugin in the WordPress repository or even search it from a WordPress Dashboard on the Plugins page. The plugin is called Migrate to Liquid Web. This plugin was built with ease-of-use in mind and works great for anyone who wishes to migrate their own site.

Instructions for downloading and using the plugin are here:  https://www.liquidweb.com/kb/migrating-to-liquid-web-with-managed-wordpress-portal/

Some things to know about using this plugin are:

  1. Implement the migration plugin on the source, live site. It uses a push method, and thus, the source site must be publicly reachable by DNS. The plugin will not work on a local WordPress copy that is not openingly accessible through a URL.
  2. It can only push a copy of a site into our Managed WordPress and Managed WooCommerce product at Liquid Web. It is not compatible with migrating into other products at Liquid Web.
  3. It is not compatible with WordPress Multi-site (WordPress Multi-site is not compatible with our Managed WordPress solution). We can, however, break up a multi-site installation into individual sites and our team can then migrate each source site into their own, individual destination site on Managed WordPress Portal.

We are happy to perform a migration for you as well, even for multiple sites.  Here is how you can submit a request for a migration to have our team migrate a live site for you into Managed WordPress Portal:  https://www.liquidweb.com/kb/free-website-migration-service/

 

Create a New Site

To create a new site in Managed WordPress Portal simply log in to the portal and then click the Create New Site button in the upper right of the portal.

The portal will then ask you for a nickname for the site along with an email address.  Fill out both fields and then click the Create Site button.Create a WordPress site through a nickname.

It’ll take a minute or two to see the new site in the portal.  An email will shortly arrive with a username and password to access the WordPress Dashboard (also known as the WordPress backend) of the new site. Each WordPress site created in the portal installs with the default TwentySeventeen theme and comes fully prepared with its own SFTP/SSH credentials.

The email address used to install a new site is the same one used for important future updates to our portal, reports and other administrative WordPress tasks for that specific site.

With a new site deploys you’ll be provided a temporary URL to access the site.  The URL will include both the nickname of the site and the default temporary URL that is a part of your specific Managed WordPress Portal.

 

Taking a Site Live

When a site is migrated into Managed WordPress Portal it is copied to a temporary URL that is publicly resolvable over DNS. The temporary URL provides a means to test the functionality and before taking it live. This testing time provides an opportunity to get the site ready with all changes before it needs to be taken live with the real URL.

Two essential and sequential steps are necessary before publishing a site to the Internet.

  1. Change the  A record for the domain to the IP address within your Managed WordPress Portal. DNS does have to be taken care of first for the second step to work.
  2. Change the name in the Primary Domain field in the portal (under Site Details) from the temporary URL to the actual domain name.  That can be done by logging into the portal, clicking on Manage Site, and then find the Primary Domain field. Just replace the temporary URL with the straight domain name and click UPDATE.Taking a WordPress site live entails renaming the primary domain.

The portal will put the site into maintenance mode as it runs the update and gets the site ready to be live with the real domain name.The Managed WordPress Maintenance Page lets us know that updating is in progress.

Here are some things to note about the renaming process.

  1. DNS does have to resolve to the IP address of the server to deploy our automatic SSL (Secure Sockets Layer) application. Our SSL implementation runs a public DNS lookup to retrieve the IP address.
  2. The renaming process will automatically replace the temporary URLs in the database to ensure menus and image links will work with the real domain.
  3. If you wish for the site to resolve to the www version of the domain you will need to include that in the Primary Domain field in the portal.  In that case, you would set the primary domain field to www.domain.com instead of domain.com
  4. The site will be issued an automatic SSL during this process that will programmatically stay up to date!
  5. Once the renaming process has finished the portal will leave maintenance mode, and you will see the portal tools and features again for the site. At this point, the site will now be live on Managed WordPress Portal.

You can find more information documented on this here:  https://www.liquidweb.com/kb/going-live-site-managed-wordpress-portal/

 

Managing DNS

Many times customers wish to have Liquid Web host all their DNS records for a domain. You can do this by using Liquid Web’s name servers.You can use the following process to migrate all DNS records to Liquid Web:  https://www.liquidweb.com/kb/migrating-your-dns-to-liquid-web/

 

Backups

We know that backups are critical, so we provide those for you in Managed WordPress.Just click on Manage Site for the site you wish to work with and then click on Backups in the left menu.Backups are included in each Managed WordPress Product.

Here are a few apsects to note on our backups.

  1. Backups run nightly and are secured off-site location, so they don’t take up any space on the server where you sites live, meaning better performance for your websites.
  2. We keep 30 days of nightly backups, and while they are remote, you do have access to them on the Backups page.
  3. On the Backups page, you can manually create a new backup, download a backup from a specific date, or restore a backup from a particular time.
  4. If you choose to restore a backup from a specific date, it will restore right on top of the live site and revert the site to how it looked and operated on that date and time.

 

What is Power DNS?

PowerDNS (pdns) is an open source authoritative DNS server that works as an alternative to traditional BIND (named) DNS. PowerDNS offers better performance and has minimal memory requirements. PowerDNS also works with many supporting backends ranging from simple zone files to complex database setups as well as various SQL platforms (Mysql, MariaDB, Oracle, PostgreSQL). Continue reading “What is Power DNS?”

Understanding the DNS Process

Do you ask yourself, “What is DNS?” “Do I need to use DNS?”  Do you feel confused? In some cases, DNS can be convoluted and complicated.  Let’s talk about Domain Name System (DNS) services. When you need to access a website, you type the domain name, such as www.google.com, into the web browser instead of typing an IP address. A conversion happens between www.google.com to 172.217.12.46, an IP, which designated to a device on the Internet. This conversion is a DNS query, an integral part of devices connecting with each other to communicate over the internet. To understand the DNS query process, let’s talk about how a DNS query routes through different components.

Step 1: Requesting Website Information

First, you visit a website by typing a domain name into a web browser.  Your computer will start resolving the hostname, such as www.liquidweb.com. Your computer will look for the IP address associated with the domain name in its local DNS cache, which stores DNS information that your computer has recently saved.  If it is present locally, then the website will be displayed. If your computer does not have the data stored, then it will perform a DNS query to retrieve the correct information.

Step 2: Contact the Recursive DNS Servers

If the information is not in your computer’s local DNS cache, then it will query the recursive DNS servers from your (ISP) Internet service provider. Recursive DNS servers have their local DNS cache, much like your computer. Given that many of the ISP’s customers are using the same recursive DNS servers, there is a chance that common domain names already in its cache. If the domain is cached, the DNS query will end here and the website displayed to the user.

Step 3: Query the Authoritative DNS Servers

If a recursive DNS server or servers do not have the information stored in its cache memory, the DNS query continues to the authoritative DNS server that has the data for a specific domain. These authoritative name servers are responsible for storing DNS records for their respective domain names.

Step 4: Access the DNS Record

For our example, to find out the IP address for www.liquidweb.com, we will query the authoritative name server for the address record (A record). The Recursive DNS server accesses the A record for www.liquidweb.com from the authoritative name servers and stores the record in its local DNS cache. If other DNS queries request the A record for www.liquidweb.com, the recursive server will have the answer and will not have to repeat the DNS lookup process. All DNS records have a time-to-live value, which shows when a DNS record will expire. After some time has passed, the recursive DNS server will ask for an updated copy of the DNS record.

Step 5: Final DNS Step

The Recursive DNS server has the information and returns the A record to your computer. Your computer will store the DNS record in its local DNS cache, will read the IP address from the DNS record, and pass this information to your browser. The web browser will connect to the web server associated with the A records IP and display the website.

The entire DNS lookup process, from start to finish, takes only milliseconds to complete. For a more profound understanding let’s break down the previously mentioned DNS components that are relevant to the DNS lookup process.

The DNS Process

Authoritative DNS Server

An authoritative name server is a DNS server that stores DNS records (A, CNAME, MX, TXT, etc.) for domain names. These servers will only respond to DNS queries for locally stored DNS zone files.  For example, if a DNS server in my network has a stored A record for example.com, then that DNS server is the authoritative server for the example.com domain name.

Recursive Nameserver

A recursive name server is a DNS server that receives DNS queries for informational purposes. These types of DNS servers do not store DNS records. When a DNS query is received, it will search in its cache memory for the host address tied to the IP address from the DNS query. If the recursive name server has the information, then it will return a response to query sender. If it does not have the record, then the DNS query will be sent to other recursive name servers until it reaches an authoritative DNS server that can supply the IP address.

A DNS zone is an administrative space within the Domain Name System (DNS). A DNS zone forms one part of the DNS namespace delegated to administrators or specific entities. Each zone contains the resource records for all of its domain names.

A DNS zone file is a text file stored on a DNS server that contains all the DNS records for every domain within that zone. It is mandatory for the zone file to have the TTL (Time to Live) listed before any other information. The TTL specifies how long a DNS record is in the DNS server’s cache memory. The zone file can only list one DNS record per line and will have the Start of Authority (SOA) record listed first. The SOA record contains essential domain name information including the primary authoritative name server for the DNS Zone.

DNS Zone File

Stored in authoritative DNS servers are the DNS records, these records provide information about a domain including its associated IP address for each domain. It is mandatory for all domains to have a few necessary DNS records to be able to access a website using a domain name.

Below is a list of the most common types and frequently utilized DNS records. Let’s dive into each kind of record.

A (Address) Record
A (Address) Record An A record points a domain name to an IP address. For example, when you type www.google.com in a web browser, it will translate to 172.217.12.46. This record links your website’s domain name to an IP address that points to where the website’s files live.Example of A record
CNAME (Canonical Name) Record
A CNAME record forwards one domain name to another domain name. This record does not contain an IP address. Utilize this type of record only when there are no other records on that domain name. Otherwise, conflict is introduced by any other records interfering. An example, a CNAME can just go from www.google.com to google.com and not to any additional domain name such as gmail.com.

Example of CNAME record

MX (Mail Exchanger)
This type of record routes all email messages to a specified mail server on behalf of a recipient’s domain to a designated mail host. The MX records use a priority number when there is more than one MX record entered for any single domain name that is using more than one mail server. The priority number specifies the order of access to the listed mail servers. Counterintuitively, the lower number is the higher priority. For example, the priority number of 10 set within the MX record will receive the email messages first. The MX record with the priority number of 20 will be a backup if the MX record with the priority of 10 is unavailable.

Example of MX records

TXT (Text) Record
Utilized for information and verification purposes the TXT record discloses information to other services about your domain such as what services the domain is using. Sender Policy Framework (SPF) records are added as TXT records to help identify if email messages are coming from a trusted source.

Example of TXT record

NS (Name Server) Record
Name servers are servers usually owned by a web hosting company, such as Liquid Web, that are used to manage domain names associated with their web hosting customers. The NS records are created to identify the name servers for each domain name in a given DNS zone. Example of NS records

SOA (Start of Authority) Record

The SOA record is a resource record which stores information regarding all the DNS records in a given DNS zone.  An SOA record contains properties for a zone such as:

  • The name of the primary DNS server
  • Email address of the responsible person for that zone
  • The serial number that is used by a secondary DNS server to check if the zone has changed
    • If a zone has changed on the primary DNS server, then the changes are copied to the secondary DNS server which changes the serial number.
  • Refresh Interval
    • This shows how frequently the secondary DNS servers check for changes to any of the records, as determined by the TTL . 
  • Retry Interval
    • The retry interval displays how frequently the secondary DNS servers should retry checking if any changes are made to the zone if the first refresh fails.
  • Expire Interval
    • Shows how long the zone will be valid after a refresh.
  • Minimum (default) TTL (Time to Live)
    • The SOA records are outlined in https://www.ietf.org/rfc/rfc1035.txt  under “Domain Names – Implementation and Specification”.

Example of SOA record

SRV (Service) Record

The SRV records are created to establish connections between services and hostnames.  For example, if an application is searching for a location of a service that it needs, it will look for an SRV record with that information.  When the app finds the correct SRV record, it will filter through the list of services to find the following information:

  • Hostname
  • Ports
  • Priority and Weight
  • IP Addresses

Here is an example of two SRV records.

_sip._tcp.example.com.   3600 IN SRV 10 50 5060 serviceone.example.com.

_sip._tcp.example.com.   3600 IN SRV 10 30 5060 servicetwo.example.com.

Note: _sip is the name of the service and _tcp is the transport protocol.

The content of the SRV record defines a priority of 10 for both records. The first record has a weight of 50 and the second a weight of 30. The priority and weight values promote the use of specific servers over others.  The final two values in the record describe the port and hostname to connect to for accessing any services.

PTR (Pointer) Record
A PTR record (Reverse DNS record) does the opposite of an A record. It resolves an IP address to a domain name. The purpose of this record is mainly administrative to verify that an IP address links to a domain name. Not all DNS hosting providers offer this type of DNS record.

Now that we have talked about the DNS services and the DNS components, we can troubleshoot any DNS issues which may have arisen. Below is a list of common DNS troubleshooting tips.  

  • If your website is displaying that a “server IP address could not be found,” then it’s possible that the A record is missing. You will need to add an A record to your DNS zone.

Error Page "IP Address Not Found"

  • Check to see if you have any improperly configured DNS records.
  • When you change your name servers for your domain name, you will need to wait for the name servers to propagate. The propagation can take up to 24 hours to complete.
  • Check to see if you have high TTL (Time to Live) values. For example, you have an A record that has 86400 seconds (24 hours) as the TTL value if you update the domain’s A record to point to a new IP address, it will take 24 hours to propagate. It is better to change the TTL value to 300 seconds which is 5 minutes. We have a great article that talks more about TTL values.
  • If you are using a third-party proxy server for your website and your website is not displaying, you can use your computer’s host file to see where the issue is occurring. For example, I have the website dnswebtest.com using a third-party proxy server, and it is displaying a connection error. I need to find out if the issue is with the web hosting company or the third-party proxy server. I will access my local host file, add my website dnswebtest.com as an entry and point it to the web hosting company’s IP address, for example, 98.129.229.4. If I then go to my site in the browser and it displays correctly, then I know the issue is with the third-party proxy server. Here is an excellent article on How to Edit Your Host File.

Although DNS can be a complex issue, with a better understanding of the process and a few troubleshooting tips, you will be much more confident when working with it or troubleshooting problems. The following third-party tools are also quite useful when checking for DNS propagation or finding what types of DNS records a domain name has:

  1. https://www.whatsmydns.net/  for DNS propagation
  2. https://www.whoishostingthis.com/ to show what IP address a website is resolving to

 

DNS Zones Explained

DNS Zones

A DNS Zone is a portion of the DNS namespace that is managed by an organization or administrator. It serves as an administrative space with granular control of DNS components and records, such as authoritative nameservers. There is a common misconception that a DNS zone associates only with a single domain name or a single DNS server. In actuality, a DNS zone can contain multiple domain and subdomains. Multiple zones can also exist on the same server.  Information stored for a DNS zone lives within a text file called a DNS zone file.

 

DNS Zone Files

A DNS Zone file is a plain text file stored on a controlling DNS server that contains all the records for every domain within a given zone. Zone files can include many different record types, but must always begin with what is called an SOA record (Start of Authority).

 

Types of Records

 

As mentioned, there are a handful of different types of records used within a DNS Zone, all of which serve a unique purpose. Below are some examples of the most commonly used record types and a brief description of each.

Start of Authority (SOA)

The first record in any zone file is the SOA resource record. This record is an essential part of the DNS zone file. It indicates the domain’s zone and the fundamental properties of the domain name server. Each zone file can contain only one SOA record.

Name Server (NS)

NS records tell recursive name servers which name servers are authoritative for a zone. Recursive name servers look at the authoritative NS records to facilitate which server to ask next when resolving a name.

 

Note
The only zone file that matters is the one located at the authoritative name server for the domain. You can find which name servers the internet will look at through a whois lookup on the domain.

Mail Exchange (MX)

MX records, usually two, are responsible for specifying which mail server is in charge of receiving email messages on behalf of a site. The email client tries to make an SMTP connection to the primary mail server listed in the zone file. The records are ranked by priority from lowest to highest with the lowest being the primary. If the primary server is not available, the next listed mail server will attempt a routing connection. MX records must point to a domain, not an IP.

Address (A)

The A record is used to find the IP associated with a domain name. This record routes info from the server to the end client’s web browser.

 

AAAA

The quadruple A record has the same function as the A record but is used specifically for the IPv6 protocol.

Canonical Name (CNAME)

This record will alias one site name to another. The DNS lookup will then route domain name requests the new name that the A record holds. These records must point to a fully qualified domain name (FQDN).

 

Alias Record (ALIAS)

The ALIAS record is functionally similar to a CNAME record in that it is used to point one name to another. That said, while CNAME records are for subdomains, an ALIAS record is used to lead the apex domain name (example.com) to a subdomain such as host.example.com. The authoritative nameservers for the Apex domain will subsequently resolve the IP of the hostname to direct traffic.  

Text (TXT)

TXT records hold the free-form text of any type. Initially, these were for human-readable information about the server such as location or data center. Presently, the most common uses for TXT records today are SPF and Domain_Keys(DKIM).

 

Service Locator (SRV)

Generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX. This type of record, while helpful, is not commonly used.

Pointer (PTR)

Pointer records point an IP to a canonical name and used explicitly in reverse DNS. It is important to note that a reverse DNS record needs to be set up on the authoritative nameservers for the person that owns the IP, not the person that owns the canonical name.

Reverse DNS Lookup

DNS is typically used to resolve a domain name to an IP address. This act is known as a forward resolution and enacted every time you visit a site on the internet. Reverse DNS (rDNS), as its name implies, is a method of resolving an IP address to a domain name.

The DNS records used for resolving an IP address to the domain name are known as pointer (PTR) records. A particular type of PTR-record is used to store reverse DNS entries. The name portion of the PTR-record is the IP address with the segments reversed and “.in-addr.arpa” added at the end of the record. The “.in-addr.arpa” portion of the record refers to the “address and routing parameter area” (arpa). rDNS uses “in-addr.arpa” for IPv4 and “ip6.arpa” is used for IPv6 addresses.

For example, the reverse DNS entry for IPv4 IP “1.2.3.4” would be “4.3.2.1.in-addr.arpa”.

 

The use of reverse DNS is for the same reason as standard (forward) DNS. It is easier to remember and identify a domain name than a string of numbers. rDNS is less critical than forward DNS, as forward DNS records are required to load up a website. Sites will still load fine in the absence of a reverse DNS record.

Email Servers commonly use rDNS to block incoming SPAM messages. Many mail servers are set to automatically reject messages from an IP address that does not have rDNS in place. Though the rDNS record can block spam, it is not a reliable means and is used mostly as an extra layer of protection. It is also important to note that merely enabling rDNS can still result in rejected messages due to a variety of reasons.  Additionally, rDNS is also used in logging to help provide human readable data rather than logs consisting entirely of IP addresses.

 

Reverse DNS lookups query the DNS servers of a domain for a PTR (pointer) record. If the domain’s DNS server does not have a valid PTR record setup, it cannot resolve a reverse lookup.  However, if a domain does have a PTR record, you can do a rDNS Lookup by using the method below.

 

Numerous online tools can be used to perform a rDNS lookup. A few examples of these online tools are linked below:

https://mxtoolbox.com/ReverseLookup.aspx

https://www.whatismyip.com/reverse-dns-lookup/

https://www.iplocation.net/reverse-dns

 

You can also perform a rDNS lookup manually from command line. In Linux, the command you would use is “dig” with the added “-x” flag. 

If you are on a Windows computer, you would typically use the “nslookup” command, though you could also use “ping -a”. An example of the Linux command and its output shown below:

dig -x 8.8.8.8

 

Output:

;<<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -x 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36810
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa. IN PTR
 
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa. 21599 IN PTR google-public-dns-a.google.com.
 
;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jul 18 11:58:54 EDT 2018
;; MSG SIZE  rcvd: 93

 

You can see the full rDNS PTR record for that IP in the “ANSWER SECTION” leading 8.8.8.8 back to the Google subdomain, google-public-dns-a.google.com :

8.8.8.8.in-addr.arpa. 21599 IN PTR google-public-dns-a.google.com.

Liquid Web makes it easy to set up and manage rDNS for your servers IPs. Just follow the steps outlined in our Knowledge Base article below:

https://www.liquidweb.com/kb/using-manage-to-update-reverse-dns/

 

Setting up a reverse DNS record is straightforward and can be beneficial to ensure that an IP does indeed belong to the domain it claims. If you are unsure who your DNS provider is, follow our helpful guide in locating where you should add the rDNS record.