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

Uses of Reverse DNS

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.

The Reverse DNS Lookup Process

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.

Perform a rDNS Lookup

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.

Set Up rDNS

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.

The post Reverse DNS Lookup appeared first on Liquid Web Knowledge Base.

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.

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.

The post DNS Zones Explained appeared first on Liquid Web Knowledge Base.

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.

DNS Lookup Process

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.

DNS Servers

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.

DNS Zone & DNS Zone Files

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 Records

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.

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. 

DNS Troubleshooting

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.

• 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

The post Understanding the DNS Process appeared first on Liquid Web Knowledge Base.

When using custom name servers, it is essential to update the DNS in cPanel/WHM, doing so, is a component of hosting your own DNS. To use custom name servers, you must update the nameservers at your domain’s registrar to match your Liquid Web server’s hostname. If you are unsure how to do this, you can see how in our article Setting Up Private Name servers in WHM/cPanel. It is critical to have created a cPanel account and to add the domain to your WHM panel, if you haven’t already,  follow our article, How To: Create a cPanel Account in WHM.  Additionally, access to your registrar’s control panel is necessary to update the name servers. If you are questioning who your registrar is, learn how to locate where your domain’s DNS is by following the instructions in our article, Where Is My DNS Hosted?

Knowing your DNS provider is imperative in guaranteeing that you’re pointing your name servers to your Liquid Web server. There is not much use in updating the records you see in WHM if your name servers are not looking to the Liquid Web server. Any updates that you want to take place have to be done so on the authoritative server for DNS (which in this case is Liquid Web), as this is the actual server responding to DNS requests.

Editing DNS Through WHM

Once you’ve set up your custom nameservers and created a cPanel account, the final step is to edit the DNS in your WHM/cPanel account.
If you’re setting your records through WHM/ cPanel and your WHOIS information reflects the correct name servers, then you are ready to make changes to your DNS. There are several different kinds of DNS records that you can set up, but the most essential of the records, and the one I am going to focus on for this article is the A and CNAME records.

After logging into WHM navigate to “Edit DNS Zone” under “DNS Functions,” and select the domain you want to edit DNS. Once highlighted, select “Edit” to update records on a particular domain.

Once you enter the zone file, none of the changes you make will take effect until you save them, so you can back out at any time and start over, a good tactic if you think you have messed up the syntax. Many parts of the zone file will never get changed, so we will focus on the three fields you are most likely to edit:

• Domain
• TTL (Time to Live)
• Record Type

These are significant fields for the function of the DNS, and within each area, specific nuances tend to raise questions from people, but the fundamentals remain very simple. The Domain field should be the domain name followed by a trailing period (.). Anywhere that a Fully Qualified Domain Name (FQDN) is used, never forget the trailing period. If you are not using a FQDN in the domain field, you can use the sub-domain, which does not require the trailing period.

This image shows several different sub-domain names and how their syntax differs from FQDNs:

The TTL column controls how long the record remains cached before it requires the general public to re-request the DNS record from the source. Caching is convenient during times of migration because it can effectively minimize downtime by using a lower TTL! The IN field always needs to be set to IN, so it is best not to make changes to this field.

Lastly, we have the record type, which is twofold: it’s necessary to select the record type and fill in the data field. For example, if you choose to add an A record, an IP address must follow that in the adjacent field. If using a CNAME then you’ll use a FQDN in its adjoining field, again, don’t forget the trailing period!

WHM is broken up into two sections, one section allows for modifying the existing data OR adding a record. In this example, we are going to add an A record a new sub-domain “files.domain.com,” if propagation is a factor we can edit the TTL:

In this example, we’ve added a new record to my zone file using a TTL of 300 seconds and pointed to the IP of the sub-domain. It will take at least 300 seconds, and up to 24 hours in some cases, for you to be able to see that domain from your browser or through a DNS lookup. Once you have added this info, you can save your changes! For the sake of brevity, we will skip the mail exchanger settings.

Editing DNS Through cPanel

So far, we have only discussed editing DNS in WHM. Editing in cPanel is much more straightforward only offering two record options: add an A record, or add a CNAME. CPanel has fewer options and does not give full permission to the Panel user to edit their file, though they can make additional A and CNAME records, necessary for adding such elements as CDNs (Content Delivery Networks) or sub-domains.

If you need to add an A record through the cPanel you will want to search for and click on “Zone Editor” through the cPanel interface:

Once in the Zone Editor, you will have the option of adding either an A, CNAME, or an MX record. You will see the options next to a plus sign:

This becomes useful when setting up services like CDN or the like. CDN services typically require a CNAME record to be added. In the following example, we are adding a CNAME to dnsexample.com for the sub-domain cdn.dnsexample.com:

Once complete, select “add” and the record will be saved. One advantage of the cPanel view versus the WHM view of the DNS record is the ability to filter your search by record type:

In closing, when the hosting DNS on your server enables editing through WHM >> Edit DNS Zone. Altering any records will not be reflected changes if the name servers are not pointed to the appropriate server. In general, you won’t touch or need to change most fields in the zone file, except for Domain, TTL and Record Type. Through WHM you can make edits to the existing record or opt to add records. To get started with editing your DNS records and locate your DNS provider our easy to follow DNS article can assist you.

The post Editing DNS Zone Files in WHM/cPanel appeared first on Liquid Web Knowledge Base.

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

Authoritative and Recursor DNS Servers

Authoritative Nameservers are DNS Servers that contain the DNS records for your domains. The authoritative nameserver will answer queries with information directly from its records.

Recursor DNS servers (commonly referred to as Recursive or Resolving) function between the end user and the authoritative DNS server. Queries that are submitted by the end user arrive at the recursive DNS server first, which then searches for the records in its cache. If the queried record cannot be found in the cache, the Recursive server then sends the query to the authoritative nameserver to resolve the requested record details.
For a deeper understanding of the DNS process visit our helpful Knowledge Base article.

PowerDNS Caching

By default, PowerDNS uses ‘Packet Cache’ to identify similar queries and the provides related answers respectively. It does this without any further processing of the request. The default cache interval is based on the TTL (time to live) setting for PowerDNS, which is 20 seconds.
In addition to caching entire packets, PowerDNS can also cache individual queries. Most DNS queries typically involve additional backend queries. An excellent example of a backend queries would be the lookup for a CNAME record.

When an end-user queries the ‘A’ record for ‘www.example.com,’ PowerDNS must first run a background query to check for the ‘www’ CNAME record. The PowerDNS Query Cache will cache these types queries for quicker recall in the event of similar future requests.

PowerDNS Advantages

While BIND is perfectly fine for the average host or user, PowerDNS provides a robust set of features and added performance suited for larger server environments with load-balancer configurations, such as reseller. One of the critical elements of PowerDNS is that it supports DNSSEC (DNS Security Extensions) creating an extra layer of security for your domains DNS. Also, PowerDNS has a convenient web-based user interface called Poweradmin that has a variety of helpful management tools.

For a full list of notable features pertaining to the PowerDNS Authoritative Server and PowerDNS Recursor, visit the links below:

