What is Power DNS?

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

Note
PowerDNS uses a separate program called PowerDNS Recursor (pdns_recursor) as the “resolving DNS server” as a standalone software package.

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.

Available tools and features with Poweradmin

 

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

Search for tools in Poweradmin

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

Adding a Master Zone in Poweradmin

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

adding a secondary zone in poweradmin

Getting Started with Ubuntu 16.04 LTS

A few configuration changes are needed as part of the basic setup with a new Ubuntu 16.04 LTS server. This article will provide a comprehensive list of those basic configurations and help to improve the security and usability of your server while creating a solid foundation to build on.

Root Login

First, we need to get logged into the server. To log in, you will need the Ubuntu server’s public IP address and the password for the “root” user account. If you are new to server administration, you may want to check out our SSH tutorial.
Start by logging in as the root user with the command below (be sure to enter your server’s public IP address):
ssh root@server_ipEnter the root password mentioned earlier and hit “Enter.” You may be prompted to change the root password upon first logging in.

 

Root User

The root user is the default administrative user within a Linux(Ubuntu) environment that has extensive privileges. Regular use of the root user account is discouraged as part of the power inherent within the root account is its ability to make very adverse changes. The control of this user can lead to many different issues, even if those changes made are by accident.
The solution is to set up an alternative user account with reduced privileges and make it a “superuser.”

 

Create a New User

Once you are logged in as root, we need to add a new user account to the server. Use the below example to create a new user on the server. Replace “test1” with a username that you like:

adduser test1

You will be asked a few questions, starting with the account password.
Be sure to enter a strong password and fill in any of the additional information. This information is optional, and you can just hit ENTER in any field you wish to skip.

 

Root Privileges

We should now have a new user account with regular account privileges. That said, there may be a time when we need to perform administrative level tasks.
Rather than continuously switching back and forth with the root account, we can set up what is called a “superuser” or root privileges for a regular account. Granting a regular user administrative rights will allow this user to run commands with administrative(root) privileges by putting the word “sudo” before each command.
To give these privileges to the new user, we need to add the new user to the sudo group. On Ubuntu 16.04, users that belong to the sudo group are allowed to use the sudo command by default.
While logged in as root, run the below command to add the newly created user to the sudo group:

usermod -aG sudo test1

That user can now run commands with superuser privileges using the sudo command!

 

Public Key Authentication

Next, we recommend that you set up public key authentication for the new user. Setting up a public key will configure the server to require a private SSH key when you try to log in, adding another layer of security to the server. To setup Public Key Authentication, please follow the steps outlined in our “Using-SSH-Keys” article.

 

Disable Password Authentication

Following the steps outlined in the previously mentioned “Using-SSH-Keys” article, results in the new user ability to use the SSH key to log in. Once you have confirmed the SSH Key is working, we can proceed with disabling password-only authentication to increase the server’s security even further. Doing so will restrict SSH access to your server to public key authentication only, reducing entry to your Ubuntu server via the keys installed on your computer.

Note
You should only disable password authentication if you successfully installed and tested the public key as recommended. Otherwise, you have the potential of being locked out of your server.

To disable password authentication on the server, start with the sshd configuration file. Log into the server as root and make a backup of the sshd_config file:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Now open the SSH daemon configuration using nano:

nano /etc/ssh/sshd_config

Find the line for “PasswordAuthentication” and delete the preceding “#” to uncomment the line. Change its value from “yes” to “no” so that it looks like this:

PasswordAuthentication no

The below settings are important for key-only authentication and set by default. Be sure to double check to configure as shown:

PubkeyAuthentication yes
ChallengeResponseAuthentication no

Once done, save and close the file with CTRL-X, then Y, then ENTER.

We need to reload/restart the SSH daemon to recognize the changes with the below command:

systemctl reload sshd

Password authentication is now disabled, and access restricted to SSH key authentication.

Set Up a Basic Firewall

The default firewall management on Ubuntu is iptables. Iptables offers powerful functionality. However, it has a complex syntax that can be confusing for a lot of users. A more user-friendly language can make managing your firewall much easier.
Enter Uncomplicated Firewall (UFW); the recommended alternative to iptables for managing firewall rules on Ubuntu 16.04. Most standard Ubuntu installations are built with UFW by default. A few simple commands can install where UFW is not present.

 

Install UFW

Before performing any new install, it is always best practice to run a package update; you’ll need root SSH access to the server. Updating helps to ensure that the latest version of the software package. Use the below commands to update the server packages and then we can proceed with the UFW install:

apt update

apt upgrade

With the packages updates, it’s time for us to install UFW:
apt install ufwOnce the above command completes, you can confirm the UFW install with a simple version command:
ufw --version

UFW is essentially a wrapper for iptables and netfilters, so there is no need to enable or restart the service with systemd. Though UFW is installed, it is not “ON” by default. The firewall still needs to be enabled with the below command:

ufw enable

Note
Recreating any pre-existing iptables rules is necessary for UFW. It is best to set up the basic firewall rules then enable UFW to ensure you are not accidentally locked out while working via SSH.

 

Using UFW

UFW is easy to learn! Various programs can provide support for UFW in the form of app profiles which are pretty straightforward. Using the app profiles, you can allow or deny access for specific applications. Below are a few examples of how to view and manage these profiles:

  • List all the profiles provided by currently installed packages:

ufw app list

Available applications:
Apache
Apache Full
Apache Secure
OpenSSH

  • Allow “full” access to Apache on port 80 and 443:

ufw allow "Apache Full"

Rule added
Rule added (v6)

  • Allow SSH access:

ufw allow "OpenSSH"

Rule added
Rule added (v6)

  • View the detailed status of UFW:

ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action From
--                         ------ ----
22/tcp (OpenSSH)           ALLOW IN Anywhere           
22/tcp (OpenSSH (v6))      ALLOW IN Anywhere (v6)

As you can see, the App profiles feature in UFW makes it easy to manage services in your firewall. Newer servers will not have many profiles to start with. As you continue to install more applications, any that support UFW are included in the list of profiles shown when you run the ufw app list command.

If you have completed all of the configurations outlined above, you now have a solid foundation to start installing any other software you need on your new Ubuntu 16.04 server.

 

DNS Zones Explained

DNS Zones

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

 

DNS Zone Files

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

 

Types of Records

 

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

Start of Authority (SOA)

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

Name Server (NS)

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

 

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

Mail Exchange (MX)

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

Address (A)

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

 

AAAA

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

Canonical Name (CNAME)

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

 

Alias Record (ALIAS)

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

Text (TXT)

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

 

Service Locator (SRV)

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

Pointer (PTR)

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

Reverse DNS Lookup

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

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

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

 

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

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

 

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

 

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

https://mxtoolbox.com/ReverseLookup.aspx

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

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

 

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

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

dig -x 8.8.8.8

 

Output:

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

 

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

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

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

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

 

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