Before starting to do so, one should consider whether it is worthwhile setting up your own Authoritative Domain Server. Most registrars, the outfit you rent your domain name from, will allow you for no extra charge to set up everything you need for forward DNS. I set up my own "authoritative domain name server" under what I now believe to be the mistaken notion that I also could then control my rDNS, reverse DNS, which would be helpful for ensuring reliable mail delivery from your email server.
With regard to rDNS, there are some in the post-modern world who believe that the computing world would be better if it were dominated by large multi-national corporations and organizations. Some of these people are trying to convince the world that only corporations that can afford tens of thousands of dollars to buy their own IP addresses should be allowed to run email servers. As summarized here, when you purchase a domain name from a domain name registrar, you receive not only authorization to use the domain name, but also authority over its domain space. Effectively this means that YOU control which ip address is reported when someone does a dns lookup of your domain. In contrast, when you you contract with an Internet Service Provider (ISP) to provide you with Internet service, THEY assign you an IP address. If you are willing to pay an additional small fee, they will assign you a so-called fixed IP address, which will be the same every time you connect. However, THEY do not assign to you the authority to control what that IP address points to.
Although there is not a single RFP standard that demands it, there are some servers that refuse, in violation of existing RFPs, to forward email from servers whose forward and reverse DNS lookups are not symmetric. They demand that the domain name for your server point to your IP (which you can control through your registrar or self-run nameserver) AND that so-called reverse-DNS lookup of your IP address (which your ISP controls) points back to the domainname of your server.
There are scattered Internet reports of ISPs being willing to do this for a customer wanting to run a server, but I believe this is exceeeding rare. I, myself, have been unable to find an ISP willing to do this, with the majority of people I speak to at my ISP, never having heard of reverse DNS.
I have not found the problem of rDNS symmetry to be a serious impediment to runing my own low-volume email server, which I have been running with two different fixed-IPs issued by two different ISPs between 2022 and 2025. The servers of really large corporations like ATT and Bezeq International, and even some of the blacklisting organizations, generally have mitigation procedures for servers blacklisted but not actually sending out spam.
Authoritative Domain Name Servers are much harder to set up and configure than webservers. We need to create two servers, a master server and a slave server, and they both must have different fixed IPs.
Most of what I report here is based upon these two very clear and informative articles.
You have to construct or configure three files on each server; the order in which you do this is unimportant. On both the computer with the master name server and that with the slave nameserver, the first step on a Debian-based operating system is to install the bind9 program by issuing the command
sudo apt install bind9
Then enter the newly created /etc/bind directory by issuing the command "cd /etc/bind" without the quotes, and there edit or compose your three files. The first step is to copy named.conf.local to named.conf.local.ori before you then modify the original.
The named.conf.local file on the computer serving as the master should be modified with a text editor to look as below:
//
// Do any local configuration here
// Forward zone
zone "domain.tld" {
allow-update { none; };
type master;
file "/etc/bind/db.domain.tld";
allow-transfer { SLAVES_IP; };
};
// Reverse zone
// zone "31.244.81.in-addr.arpa" {
// type master;
// file "/etc/bind/db.REVIP.in-addr.arpa";
// allow-transfer { SLAVES_IP; };
// };
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
//logging {
// channel query.log {
// file "/var/log/query.log";
// Set the severity to dynamic to see all the debug messages.
// severity dynamic;
// };
//};
where REVIP is the first three octets of the domain name's IP in reverse order separated by periods. In other words, if the domain's IP is A.B.C.D, the file name is db.C.B.A.in-addr.arpa.
This is a work in progress. I will update, correct, and finish it once everything has has been shown to work.