https://www.powerdns.com/auth.html
https://www.powerdns.com/recursor.html

Poweradmin

Poweradmin is a browser-based administration tool for PowerDNS. It supports master, native and slave zones types. It can also be used for automatic provisioning and supports multiple coding languages. Below are a few examples of what the Poweradmin interface looks like and the tools and features it posses. For a full list of Poweradmin features visit https://www.poweradmin.org/features.html.

Main Page –  Available tools and features can be seen on the main page of Poweradmin when you first log in.

Search Tool – Utilizing the search tool allows you to query all of the DNZ zone setups with your PowerDNS for a specific string of text (name, IP address, etc.)

Add a Master Zone – The Master Zone is used as the primary point of a query for all DNS requests made to the PowerDNS.

Secondary Zone – As a failsafe, the secondary zone handles DNS queries should the Master Zone experience issues or go unresponsive.

The post What is Power DNS? appeared first on Liquid Web Knowledge Base.

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.

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.

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.

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

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.

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.

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.

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.

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.

The post A Beginner’s Guide to Managed WordPress appeared first on Liquid Web Knowledge Base.

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.

Before Making Changes

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.

Changing the Primary Domain

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:
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.
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:
5. Finally, click the Modify Account button:
6. Change the Primary Domain to the domain you want in its place:
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.

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

The post Change Primary Domain in WHM appeared first on Liquid Web Knowledge Base.

Going live with your site is the last step in the process of migrating your WordPress sites into Liquid Web’s Managed WordPress portal. These instructions are for domains pointed to our DNS. To check where your name servers are pointed to visit this DNS checker and input your domain name.  If your name servers point to ns.liquidweb.com and ns1.liquidweb.com you can continue on the tutorial.  Otherwise, you’ll want to update your A record’s IP with the outside name servers.

Step #1: Create DNS Record

1. Log into your Liquid Web account.
2. Click on Domains to open the domain page. 
3. Select the DNS tab to open your DNS management screen. 
4. Click on the [+] to expand the DNS records for that domain. 
5. Once the DNS records are open, you will need to add an A Record to point your WordPress site to the correct domain.
6. Click Add New Record to create a new A Record for your site. 
7. Enter the domain name, TTL of 3600, select A for the record Type from the drop-down menu. 
   Note:

   For this tutorial, we are leaving the domain name empty, as I want the A record to apply to the entire lwtrainingmwp.com domain name. For more information on what information goes into your A Record, see our article DNS Record Types.

    

8. The IP address to add to the A Record can be found in your Managed WordPress portal on the home page. Click Copy to copy the IP address from your dashboard. 
9. Paste the IP address into the A Record for your domain. 
10. Click the green check mark to create the A Record.
11. The A Record will appear in your DNS zone list. 

Step #2: Change Your Domain

1. Once the A Record is created, go back to your Managed WordPress Dashboard site home page. 
2. Change the Primary Domain to the domain you want to use for the site and click Update. 
3. When you click on the site link under Domain at the top of the page, your site will open and is now live. 

The post Going Live With Your Site in Managed WordPress Portal appeared first on Liquid Web Knowledge Base.

What is the 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.

Why Should a Blacklist Matter?

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.

Need to Know about SPF Records?

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 have control over your own SMTP, such as a VPS, you should be able to review these messages in the /var/log/exim_mainlog on a cPanel server. Or simply go to the WHM and locate the “Mail Delivery Reports” tab to view any delivery reports for emails across the entire server.

Keep in mind that the bounceback messages you’ll get from Google will have information on why you are having issues as well. Look for the three digit error code and this should shed some light on exactly what’s wrong. You can find a list of error codes here.

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

What are the Best Ways to Stay Off the Blacklist?

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.

The post Gmail Blacklist appeared first on Liquid Web Knowledge Base.

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.

Prerequisites

If you don’t already have PHP, Apache, and Mycrypt installed on your Ubuntu 16.4 server you will need to install them now.

First, add the repository for the most recent versions of PHP.

sudo add-apt-repository ppa:ondrej/php

Then update your repo cache and install.

sudo apt-get update
sudo apt-get install apache2 libapache2-mod-php php php-common php-curl php-dev php-gd php-pear php-imap php-mcrypt php-mysql php-xmlrpc gettext libmcrypt-dev

Then install Mcrypt for PHP and Apache.

sudo pecl install mcrypt-1.0.2
sudo bash -c "echo extension=/usr/lib/php/20170718/mcrypt.so > /etc/php/7.2/cli/conf.d/mcrypt.ini"
sudo bash -c "echo extension=/usr/lib/php/20170718/mcrypt.so > /etc/php/7.2/apache2/conf.d/mcrypt.ini"
sudo systemctl restart apache2.service

Installing Poweradmin

Now that we have the prerequisites out of the way we can install Poweradmin. First, start by going to the document root of the site where you want to install Poweradmin. For these purposes, I am going to use the default document root in /var/www/html.

cd /var/www/html

Then download and extract Poweradmin.

sudo wget https://newcontinuum.dl.sourceforge.net/project/poweradmin/poweradmin-2.1.7.tgz
sudo tar xf poweradmin-2.1.7.tgz
sudo mv poweradmin-2.1.7 poweradmin

Now go to your domain.tld/poweradmin/install to complete the full installation of Poweradmin.

Step 1. Select your language.

Step 2. Acknowledge warning.

Step 3. Fill in database information and set the password for the admin user.

The database and user are “pdns”. The password was automatically generated password that was set when installing PowerDNS. You can find the password by catting the pdns config file.

sudo cat /etc/powerdns/pdns.d/pdns.local.gmysql.conf

The password will be the string of letters and numbers after”gmysql-password=”. You will also be asked to set the admin user’s password.

Step 4. Create a pdns user and set some default configurations.

Put in a username and password for the non-admin pnds user. Set the default Hostmaster and nameservers.

Step 5. Create the database user in MySQL.

Log in to MySQL and then copy and paste the command to setup the database user in MySQL.

Step 6. Set up the PHP configuration file.

Create the PHP configuration file and copy and paste the output into the file.

cd poweradmin

sudo vim inc/config.inc.php

Step 7. Create the .htaccess and remove the install directory

sudo cp install/htaccess.dist .htaccess

sudo rm -rf install

Now you can browse to the poweradmin homepage domain.tdl/poweradmin. You should now see the login screen.

Using Poweradmin

When you first log in you will be greeted with the main page and a list of available options.

The first thing you are likely to want to do is set up your domain with an A record. To do so simply click on “Add master zone”.

Now you will see a box to enter in the domain name. In this case, we’re using example.com as the domain. There are a couple of other options you can choose from. We left them as their defaults, but this would be a good time to set the zone’s owner (i.e., which Poweradmin user can modify the zone file) and also set the template to create the zone with specified DNS records already in place. Click “Add zone”.

Now click list zones again, and you will see your newly created zone. Since we didn’t set up a template with our new zone file, it will not have any A records yet. To change that click the edit icon.

Now we can add the A record for the domain. We changed the type to A, fill in the IP address under “Content”, set the priority and the TTL then click “Add record”.

