PowerDNS (pdns) is an open source authoritative DNS server that works as an alternative to traditional BIND (named) DNS. PowerDNS offers better performance and has minimal memory requirements. PowerDNS also works with many supporting backends ranging from simple zone files to complex database setups as well as various SQL platforms (Mysql, MariaDB, Oracle, PostgreSQL). Continue reading “What is Power DNS?”
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.
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.
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:
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.
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.
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:
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:
The below settings are important for key-only authentication and set by default. Be sure to double check to configure as shown:
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.
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:
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 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 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
- Allow “full” access to Apache on port 80 and 443:
ufw allow "Apache Full"
Rule added (v6)
- Allow SSH access:
ufw allow "OpenSSH"
Rule added (v6)
- View the detailed status of UFW:
ufw status verbose
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.
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.
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.
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.
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 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.
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 “184.108.40.206” would be “220.127.116.11.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:
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 18.104.22.168
;<<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -x 22.214.171.124
;; 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:
;126.96.36.199.in-addr.arpa. IN PTR
;; ANSWER SECTION:
188.8.131.52.in-addr.arpa. 21599 IN PTR google-public-dns-a.google.com.
;; Query time: 19 msec
;; SERVER: 184.108.40.206#53(220.127.116.11)
;; 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 18.104.22.168 back to the Google subdomain, google-public-dns-a.google.com :
22.214.171.124.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:
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.