In Part 1 of this four part series, we discussed establishing your VPC, creating and configuring your small subnet, and worked through configuring the Security Groups for our two instance types (‘NS_SG‘ and ‘VS_SG‘).
Today, we work on launching a two new instances, running cPanel DNSONLY, into our VPC and configuring these to be the primary and secondary DNS resolvers for our environment. While this series is written with the assumption of using dedicated DNS instances, you could easily use these instructions on dual use instances that both serve as web servers and as name servers.
Below is a quick overview of the architecture implemented as well as instance types used for provisioning instances. While I can not link directly to specific AMIs (Amazon Machine Images), selecting your desired operating system and getting cPanel/WHM installed is a straightforward procedure.
- First, I will discuss the reasons for configuring instances in certain ways as they relate to being on AWS, but this is not a lesson in DNS basics. You will need to have a working knowledge of DNS best practices.
- Second, this model makes no assumption of complete configuration or security. Again, I will just be touching on the subtleties of using the AWS eco-system.
Some instructions below are borrowed from Amazon’s AWS User Guide.
This Lesson Includes
- Creating and launching a new EC2 Instance (Name Server) within VPC
- Applying a Security Group to an Instance
- Configuring cPanel DNSONLY for AWS
- Creating a DNS Cluster
Create and Launching the Name Server Instance
Amazon EC2 instances are the fundamental building blocks for your computing needs in AWS. You can think of instances as virtual servers that can run applications and services. Instances are created from an Amazon Machine Image (AMI) and choosing an appropriate instance type. An AMI is a template that contains a software configuration, including an operating system, which defines your operating environment. You can select an AMI provided by AWS, our user community, or on the AWS Marketplace. You can also create and optionally share your own AMIs. A single AMI can be used to launch one or thousands of instances
There are thousands of freely (and commercially) available AMIs available to choose from. You can also opt for building your own from the ground up. In my case, I chose a vanilla CentOS 6 AMI and built my name servers from there.
An important aspect to understand about the AWS eco-system is a term called “Regions“. Regions are just that, geographical locations of the datacenters that house your services in AWS. Amazon offers numerous regions all at different price points. I generally build out an infrastructure in a single region and then duplicate the infrastructure to a separate region. I then can use AWS ELB (Elastic Load Balancing) to direct traffic to different regions or for failover. In this tutorial I will be operating in the N. Virginia (East 1-A) region. More on regions can be found here.
While I will walk you through launching your instance, I will skip the installation step for cPanel Services merely for brevity. Let’s begin.
Choose an AMI
- Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/
- Click “Launch Instance” in the top menu.
- Click the “Classic Wizard” radio and click “Continue“.
- Choose one of the four tabs to search for your desired AMI. Keep in mind, AMIs are region specific so when launching a new AMI ensure it is in the same region as your VPC.
- Select the “Instance Type: T1 Micro“. A T1 Micro Instance is sufficient for a basic name server. (More on Instance Types).
- Select the “Launch into: EC2-VPC” radio button.
- Accept the default subnet since we only have one (unless more were configured, select accordingly).
- Click “Continue“.
- Kernel ID and RAM Disk ID can both be kept as “Use Default“.
- While an additional charge will be incurred, it may be advantageous for you to enable CloudWatch Monitoring. I choose to enable it.
- Important: Make sure you enable Termination Protection by checking the box labeled “Prevent against accidental termination.” This helps prevent you from deleting an instance or volume store without you first disabling this protection.
- Also Important: Ensure “Shutdown Behavior” is set to “Stop” and not “Terminate”. When an instance is terminated, it is deleted from your VPC/EC2 account and is not recoverable.
- Now we want to set a Static Private IP for our instance. VPC comes built in with a DHCP server but we really don’t want our instance IPs to be changing. Set an appropriate IP address for your instance. I chose “10.0.0.10” based on my subnet range.
- Click “Continue“.
Understanding AWS storage can be somewhat overwhelming but it is really quite simple. AWS uses two primary storage types. “EBS” and “Instance Store“. In all practical instances, you will want to use EBS. The differences are simple really.
EBS Storage is physically separate storage that is backed by Amazon S3 and is independent of your instance. EBS volumes can be attached/detached to Instances much like plugging in a thumb drive. You can also take snapshots of EBS volumes making backups/recovery simple. EBS storage is a safer option because if a region goes offline or fails completely, the likely hood of recovery of your EBS backed volumes are significantly greater than Instance Stores because of the physical location separation. When you terminate (delete) an instance, unless you say otherwise, the EBS volume associated with that instance will still be available. EBS volumes can also be resized and scaled. More on this later.
Instance Store is a storage volume type that is tied directly to an instance. Instance stores cannot be managed and cannot have snapshots taken. Instance stores are also not persistent, meaning, if you boot an instance, make changes to the volume (create/delete files, etc) and then stop the instance, the next time you boot the instance, any changes made will not be available. The instance essentially resets to a fresh state every time you boot. Instance stores are useful in an application specific environment where a particular instance has one job to do.
Important: When selecting an AMI, ensure that the Storage Type indicates “EBS-Backed“ if that is the storage type you want to select.
- Accept the defaults of your selected AMI and click “Continue“.
Naming convention is entirely up to you, however, I recommend using a standard naming schema throughout your VPC. This makes for easier maintenance and management. I generally set the “Name” key to the hostname of the instance, and create an additional key “Type” and set it to the function of the instance, in this case NS (Name Server).
Public/private key pairs allow you to securely connect to your instance after it launches. For Windows Server instances, a Key Pair is required to set and deliver a secure encrypted password. For Linux server instances, a key pair allows you to SSH into your instance.
To create a key pair, enter a name and click “Create & Download Your Key Pair”. You will be prompted to save the private key to your computer. Note: You only need to generate a key pair once – not each time you want to deploy an Amazon EC2 instance.
- Select the “NS_SG” Security Group that we created in Part 1.
- Click “Continue“.
- Review and verify the Instance details.
- Click “Launch“.
Allocating and Associate an Elastic IP
Elastic IP addresses are static IP addresses designed for dynamic cloud computing. An Elastic IP address is associated with your account, not a particular instance (but can be associated to an instance), and you control that address until you choose to explicitly release it. Unlike traditional static IP addresses, however, Elastic IP addresses allow you to mask instance or availability zone failures by programmatically remapping your public IP addresses to any instance associated with your account. Rather than waiting on a data technician to reconfigure or replace your host, or waiting for DNS to propagate to all of your customers, Amazon EC2 enables you to engineer around problems with your instance or software by programmatically remapping your Elastic IP address to a replacement instance.
- Open the Amazon VPC console at https://console.aws.amazon.com/vpc/
- Click “Elastic IPs“ in the left hand navigation menu.
- Click the “Allocate New Address” button in the header menu.
- Set “EIP Used In:” to “VPC“. (Elastic IPs allocated outside of a VPC to EC2 cannot see VPC Instances).
- Click “Yes Allocate“.
- Open the Amazon VPC console at https://console.aws.amazon.com/vpc/
- Click “Elastic IPs” in the left hand navigation menu.
- Locate your newly allocated IP Address in the list and click the selection box (or right click) associated with the address.
- With the address selected, click the “Associate Address” button in the header menu.
- Select your new Instance from the “Instance” dropdown and the correct Private IP should be selected by default.
- Important: Ensure that you enable “Allow Reassociation“. This tells the VPC to reassign this EIP to this instance in the event of a reboot or shutdown. If you do not enable this option, you will have to manually re-associate the EIP with the Instance.
- Click “Yes, Associate“.
Configuring cPanel DNSONLY
At this point, you have a brand new Instance with an Elastic IP associated to it. The first thing you want to do is login to your instance via SSH using your newly acquired KeyPair. As I said previously, I won’t be going over the steps for installing cPanel, although they are straightforward.
Pre-configured AMIs will always have a root password set which you will inherently have to change to be able to login to cPanel. This is a quick, yet necessary step to complete before continuing.
SSH into your instance as root and run:
Modify your password and continue.
- Assuming you have installed cPanel DNSONLY, In a web browser, navigate to:
Where <elastic-ip> is replaced by the Elastic IP Associated to your new instance.
- You will be prompted for login credentials. Username will be ‘root’ and the password will be your new modified password.
- ‘Read’ and Agree to the Terms and Conditions and continue to Step 2.
- Enter your Contact Information.
- Enter the hostname of this instance. In my case, I chose “ns1.example.com“.
- Enter your primary and secondary resolvers. I choose to use Google’s Resolvers located at “126.96.36.199” and “188.8.131.52” respectively.
- Ensure Main Network Device is set appropriately. It will most often be eth0.
- Save and Go To Step 3.
11.36 Temporary Workaround
At the time of writing this, cPanel DNSONLY Stable Release is at 11.36, meaning it does not yet officially support a NAT, however I can say with confidence that by the time WHM 11.40 is released DNSONLY will be on par with NAT support.
The following instructions are unique to 11.36 and DNSONLY because it does not yet officially support NAT, these should be considered a temporary work-around until 11.40 arrives at which I will update the instructions.
- In Step 3, add a new IP address by entering in the Elastic IP of the instance you are working with. Subnet should remain default.
- Click “Add IP(s)“.
- Click “Finish“
You should now be directed to the DNSONLY Dashboard. Again, due to this being a non-NAT build, we need to workaround for the time being. We need to modify the Main IP within cPanel from our Private IP to our Elastic IP.
- In the left hand menu, click “Basic cPanel & WHM Setup“.
- Locate the first field under “Basic Config” that contains what probably looks like a random 10.x.x.x IP. Replace the existing IP with your Elastic IP.
- Click “Save Changes“.
A DNS cluster is a group of nameservers that share records. A DNS cluster allows you to physically separate your nameservers so that if a web server loses its connection, you still have DNS functionality. This will allow visitors to reach websites on your server more quickly after the web server comes back online.
- In the left hand menu, under Cluster/Remote Access, click “Configure Cluster“.
- In the Modify Cluster Status box, select “Enable DNS Clustering”.
- Click “Change”.
- Click “Return to Cluster Status”.
At this point you have a single nameserver, ns1.example.com, configured and with DNS Clustering enabled. This server is ready to Pair/Synchronize with WHM/cPanel client servers.
You do, however, need to repeat these steps for a secondary nameserver, presumably ns2.example.com.
While this is a very basic setup, all of the possibilities of this infrastructure within AWS are too numerous and out of scope for this tutorial. I am more than happy to field questions and comments below if you have a more challenging project.
Already using Amazon Web Services? Check out the cPanel & WHM listing in the AWS Marketplace and start building your own cPanel hosting environment.