That’s all there is to it. With the record set up for example.com, we can now do a domain name lookup with dig on the server to get the IP address I just set up.

dig example.com @127.0.0.1

This request should now show something like this.

;; ANSWER SECTION:
example.com.       1440    IN A  127.0.0.1

This can, of course, be accomplished as we pointed out earlier with MySQL but Poweradmin is much more user-friendly and does not require knowledge of MySQL. Poweradmin is required to be installed separately from PowerDNS and has more requirements than PowerDNS (i.e., PHP, Apache, and Mycrypt).

In this Knowledge Base, we have shown you how to install Poweradmin on a server running Ubuntu 16.04. Be sure to check out our other Ubuntu related articles.

Cloud Spectator, an industry leader in laaS Marketplace Analysis, confirms Liquid Web’s VPS servers outperform Rackspace, Amazon, and Digital Ocean across the board.

The post Install Poweradmin on Ubuntu 16.04 appeared first on Liquid Web Knowledge Base.

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!

Pre-flight

You will need:

1. Two Plesk installations and a basic working knowledge of Plesk and DNS.
2. The current server you are migrating sites from with Plesk installed (Source Server)
3. The new server you are migrating sites to with Plesk installed with an equal or higher version number. (Destination Server)

If you are looking for a great VPS with Plesk pre-installed and ready to go, try one of our Liquid Web VPS packages!

Special notes:

1. While this guide is for Windows servers, the same process applies to Linux servers with the exception of the RPC agent tool, the location of the .hosts file, firewall rules and scripts.
2. Only settings that have been configured within Plesk will be migrated. If you have done any special configuration changes outside of Plesk (which is not supported) these settings will not move properly, and you will have to re-configure them manually.
3. This guide assumes you are moving to new IP addresses. If you are maintaining the same IP addresses, you will have to work with your hosting provider and configure a loopback adapter to successfully migrate IP addresses to a new server. This is not something Plesk will do natively.
4. The Plesk Migrator Tool copies data from one server to another. It does not automatically delete any data such as subscriptions or customers from the source server. This allows us the ability to test migrated sites before going live and shorten any downtime from live services.

Initial Sync for Plesk Migration

To begin the installation, log in to your Plesk Administration Panel on the destination server (the new server you are migrating sites to) by logging into https://127.0.0.1:8443 where 127.0.0.1 is your destination servers IP address or domain name used by Plesk.

Once logged in, you will navigate to Extensions > My Extensions > Plesk Migrator.

Open the Plesk Migrator (you may have to press Open twice) and then click Start a New Migration located at the top of the page. This will open a page that looks like the following:

Now fill in the required fields.

The Address is the IP address of the source server you are migrating sites from.

For Setup, we will first attempt Automatic.

Enter the Plesk login for the source server.

Leave the Temp Directory as it is unless specifically needed.

Enter the Plesk login credentials for the destination server you are migrating sites to.

Now click Prepare Migration.

At this point one of two things happen:

1. You will either see the Preparing Migration load bar complete, and it moves to the next page. Note: It may take some time for the progress bar to complete.
   OR
   
2. An error will pop up and say “Panel Migrator failed to connect to RPC Agent running on ‘<your-ip>’ server. RPC Agent is required for communication between the current server and ‘<your-ip>’ server”. A migration error may pop up when migrating Plesk to Plesk.

This time it will bring you to the next step in the Migrator Tool. This page is where you select what data you would like to transfer. You can migrate by subscription, customer, reseller or hosting plan depending on your needs. In most cases, moving by subscription will be the best option. This is what we will do in this guide.

You can migrate all available subscriptions or move one or two. It’s up to you! Simply select the checkboxes you desire and click Select Object. You can always remove items from the list if you select the wrong one.

For our example, we will be moving only one subscription which contains the domain, all mail messages, files, and databases to the new server.

Now that we have selected our subscriptions to migrate (or all of them!) and selected migrate mail messages, migrate website files, and migrate database data, we can begin.

Click Migrate.

Plesk will go through its pre-migration checks and compare the servers and files to make sure it is compatible. If you failed any pre-migration checks, it will provide you with any error(s) and how to resolve it.

Once this is done, click Start Migration.

You will now see a progress bar and exactly what step your migration is on for each subscription you are migrating. This is helpful for monitoring the progress and status of your migration.

Now, you wait! This process can take a few minutes or many hours depending on how much data you are moving. This is dependent on website file sizes, database sizes, mail messages and more. You are able to leave this page and come back to the Plesk Migrator extension anytime you want to recheck the migration progress.

Once the migrations are complete, it will show a green banner saying that your subscriptions have been migrated and it will display any issues that arose during the process.

Testing the New Plesk Environment

At this point, we can begin the testing phase on the destination server to make sure all websites are functioning properly before we final sync and go live on the new server. We can accomplish this using the .hosts file.

The hosts file works by letting you locally designate which IP address a domain points. This won’t affect live service for the domain, as IP changes would need to be handled at the DNS level, but it allows you to see the site as if it were running from your specified IP address, in this case, the destination server.

To get a list of domains and their associated IP addresses, you can run the following command from command prompt on the destination server. You can access command prompt by going to Start > Run and typing in cmd and running it.

Enter the following command:

%plesk_bin%\dbclient.exe" --direct-sql --sql="SELECT iad.ip_address, dom.name FROM domains dom LEFT JOIN DomainServices d ON (dom.id = d.dom_id AND d.type = 'web') LEFT JOIN IpAddressesCollections ia ON ia.ipCollectionId = d.ipCollectionId LEFT JOIN IP_Addresses iad ON iad.id = ia.ipAddressId;

This command will give you a list in the following format:

<ipaddress> exampledomain.com

<ipaddress> example2.com

<ipaddress> example3.com

Highlight and copy these results. Navigate to C:windowssystem32driversetc in file explorer and open the .hosts file with Notepad. The file will include a blurb about the HOSTS file and have examples such as:

127.0.0.1 localhost
::1 localhost
127.0.0.1 mewebmail.localhost

Paste your copied results at the end of this file and save.

Now you will be able to go to your browser on the destination server and access any of these domains from the new server without affecting live services. You can verify that you are seeing information from the destination server by making a modification on the file or database and seeing this reflected in your browser on the destination server.

If you do not see the changes, try accessing the site via a private or incognito windows within your chosen browser. This will let you access the site without cached information.

Go through each of your websites and test their functionality. Make sure the data is correct, and website features are functioning as expected.

If you are experiencing issues with database connections, you will need to modify connection string in your website(s) to point to your domain name (which is loading locally via the hosts file) or to the correct destination IP address, this way the site is loading the local SQL database servers. It is usually recommended to use ‘localhost’ for your database server, if databases and web content will be loaded from the same server, which would avoid this configuration issue. These connection settings are often located in web.config file on Windows or in your server-side configurations (wp-config.php for WordPress, for example). These settings are dependent on how your site was developed.

Does everything look good? Great!  We can now move on to the final sync. Delete or comment out the changes you made to your .hosts file on the destination server. Otherwise, make adjustments to your destination server’s configuration or add any necessary missing modules to make sure it is compatible with the sites you are migrating, and re-test.

