The general expression, "domain name service", refers to two types of service: forward name service (abbreviated DNS); and reverse name service (abbreviated rDNS). A single instance of a server program such as bind9, if configured properly, can handle both at the same time. Forward name service requires properly-written A, AAAA, C, MX, and TXT records, etc, and reverse name service requires a properly-written PTR record. When you are talking about authoritative name servers, the situation is a little more complicated, because of the issue of "Delegation of Authority".
When you rent your domain name from a registrar, every registrar I know of will give you nearly complete authority as well as much help in managing where your domain points (usuallly to an IP address or another domain name). They even will let you run your own nameservers and will assist by telling the "Authorities" that the nameservers for your domainname are not their's (ns1.registar.com, ns2.registrar.com, etc), but yours, ns1.mychosendomain.tld and ns2.mychosendomain.tld, etc.
There is an important consideration with rDNS. When you rent a fixed IP, which each of your domain name servers requires, the "Delegation of Authority" to control where each points resides with your ISP. There are scattered reports on the Internet of users getting their ISPs to point their fixed IP to the user's domainname. I have tried with three different ISPs and failed to persuade any of them to point my fixed IP to the domainname I was renting from my registar. This sounds like a minor inconvenience, and for most of the years I have run my own mail servers, it has been. But, as discussed below, lately it has become a bigger problem.
Some in the post-modern world 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. In accordance with this thinking, although there is not a single RFP standard that demands it, and several that forbid it, there are some servers that refuse to forward email from servers whose forward and reverse DNS lookups are not symmetric. They demand that the domainname of your server point to your IP (which you can control through your registrar or self-run nameserver) AND that rDNS lookup of your IP address (which your ISP controls) points back to the domainname of your server.
The problem of rDNS symmetry was not a serious impediment to running my own low-volume email server between 2022 and 2024. 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. Starting in 2025, the ideas of the post-modernists started gaining traction, despite lack of evidence regarding their effectiveness.
To set up Authoritative Domain Name Servers we need to create two servers, a master server and a slave server, and they both must have different fixed IPs. I succeeded setting up my own authoritative name servers by following these two very clear and informative articles.
Using Linux Mint 22.2 OS, you have to construct or configure no more than 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 is to install the bind9 program by issuing the command "sudo apt install bind9" without the double quotes.
Then enter the newly created /etc/bind directory by issuing the command "cd /etc/bind" without the quotes, and there edit or compose your files. The first step is to copy named.conf.local to named.conf.local.ori as a backup before you 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 { SLAVE_IP; };
};
// Reverse zone
// zone "C.B.A.in-addr.arpa" {
// type master;
// file "/etc/bind/reverse.db";
// allow-transfer { SLAVE_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 reverse zone address is C.B.A.in-addr.arpa.
While on the computer with the master name server create database files for the forward and reverse zones.
The forward data file should look like this:
; ; BIND data file for local loopback (forward) interface ; $TTL 604800 @ IN SOA domain.tld. contact_person.domain.tld. ( 2025120502 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ;Name server entries @ IN NS ns1.domain.tld. @ IN NS ns2.domain.tld. ;A records for name servers ns1 IN A MASTER_IP ns2 IN A SLAVE_IP ;Other A records similar to those stored at my registrar @ IN A DOMAIN_IP mail IN A DOMAIN_IP smtp IN A DOMAIN_IP @ IN MX 10 mail.domain.tld. @ IN MX 10 smtp.domain.tld. @ IN TXT "v=spf1 ip4:DOMAIN_IP ~all"
Even though, as we explained, it will have no effect since we don't have Designation of Authority for managing the domain IP, the correct format for the reverse data file on the master domain name server is this:
; ; BIND data file for local rDNS ; $TTL 604800 @ IN SOA ns1.registrar.com. contact_person.domain.tld. ( 2025120502 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ;Name server entries @ IN NS ns1.domain.tld. @ IN NS ns2.domain.tld. ; ;A records for name servers ns1 IN A MASTER_IP ns2 IN A SLAVE_IP ; ;PTR record D IN PTR domain.tld.
The value of D in the PTR record is the same as that in the domain name's IP as defined above.
Now we just have to configure the named.conf.local on the slave name server. As with the master, don't forget to backup the original.
The named.conf.local file on the slave domain server should look as follows:
//
// Do any local configuration here for slave
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "domain.tld" {
type slave;
file "/var/cache/bind/forward.db";
allow-query { any; };
masters { MASTER_IP; };
};
zone "C.B.A.in-addr.arpa" {
type slave;
file "/var/cache/bind/reverse.db";
allow-query { any; };
masters { MASTER_IP; } ;
};
C, B, and A in the zone definition again are from the domain name IP as defined above.
There are many things we have not explained. You easily can find these from the two references given above or elsewhere on the Internet. Just one thing we will caution about. Some of the values given above have a terminal period and some do not. This is not capricious. It is vitally important. Any deviation from the above will lead to the name server not functioning correctly, probably not at all. Also don't forget the terminating semicolons in the config files.
We started the project of setting up our own authoritative domain name servers in order to make our DNS and rDNS symmetric. As outlined above, we succeeded in setting up a name server for our domain and having it recognized as the authroitative one, but never succeeded in getting our DNS and rDNS symmetric. Since every regisrar we used accomplished the same, we conclude that there is no advantage to running your own authoritative name servers, even though we currently do so.
An interesting aside, for which we have no explanation, is that as part of the process of setting up a second name server, we started renting a new fixed IP address from an ISP we had not previously used. As with the other ISPs we had tried, we were not able to persuade them to point the rDNS to our domain. We did however note that this particular fixed IP was on fewer blacklists than others we had used. We therefore pointed our domainname to this IP and hoped for the best. Since doing this in the last month of 2025, we have not a single email that was returned as undeliverable. You can check the "Last updated" date on this page to decide for yourself how significant you think this is. One last share of information that may or may not be relevant is that we comply with the SPF specification, but not DKIM or DMARC.