Final Sync in Plesk

DNS

To reduce downtime during the final sync, you will want to update your TTL (Time To Live) values in your domains DNS records to 300. This can be done at your domain registrar.

Lowering this value from its default value to 300 will allow DNS updates to occur every 5 minutes instead of every few hours. This ensures your transition to the new server goes quickly and propagates globally in just a few minutes.

Block Public Facing Ports

During the final sync, you will want to block all public facing ports on your source server. We want to do this because we do not want data to be updated on the source server while we are syncing the data. If something is updated on the source server, that change may not reflect on the destination server.

To block public facing ports, we can run the following command in command prompt to create a firewall rule:

netsh advfirewall firewall add rule name=Final_Sync_Block protocol=TCP dir=in action=block localport=21,25,80,110,143,443,1433,3306

This command blocks common ports for services such as FTP, Mail, HTTP, SSL, and SQL servers. This ensures no clients are updating information from your website or mail servers.

Beginning the Final Sync

So now that you have tested your websites on the new server, blocked all public facing ports, and updated your DNS TTL values, we are ready to perform a final sync your data and go live.

To do this, log in to Plesk on the destination server, browse to Extensions > My Extensions > Plesk Migrator Tool. You will see your current migration with the host of your source server’s IP address.

Click on the IP address (do not click Finish Migration, this will remove the migration meta-data from Plesk and you will have to start the process over from the beginning).

You will see the sync completion screen that we saw earlier. It looks like this:

At the top, click List of Subscriptions then click Switch to Advanced Mode.

You will see a list of all subscriptions in your account. Check any subscription or all subscriptions that you are migrating and click the Re-Sync button at the top of the page.

It will prompt you to select which content you would like to re-sync, including business objects, website files, database data, and mail messages. You will most likely leave the default information checked which is website files, database data, and mail messages.

Any information that was changed from the initial sync until now will be updated to the current version if checked. If you have made changes on the destination that you do not want to be replaced, select your checkboxes accordingly.

Click OK.

Your subscriptions are now re-syncing all selected data to the destination server. You can watch this progress by going back to the Overview section of the Migrator Tool.

Final Steps

Now that all subscriptions have been re-synced, there are a few final steps to take before you are live.

First, update your database connection strings if necessary. Again, these should be pointing to your domain or your new server’s IP addresses. If you did not re-sync web files, the changes you made during testing would remain intact.

Now, update your DNS A records. You will want to go to your nameservers (e.g., Namecheap, GoDaddy or Liquid Web’s DNS management if you registered it through us) and update all A records for your domains to their new respective IP addresses. You can verify which IP addresses are configured to each domain by running the command from the Testing phase again or by navigating to Tools & Settings > IP Addresses and clicking on Sites for each IP to see what is assigned to it.

Your DNS changes will take around 5-10 minutes to propagate globally with the lowered TTL values. You can check the status of the propagation by going to, for example, DNSChecker.org or WhatsMyDNS.net and entering your domains. You will see which IP address each location is using around the world and can watch them update in real time by refreshing the page.

Take a break! You have now completed your Plesk to Plesk Migration!

Once you are done, close the RPC agent command shell on the source server. When you have verified everything is working, you can remove the new firewall rule we created on the source server. You can remove this firewall rule by running the following command in the command prompt:

netsh advfirewall firewall delete rule name="Final_Sync_Block"

And really, that’s it! The Plesk Migrator tool makes the process of migrating entire Plesk installations to a new Plesk server, a walk in the park. While you may receive errors along the way, Plesk’s useful details will show you what errors are occurring and how to resolve them.

We hope your Plesk migration has gone smoothly! Compared to the traditional ways of migrating websites, Plesk does a fantastic job of making this easy for the end user.

Looking for a great VPS with Plesk pre-installed and ready to go? Try our Liquid Web VPS packages and speak to a specialist today!

The post Plesk to Plesk Migration appeared first on Liquid Web Knowledge Base.

Sites with SSL are needed more and more every day. It’s ubiquitious enforcement challenges website encryption and is even an effort that Google has taken up. Certbot and Let’s Encrypt are popular solutions for big and small businesses alike because of the ease of implementation.  Certbot is a software client that can be downloaded on a server, like our Ubuntu 18.04, to install and auto-renew SSLs. It obtains these SSLs by working with the well known SSL provider called Let’s Encrypt. In this tutorial, we’ll be showing you a swift way of getting HTTPS enabled on your site.  Let’s get started!

Pre-flight

• Apache installed with a virtual host file for your domain already created
• Logged in as the root user
• An A record is necessary for your domain, Let’s Encrypt verification will be performed through a DNS lookup

Step 1: Update apt to ensure we are working with the latest package tool.

apt update && upgrade

Step 2: We’ll install the Certbot software, as this will aid in obtaining the SSL (certificates) from Let’s Encrypt.  Type Y when prompted to continue.

sudo apt install certbot

Step 3: Installing Certbot’s Apache package is also required. Type Y when prompted to continue.

apt install python-certbot-apache

Step 4: Time to attain the SSL from Let’s Encrypt.  Enter your email address and go through the prompts.  This step will look through your /etc/apache2/sites-available/yourdomain.com.conf file, specifically the website name set with the ServerName directive.

certbot --apache

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A
Your choice to opt in to their newsletter.
-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o:

Jumping off of our Apache Configuratio tutorial, we want both of our domains covered with the option of www and non www for our visitors. We’ll leave the input blank and hit ENTER.

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: domain.com
2: www.domain.com
3: domain2.com
4: www.domain2.com
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

In our tutorial we will select the Redirect option, you may choose No redirect if you would still like your site reachable through HTTP.

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):2

A congratulation message will appear as well as instructions of where your SSL certificates are, just in case you need them later on.

- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/domain.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/domain.com/privkey.pem
Your cert will expire on 2019-07-16. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

Step 5: Verify your domain was issued the Let’s Encrypt SSL by visiting your site in the browser.  Be sure to clear your browser if you don’t readily see the SSL lock.

You now have an SSL encrypting the traffic to your site.  A few things to point out:

• SSLs are valid for 90 days at a time
• Let’s Encrypt will automatically renew
• Any notifications from Let’s Encrypt will be sent to the email address specified in the .conf file

Get our fully Managed VPS servers, and you can control Let’s Encrypt through your WHM control panel.  Not only will you get a clean control panel to adjust server aspects but you also get 24/7 support at your fingertips.  See how our servers can make admin tasks easier!

The post How to Setup Let’s Encrypt on Ubuntu 18.04 appeared first on Liquid Web.

If there is one truth in the world of web hosting, it is that we always need more information. Information about configurations, servers, connections, delivery speeds and networking is essential in troubleshooting and optimizing our web presence. While this kind of information can be gathered from various providers and sites across the Internet, Liquid Web has developed a one-stop shop toolkit to gather some of the most vital troubleshooting tools in one convenient interface designed to make your life easier.

The Liquid Web Internet Webhosting Toolkit provides you with the data you need to verify connectivity, identify DNS issues, and test web page performance. We’ll continue to develop and share new tools that will make your job easier; it’s one of the ways that we are working to be the Most Helpful Humans in Hosting.

IP Checker

Knowing the public IP address of your workstation can help you to unblock your computer if it has been flagged by server security software. Head over to our Internet Web Hosting Toolkit and click on the IP Checker tab. This will display your public IP address (how your workstation identifies itself to the rest of the Internet).

SSL Verification Tool

SSL Certificates are a vital part of securing your website when doing business on the Internet. Ensuring your website’s SSL is up to date and correctly functioning is a necessary task in assuring your visitors that their transactions and information is secure. To check your SSL status, browse to the SSL Verification Tool and enter your domain name.

When you click Submit, the site will show all the relevant information about the SSL for your domain, including when the SSL was initially ordered, it’s expiration date, the Certificate Authority who issued the certificate, the type of encryption , and all of the domains/subdomains covered by the certificate.

DNS Tree

Understanding your DNS records is necessary for website accessiblity. DNS records can be confusing, but we’ve simplified the concept by creating a visual map of your DNS entries to identify essential records.

When you click Submit, the DNS Tree will display all of the DNS records that are available from your domain’s authoritative nameservers. The domain will be shown on the left, then the authoritative nameservers, followed by the types of available records (A records, MX records, TXT records, etc.) and finally the actual records at the far right of the screen.

This allows you to verify your public DNS records are correctly set. Mismatched records or missing data could result in users receiving errors, like “DNS address could not be found”, when trying to browse your website.

Performance Test

The newest addition to our Toolkit is the Webpage Performance Test. This page is a collection of tools for testing the responsiveness of your website using a variety of metrics and testing locations. These tests can assist in creating a more efficient and faster site, providing a better experience for your users and customers.

The post How Do I Use Liquid Web’s Hosting Toolkit? appeared first on Liquid Web.

What is DNS?

If you are new to web hosting, you may have heard the term DNS, but you might not be sure what it means or how it is essential to you. DNS is short for Domain Name System, and it is the process by which the whole Internet organizes and easier way for humans to reach websites. Numbers or IP addresses identify all of the computers/websites connected to the Internet. While computers have no trouble identifying each other using these strings of numbers, it would be challenging for humans if we had to remember a set of numbers for every website we wanted to visit! Fortunately, DNS translates domain names like liquidweb.com to an IP address and back, so all we need to know to find a website is the name. For a more in-depth discussion of the DNS system, see Understanding the DNS Process.

You can use the DNS Tree for a quick, visual comparison of the records that exist on all of your nameservers. Making sure your records match across nameservers and that they match your server is an essential part of troubleshooting possible website issues. If you’re error messages like “This site can’t be reached” or “webpage is not available”, the DNS Tree may help you figure out where the problem exists.

How Do I Check My DNS?

Verifying accurate DNS records is essential for navigating traffic to the correct web server. You can use Liquid Web’s Internet Webhosting Toolkit to view your current, authoritative DNS records. Just go to the toolkit’s site, click on the DNS Tree tab, enter your domain name, and click Submit.

If you have registered your domain and set DNS records our tool will display the results in an easy to see “tree” of records, organized from most general to most specific.

In our example, we are looking up the records for liquidweb.com, so the tree begins with that domain at the far left of the screen.

The next set of records displayed are the Authoritative Nameservers for the domain. These are the servers designated as the holders of the records for this domain. If you want to change the records for this domain, you must change them on these servers. Changing records anywhere else won’t make reflect DNS changes. Your domain can have one, two, or as many Authoritative Nameservers as you would like but most websites use at least two for redundancy and stability.

The next set of entries in the DNS Tree show the Types of records that are available. DNS record types are unique for each kind of DNS function.

• An “A Record” is used to identify primary IP addresses of given domains.
• “MX Records” are used for email routing and delivery.
• “TXT records” hold additional information about the domain, like SSL validations, DKIM entries, or SPF records.

For more information about DNS record types, see DNS Record Types.

The final “column” of entries displays the actual DNS record. This is typically an IP address for an “A record”, and domain name for an “MX record”, or a string of text for a “TXT record”. Hovering the mouse over a circle will display all of the information for the record in a pop-out window, including the TTL, Type, and Data.

If you’ve made recent changes to your DNS records, the toolkit may be showing an older, or cached, version of the records. The TTL portion of the record indicates how frequently the DNS system should update its records. TTL is shown in seconds, so a typical setting of 3600 means that servers will be asked to update your records every 6 minutes. The delay that occurs during this period is referred to as propagation. Some DNS changes, like nameserver changes, can up to 72 hours to propagate, so if you are going to be making changes to your DNS records, you’ll want to lower your TTL values for a quick update. For more information on reducing your TTLs, see How To: Lowering Your DNS TTLs.

If you need additional help, Liquid Web customer’s can contact the Most Helpful Humans in Hosting via ticket, chat, or phone at any time and we’ll do our best to make sure everything is working correctly.

The post What’s My DNS? appeared first on Liquid Web.

In part 3 of our series of InterWorx vs. cPanel, we’ll be reviewing the following sections: MySQL, DNS, and NFS/Clustering. In InterWorx, there are three divisions under each main section.

• MySQL Server
  • Overview
  • Remote Servers
  • PHPMyAdmin
• DNS Server
  • Overview
  • Zones
  • Synchronization
• NFS (Network File System)
  • Overview
  • Exports
  • Mounts

WHM also has three distinct areas for each of the corresponding options noted above:

• SQL Services
• DNS Functions
• Clusters

InterWorx MySQL

In the MySQL Server section of InterWorx, we see the first option called overview. The overview area provides a quick summary of the MySQL server operations.

This section above contains three fields which include the MySQL Server Control Queries area (where queries are noted), the MySQL Server Control which shows the status of the MySQL server (allowing you to stop, start, or restart the database server), and the MySQL Root Password change section where you can edit the root MySQL password.

In the next section, we see the MySQL Server Options. This section contains the settings used for connections, timeouts, buffer and packet size as well as multiple caching options.

Lastly, we see the running MySQL processes that are active on the server.

WHM MySQL

In WHM, MySQL is covered under the SQL Services section. Here, the controls provided are defined in a more granular manner and are broken up into eleven subsections.

All of the MySQL options available in InterWorx are also covered in WHM, with the addition of four other options, namely the Database Map Tool, Manage Database Users, Repair a MySQL Database, and Manage MySQL Profiles. Overall, WHM provides more GUI controls for users but the command line options are always available to supplement any needed options.

InterWorx DNS

In the DNS Overview section of InterWorx, we again have a summary area that provides a quick review of the server’s active DNS operations.

Above, we see the version of DNS that’s running, the default nameservers, the default zone file settings, and the SOA (Start of Authority record) format.

In the right-hand section, we see the Active DNS Services section and the IP Addresses Without DNS Services area. The Active DNS Services section also denotes how to handle certain query types like recursive and iterative queries. The IP Addresses Without DNS simply indicates any unassigned IP’s on the server.

WHM DNS

WHM again provides a more granular means of handling DNS.

In this area of WHM DNS functions, we have the ability to add a DNS zone, add an A record to your hostname, delete a DNS Zone, enable DKIM/SPF for all domains, run a nameserver report, park a domain*, set up domain forwarding, and sync DNS records. Many of these options are scripts that are added to WHM to improve functionality. InterWorx does not have the ability (within its existing GUI) to accomplish many of these tasks.

“*In SiteWorx there exists the ability to park domains manually, but hosting several domains under one account is not supported by SiteWorx at the moment. You can edit the domain.com.conf files manually to add more virtual hosts to a SiteWorx account but the SiteWorx interface would not recognize the second domain.“

In the image above, we see WHM can edit zones, MX entries, and zone templates as well as set TTL’s, perform a DNS cleanup, and lastly, reset a DNS zone. Most of these options, InterWorx does not have a GUI option available but can be accomplished via the command line.

InterWorx NFS

The InterWorx NFS or Network File System provides the ability to mount folders from other servers on your InterWorx server.

In the image above, we can see the status of the NFS service, the actions available for the service (Start, Restart and Stop), and the ability to configure the service to start on boot. It also notes the NFS version.

To the right of the above section, we see the usage statistics graph that is generated by RRDTool.

NFS Exports

This section is the interface that interacts with the /etc/exports file which manages access to the filesystem via NFS. To create an NFS export, you simply need the following information:

• Directory To Export
• IP Allow List
• Read/Write Access
• Root User Access
• Sync Options

After that info is supplied, clicking add will modify the /etc/exports file and add the export entry. You can then view/edit/delete the entry in the “Exported NFS Shares” table.

Mounts

The Mounts section denotes where your server is acting as an NFS client to an external NFS server elsewhere. This simply means that you have data stored on a server elsewhere and you want to have it accessible as a local drive.

To summarize, Exports pushed a folder or drive to an external server and Mounts pulls in an external folder or drive to this server.

WHM Clusters

Here we see WHM’s option to link this server to other servers in a configuration cluster. You can also copy this server’s configuration settings to the cluster’s servers from other WHM interfaces. Them, when you update a setting, the system will copy the changes over to the cluster’s servers.

In WHM’s DNS Cluster option, it allows you to synchronize DNS records among multiple cPanel & WHM or cPanel DNSONLY servers.

Lastly, we see the Remote Access Key option. This option sets up remote access keys that allow you to log in to your server without the need for a password. This key can be used as a remote access key to authenticate with WHM’s remote API or DNS clustering features. Warning: This interface is deprecated and will be removed in a future release. We strongly suggest that you use the Manage API Tokens interface. This feature can be found under Home »Development »Manage API Tokens. That interface lets you create, list, update and revoke API tokens. It also lets you assign Access Control List (ACL) privileges to API tokens.

Note; cPanel does not natively support NFS, but it can be configured manually.

Conclusion

Most all of the MySQL, DNS, and NFS/Clustering solutions can be found both in InterWorx and in WHM. These systems work well because they utilize the same underlying software, but the interfaces may be implemented or laid out differently. If there are shortcomings with InterWorx, they can be mostly overcome using the command-line (CLI) capabilities built into the underlying OS itself as both platforms run on CentOS 7.

Learn More Today!

If you still have thoughts or questions regarding these management panels, our Level 3 system admins are standing by 24 hours a day, 7 days a week to take your call!

Give us a call today at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Hosting advisors today!

The post InterWorx vs. cPanel: Part 3 appeared first on Liquid Web.

What is DNS?

The Domain Name Service (or DNS) is the key to the presence of your server on the internet. You are probably aware your domain has an “IP” address, which stands for Internet Protocol; that number is your domain’s literal web address on the internet. A typical IP address is a series of four numbers called octets that are identified like so: 10.10.10.10.  You can think of your IP address as being similar to a postal address. The IP address is the exact location where your domain lives. I usually explain it like this;

Let’s say my friend Bob’s address is at 123 Main Street.

My other friends all know his location as “Bob’s House.”

Now, we can compare 123 Main Street as the IP address since it’s specific to a single location and “Bob’s House” would be the equivalent of the domain name.

123 Main Street and “Bob’s House” are the same location, but defined in a different way.

DNS is the system that tracks the information that 123 Main Street and “Bob’s House” are the same location. The DNS protocol translates a domain name to an IP address and back again.

Your domain name (we’ll use domain.com in this article) is much easier for humans to read and remember than a long string of numbers. Without the DNS system, the actual location of a domain is not transferred to other computers on the internet. DNS tells other networked computers where your domain resides.

As you can see from the above graphic, DNS is a multi-layered system. At the peak of this hierarchy are 13 top-level root nameservers that store all of the domain names and their associated IP addresses. These root nameservers are managed by IANA and are located all over the world in different geographically diverse locations. Under those root nameservers are the top-level domain servers like .com, .net, and .org. Under those TLD’s are the third level nameserver provided by the major ISP’s or internet communications companies that manage those TLD’s.

Each level in that hierarchy uses nameservers to track, store, and update the domain names and IP addresses. When your browser wants to visit a new domain that you haven’t visited before, it will send a request to the next highest DNS server in that hierarchy, searching for the domain’s IP address. If your ISP’s nameservers do not find the IP, the request is forwarded up the chain to the next level DNS nameserver until it finds an IP, or if it doesn’t see an IP associated with a domain, the browser will return an error message.

DNS primarily uses port 53 and transmits its inquiries utilizing the User Datagram Protocol (UDP) to serve requests. DNS queries are expressed in a single UDP request from a client followed by a single UDP reply from the server. This transaction happens within milliseconds and is usually transparent to the client.

The next step in the progress of DNS is the move towards “DNS over HTTPS” or DoH. DNS over HTTPS is a new protocol that’s used for processing remote Domain Name System (DNS) lookups via the HTTPS protocol. This method increases the user’s privacy and security by preventing third parties from monitoring and manipulation of the DNS data.

Learn More Today!

DNS can be a difficult topic to master, especially when you have more important decisions and tasks to achieve for your business. Let Liquid Web take care of this responsibility for you! we have Level 3 admins standing by to assist you 24 hours a day, 7 days a week, 365 days a year. We are experts at addressing issues like this and we will own this so you can move forward with your day.

Give us a call today at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Hosting advisors today!

The post DNS: An Overview appeared first on Liquid Web.

If you have a VPS or Dedicated server running cPanel, and your server is also running private nameservers, you will find the Web Host Manager’s (WHM’s) interface very useful when it comes to updating, creating, or removing DNS zone files for your domains.

Log in to your server’s WHM management panel and locate the left navigation bar named DNS Functions.

WHM DNS Functions Described

Add a DNS Zone

Allows you to manually create entirely new DNS zone files. You do not need to create a DNS zone for a new domain account when creating a new account via WHM. The server software will automatically create a new zone file for the domain when you create an account.

Add an A Entry for your Hostname

Creates an A record in the relevant DNS zone file so the hostname of the server can be resolved. Example: If the server’s hostname is host.domain.com, WHM will look for a DNS zone file for domain.com and add a new A record to it pointing at the server’s primary IP address. If there is no domain.com record then the WHM will create an entirely new zone file called host.domain.com.

Delete a DNS Zone

This tool allows you to manually remove DNS zone files stored on the server. Note that is very important that you are careful when using this tool. In most cases, DNS zone files do not need to be deleted manually when you are a terminating a domain account because the WHM will delete it automatically.

Edit DNS Zone

An easy to use graphical user interface for making manual edits to DNS zone files on the server. For more information please see our guide on Updating an A record in cPanel.

Edit MX Entry

Another graphical interface for modifying a domain’s Mail Exchange record (MX record). For more information please see our guide on Changing a Domain’s MX Record.

Edit Zone Templates

Allows editing of the server’s templates that are used when creating a new domain account or creating a new DNS zone file manually. Very rarely do these templates need to be modified.

Enable DKIM/SPF Globally

As of cPanel & WHM version 62, the system provisions SPF and DKIM for new accounts by default. However, the system does not automatically provision these DNS records for existing accounts. When you enable this feature, the system will create SPF and DKIM DNS records for all accounts and domains. If a domain currently possesses an SPF record, the system will append the appropriate IP address from the /var/cpanel/mainip file to the existing record. However, the system will not modify existing DKIM records.

Nameserver Record Report

This feature reports information about the nameservers used by zones on this server. The displayed data updates nightly or when you transfer an account.

Nameserver IPs

This tool gives you access to the IP configuration your server is using for its internal private nameservers. For more information please see our guide on Setting Up Private Nameservers in WHM/cPanel.

Park A Domain

This option “Parks” one domain on top of a different domain. In DNS terminology a simple park means one domain shows another domain’s content. For example, if you owned mydomain.com and mydomain.net you could create a domain account for mydomain.com and then use this tool to park mydomain.net on top of it.

Please note: This is not the same as a “Virtual Park”, which is the cPanel equivalent of Add-on Domains (two or more domains sharing a single domain’s webspace on the server as opposed to having their own unique accounts).

Perform a DNS Cleanup

Checks the server’s primary DNS configuration for duplicate DNS zone file entries and attempts to clean them up by removing all but one.

Reset a DNS Zone

Resets an existing DNS zone file to server defaults using the template system. It is HIGHLY recommended that you use this tool with caution as all modifications made to the domain’s DNS since it was created will be removed.

Set Zone Time To Live (TTL)

This feature modifies the domains Time To Live (or TTL) which specifies how long a resolver remembers the DNS query before the query expires and a new one is set.

Setup/Edit Domain Forwarding

Redirects one domain to another domain. Note that the forwarding domain does not need to be on the local server, but you would still use this tool to set up the incoming redirection.

Synchronize DNS Records

This tool is only used when your server is part of a DNS cluster. DNS clustering is outside the scope of this guide but we will cover it in a future guidepost.

Remember, if you have any questions regarding the use of your WHM’s DNS tools please do not hesitate to contact us using the resources below!

===

Liquid Web’s Heroic Support is always available to assist customers with this or any other issue. If you need our assistance please contact us:
Toll-Free 1.800.580.4985
International 517.322.0434
support@liquidweb.com
https://manage.liquidweb.com/

The post WHM Tutorial: DNS Functions and Tools appeared first on Liquid Web.

Full Cloudflare Website Integration

In this article, we will discuss how to set up our domain in a full Cloudflare configuration. This will allow us to take full advantage of their many DNS features, increased speed, Railgun options, and other amazing features that full domain integration allows. 

It should be noted that these instructions do not require you to interact with your Cloudflare account directly. Liquid Web Support works with Cloudflare via your Manage account interface to implement many of these changes. Unfortunately, support cannot directly access external providers, so any changes that need to be made outside the Manage interface will need to be addressed by you or your team. This being said, we find the benefits of a full Cloudflare domain setup to be well worth the effort of some minor DNS modifications.

Liquid Web Manage Dashboard

Let’s get started. Log in to your Liquid Web manage account at https://manage.liquidweb.com and go the Domain’s navigation menu in the left menu. Once there, click on the Cloudflare tab. 

In the Cloudflare tab, click on the “Add Website” button.

Next, we will enter our domain name in the box at the top and then select the radio button in the bottom section “Make Cloudflare my DNS provider (Full).”

Next, select the plan you would like to use at the bottom and then click “Activate Service.” Shortly, a new domain will appear in your account. You will see this screen once it has completed. 

Now, click “Go to Dashboard” and then we can see the domain, and note its pending status.

This screen will also show you the nameservers that will be assigned to our domain, but these nameservers will vary for different users so the ones you see here may not match the ones you have assigned to you. 

Cloudflare Dashboard

Next, we click the three dots on the right side of our new domain name screen, and then select “Cloudflare Dashboard.”

This will take us to the Cloudflare site where we will need to log in to access our account. Now, we need to locate our domain name and it will still show pending, but we can still click on it. 

Next, we will be taken to a screen where we can complete our nameserver setup, but before we do, we need to click on the DNS Icon as we need to add our DNS records. 

Adding DNS Records

Now, we will need to add all of our DNS records for the domain. This information will vary by domain, but at a minimum, you will need to add an A record that points to your Liquid Web server IP and a www.domain.tld cname record. 

From here, select the zone file to upload and leave the defaults in place.

Next, click upload. You may get an error stating that some records failed to upload, so we need double-check to make sure the records are correct, but most of the information should be imported. Make sure to remove any NS records that are imported by clicking on the X to the right of them and confirming that choice.

Once you have confirmed that all your DNS records look correct, we can remove the proxying option as we do not want interruptions in our service (as will be explained in the SSL section below.) 

Proxy Status

To remove Proxying for your records, click on the Proxied Cloud.

Next, it will turn to DNS Only.

Once these settings are all adjusted to “DNS Only”, we can move on.
Note: when we are at the “DNS Only” setting, no traffic is passing through Cloudflare’s CDN network yet.

Change Nameservers

Now we are ready to change our nameserver information to the ones provided to us by Cloudflare on the overview page. Cloudflare provides clear directions to accomplish this.

We will have to wait until propagation takes place after changing our nameservers for our domain. Tip: A good way to check on the progress of propagation is to review your domain name at https://www.whatsmydns.net/.

Once the propagation of your new nameserver has taken place, we should verify that our site loads correctly. At this point, our DNS is running through the Cloudflare service, but the other DNS records like MX, cname and other records should still be pointing at your server.

SSL Setup

Next, let’s take a look at our SSL setup. In the Cloudflare main menu, click on the SSL/TLS icon.

We can now select any of the four options available here with “Flexible” being the most lenient if you want SSL support, Full, or Full (Strict) being most stringent, as it indicates. Generally, Full is a good option here, or if needed, Flexible will work also. If there are issues with Flexible, we can switch back over to Full. 

Cloudflare will issue a universal SSL to cover our domains, but sometimes, this can take time after we change our nameserver information. We want to try to avoid proxying our traffic until we confirm that the universal certificate has been issued as we may see insecure warnings if it has not been completed. To confirm this change, click on the “Edge Certificates” tab under the SSL/TLS button.

The first box is Edge Certificates, and in this area, we want to see a certificate present for our domain. If we do not see this certificate, we will have to wait until we do see the certificate to enable proxying.

When there is a certificate in place, it will look like this.

Enable DNS

Once we see that certificate in place, (which might take a little while) we are now ready to proxy traffic through Cloudflare, so you get all the benefits of the service. Let’s finish these final few settings. In your Cloudflare account go back to the DNS tab

and click on the “DNS only” clouds

to toggle them back to “Proxied.”

Success! 

Now we have set up our site to run on Cloudflare and have our traffic proxied through them.

Bonus

Cloudflare has some other great features as well. There are two which stand out that we should consider employing. The first of which is Railgun.  

Railgun

The Railgun service helps cache content and improves the overall speed of our site. We also provide this service as part of the Liquid Web Cloudflare plan. If you do not have our Cloudflare service, the cost to utilize this service would be close to $200/month for a similar plan from Cloudflare. Enabling this service is very easy. Simply log in to your Cloudflare account in manage and click on the Speed Button, 

then the Optimization tab, 

and then scroll down to the Railgun heading. Here we will see the Liquid Web Central and Liquid Web Staging areas. For this selection, we are only concerned with the Liquid Web Central Option.

To enable it, toggle the off button to the on position,

Then click the Test button. We will want to ensure we see a Success message after the test runs.

Now, let’s check our site to ensure it is working as expected. In rare cases, there could be issues with Railgun, but generally, enabling this service will make your website faster. That’s it! Railgun is enabled.

BOT Fight Mode

This feature helps to stop malicious bots from weighing your server down and is an excellent option to stop most of them. To enable this setting in your Cloudflare account, go to the Firewall button

and then click the settings tab on the right. 

You will see the Bot Fight Mode box, which needs to be toggled to the on position. Now we are fighting back against the malicious bots.

Try It Now!

Utilizing Cloudflare is an excellent way to optimize any site in multiple ways. Would you like to give it a try?

Give us a call at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable system administrators or Experienced Linux technicians to learn how you can take advantage of this system today!

The post How To Setup A Domain In Cloudflare appeared first on Liquid Web.

What is DNS and Why is it Important?  

Simply put, DNS (the Domain Name System) converts text-based, human-readable domain names like www.liquidweb.com into an IP (Internet Protocol) address like 172.154.75.42. This system also works in an inverse manner and converts IP addresses into domain names. When internet-connected devices communicate, IPs are utilized to find and connect to a specified destination. This simply means that the DNS protocol acts as an “internet phone book” of sorts that translates the text-based domain name you enter in your favorite browser into that device ready IP. Because of the limited availability of IPv4 IP addresses, keeping all the internet-ready devices connected becomes even more challenging. This has caused the rise and proliferation of IPv6 addresses. These IP addresses, which look like “2a03:2880:f127:283:face:b00c:0:25de” are continuing to be more widely used.

So, whenever you (or a customer of yours) opens a website, downloads a favorite recipe, or clicks on a link to your favorite sports highlight, DNS can be used multiple times within that single click, as most modern websites now have additional external domains linked within a page. Having a highly stable and durable DNS system becomes critical for customers as it is used for every click and every query.

Introducing the New Liquid Web Global DNS System

Liquid Web is consistently improving our customer’s experience by providing increased reliability and enhanced performance. In the spirit of that continuous improvement, we have accomplished the placement of additional Anycast DNS servers around the world. These servers are strategically positioned globally so that they provide a local DNS server option for our clients which significantly reduces first-visit load time of a website. The first-visit load time metric is critical as this significantly improved websites SEO score and is a top indicator whether a customer will stay on a website or not.

What is Anycast?

Anycast is a “one to many” method of network routing and addressing in which an inbound request can be routed to different servers or locations. Routers select the ideal path of an inbound request based on the distance, latency measurements, number of hops, lowest cost, or on the least crowded route

Why A Global Approach is Better

Liquid Web now has DNS service available on a global Anycast network which provides significant benefits for DNS queries. Our Anycast resolvers provide a notable speed boost by allowing a customer’s browser to make requests to the nearest (or least latent) nameserver available. This global approach also alleviates the problem of a slow localized DNS server which may cause lag prior to the initial website load.  

This solves additional issues related to down servers which may deny a client the ability to access any sites at all. Having multiple locations that can route traffic at all times increases the availability and reliability of the requests placed.  

Using this globally distributed approach, Liquid Web broadcasts the IP addresses of our DNS servers from these universal locations simultaneously. When a visitor loads your website, this technology allows their internet service provider (ISP) to route the visitor’s DNS requests to the closest Liquid Web Global DNS server (with the least number of hops and lowest latency) to that visitor.

Increased Performance

The following is a real-world example of our Liquid Web Global DNS network in action. Using a tool provided by KeyCDN.com, we tested the latency (round trip time) from 14 locations around the globe, then compared our latency models from Nov. 2019 to Jan. 2020. In reviewing these latency differences, the sub millisecond latency times are incredible! These results demonstrate our commitment to improving performance and reliability for our customers.

Example DNS Resolution times

Global DNS Server Locations

Here the current locations of the Anycast servers worldwide.

• Amsterdam
• Atlanta
• Chicago
• Dallas
• Frankfurt
• London (2)
• Los Angeles
• Miami
• New York (2)
• Paris
• San Francisco
• Seattle
• Singapore
• Sydney
• Tokyo
• Toronto

What’s Next?

Here at Liquid Web, we consistently strive to provide better, more reliable, and faster performance for all of our customers. We will continue to investigate additional ways to add new Global DNS locations in the near future. We are always on the lookout for new opportunities to better assist our customers by improving the experience for you and your website visitors.

Conclusion

If you are interested in learning more about this technology, simply reach out to one of our knowledgeable Solutions Team or Systems Administrators at 800-580-4985, or you can open a chat or ticket with us 27/7/365 for more information!

The post Liquid Web Global DNS appeared first on Liquid Web.

Reading Time: < 1 minuteLiquid Web’s Content Delivery Network is a fantastic way to get elements of your site to your global customers in a timely manner. As part of the set up process, you may need to add a Canonical Name (CNAME) record to your domain’s DNS.

If we manage your nameservers, or if your DNS is hosted on our nameservers, our Heroic Support technicians will take care of this step. If not, as part of the CDN set up process you will need to add the following line to your domain’s zone file:

cdn.domain.com. 300 IN CNAME sourcecdn.edgesuite.net.

Substitute your domain for “domain.com” in the above example. Also make sure you follow any other necessary steps your DNS provider might require for updates to your zone file.

Why Do I Need a CNAME For My CDN?

The CNAME entry points any references to cdn.domain.com in your site code to the Content Delivery Network. For most content management system CDN plugins, simply putting the cdn.domain.com in the plugin configuration will allow site assets to be downloaded from locations across the globe.

===

Liquid Web’s Heroic Support is always available to assist customers with this or any other issue. If you need our assistance please contact us:
Toll Free 1.800.580.4985
International 517.322.0434
support@liquidweb.com
https://manage.liquidweb.com/

The post On CNAMEs and CDNs appeared first on Liquid Web.