Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Reverse DNS

Section 1: What is Reverse DNS

Reverse DNS (Domain Name System) is an integral part of the Internet infrastructure and plays a crucial role in translating IP addresses into domain names. While most users are familiar with forward DNS, which maps domain names to IP addresses, reverse DNS performs the opposite task, allowing users to identify the domains and hostnames associated with particular IP addresses.

Reverse DNS is a query and response-based service such that when an IP address is used to access a website or send an email, reverse DNS can be employed to determine the associated domain.

Section 2: Reverse DNS Delegation

2.1 Reverse DNS Delegation

Reverse DNS (Domain Name System) operates through a hierarchical tree of servers, similar to forward DNS. The Address and Routing Parameter Area (ARPA) top-level Internet domain serves as the root of the reverse DNS structure. The delegation process involves the ARPA root, the Regional Internet Registries (RIRs), delegated servers, and PTR records.

Regional Internet Registries, such as AFRINIC, manage the reverse delegation process for their respective regions. Understanding the hierarchical structure and delegation process of reverse DNS is essential for maintaining proper configuration and ensuring efficient IP address lookups in the Internet ecosystem. 

Hierarchy of Reverse DNS

The ARPA root serves as the highest level in the reverse DNS hierarchy. Below the ARPA root, delegated servers handle specific IP address ranges. For IPv4 addresses, the "in-addr.arpa" domain is used, while "ip6.arpa" is utilized for IPv6 addresses. Further down the hierarchy, there are delegations for the /8 IPv4 and IPv6 blocks allocated by the Internet Assigned Numbers Authority (IANA) to the RIRs.
Image

PTR Records and Zone Files

PTR records, containing the reverse mapping of IP addresses to domain names, are stored in the zone files specific to each reverse domain. These zone files are maintained by Name Servers. To create a PTR record, the IP address octets are reversed and appended with the ".in-addr.arpa" extension. For instance, if a server has the IP address 196.0.1.2, the corresponding PTR record will be registered as 2.1.0.192.in-addr.arpa.

AFRINIC Reverse Delegation Process

AFRINIC DNS servers provide referrals for the IP resources delegated to its resource members.

To request reverse delegation, resource holders need to create a domain object in the AFRINIC WHOIS Database. Members must also configure reverse DNS zones on their name servers in advance, as AFRINIC servers will perform verification to ensure proper configurations are already in place. It is recommended to have at least two name servers for redundancy purposes. If the name servers are correctly configured, AFRINIC propagates the delegation to the Domain Name System. However, if a DNS server is not properly configured, it will be detected as a lame DNS server, and the delegation request may be dropped unless the issue is resolved promptly.

2.2 Reverse DNS Usage

Reverse DNS finds numerous applications in email management, network administration, security and troubleshooting. Some notable use cases include:
  1. Email Authentication: Reverse DNS is an essential component of email authentication mechanisms such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Verifying that the IP address used for sending emails matches the domain specified in the sender's address helps combat email spam and improve deliverability.
  2. Network Troubleshooting: By using reverse DNS, network administrators can identify the domain associated with a problematic IP address using the log data with human-readable hostnames instead of numeric IP addresses, enabling them to pinpoint the source of network issues more efficiently.
  3. Security and Access Control: Reverse DNS is often used in firewall configurations and access control systems. It allows organizations to define rules based on domain names rather than IP addresses, enhancing security measures and facilitating network management.

2.3 Common Reverse DNS Issues

Certain services like email are configured to verify the authenticity of request-originating IP addresses before accepting such requests hence invalid or non-existent PTR (Pointer) records could lead to service rejection. Below are some of the common causes of reverse DNS issues.

1. Lack of Reverse DNS Delegation

The absence of the network operators' Name Server (NS) information for their IPs will cause a failure of reverse DNS delegation.

  • AFRINIC maintain authoritative information for the IP blocks they administer and its authoritative DNS servers give referrals if it contains the network operator's Name Server (NS) information in what is referred to as reverse DNS delegation.
    • For example, AFRINIC administers the prefix 196/8 and has the corresponding domain 196.in-addr.arpa.
  • Resource members must request delegation by registering their DNS name servers in the AFRINIC database.
    • For example, the network operator with 196.1.0.0/24 has to register the domain 0.1.196.in-addr.arpa.

2. Lack of PTR records for your IP address

  • A PTR record maps an IP address to a hostname within the reverse DNS zone.
  • Network operators must create PTR records for their email servers, enabling reverse DNS lookup to establish the server's authority for sending and receiving mail. If a DNS server does not possess the appropriate PTR record, the reverse DNS lookup will fail. Consequently, sending emails from such a server may face rejection by email providers that require a valid Reverse DNS record.

3. Incorrect Reverse DNS record

  • An incorrect Reverse DNS record may cause either service or DNS delegation failure impacting other network functionalities, leading to the rejection of emails sent from the server. It is crucial to ensure the accuracy of PTR records to maintain proper reverse DNS resolution.

4. Slow Reverse DNS resolution

  • Delays in Reverse DNS lookups may occur due to network congestion or problems with the DNS server's performance. If slow reverse DNS resolution becomes an issue, alternative DNS servers can be used to determine if the problem persists. In such cases, contacting the hosting provider or network administrator for further investigation is recommended.
Reverse DNS issues can hinder the smooth operation of email servers. By understanding the common causes, network administrators and email server operators can troubleshoot and resolve these issues effectively. Ensuring proper configuration and maintenance of reverse DNS records is crucial for reliable email delivery and compliance with email provider requirements.

Section 3: Steps to setup reverse delegation in the AFRINIC WHOIS database

 Before proceeding with the request for reverse delegation service, it is advisable to review the following checklist:
  • Register Assignments on the WHOIS Database: For Local Internet Registry (LIR) members, it is a must to register the IP utilisation assignments in the AFRINIC WHOIS database before initiating reverse DNS registration. AFRINIC requires at least one registered assignment in order to comply with the policy for accepting reverse delegations.
This requirement is not applicable to resource members in the End-User category.
  • Delegation Boundaries for IPv4 and IPv6: AFRINIC permits reverse delegation on 8-bit boundaries for IPv4 addresses, typically /16 or /24.
To cover CIDR prefixes shorter than a /24 (e.g., /22), multiple delegations are necessary, requiring the registration of four /24 objects. For IPv6, it is highly recommended to align reverse delegations with the boundaries of 4 bits, commonly referred to as nibble boundaries.

Step 1. DNS Configurations on your Name Servers

Before requesting reverse DNS delegation, follow these DNS configuration steps on your name servers:
  1. Create Reverse Zone: Ensure that the reverse zone is created before proceeding with the reverse DNS delegation request.
  2. Configure PTR Records: Properly configure the PTR records within the reverse zones. These records facilitate the mapping of IP addresses to domain names.
  3. Uniformity in SOA Resource Record: Maintain consistency among all the nameservers by ensuring that the SOA (Start of Authority) resource record contains the same serial number and other data content. The SOA should also include a valid 'rname,' which represents the contact address for administrative purposes.

Step 2. Register your Domain(s) on AFRINIC Servers

After concluding step 1, you are now ready to add your domain object(s) and request the reverse delegation. from AFRINIC. This request can be made in one fo the three methods:

2.1 Through MyAfrinic Members Portal

  1. Log into https://my.afrinic.net
  2. Go to Resources -> Reverse Delegation
  3. Click "+" to expand the target allocation
  4. Click the "Add Reverse delegation" option to add the domain
  5. Update the details and submit

2.2 Through the whois web portal

  1. Please Go to https://afrinic.net/whois
  2. Click on "create object ", then choose "domain", then load.
  3. Fill out the form as requested, then submit it.

2.3 Through e-mail and is effective for the bulk updates

Submit a new reverse domain object by copying the domain object(s) template in a text file and emailing it to This email address is being protected from spambots. You need JavaScript enabled to view it. with a blank subject line.

An example of a domain object(reverse delegation) for 192.168.1.0/24 is shown below;

domain: 0.1.192.in-addr.arpa
descr: Example Domain Object
admin-c: NIC-AFRINIC
tech-c: NIC-AFRINIC
zone-c: NIC-AFRINIC
nserver: ns1.example.com
nserver: ns2.example.com
mnt-by: EXAMPLE-MNT
changed: This email address is being protected from spambots. You need JavaScript enabled to view it.
source: AFRINIC

Note that the "nserver:" attributes should be the Fully Qualified Domain Names(FQDNs) and not the IP addresses of your nameservers.

You can validate the functionality of your reverse DNS delegation using the AFRINIC reverse DNS lameness checker here: https://afrinic.net/whois/lame.

Propagation may take a few hours to fully reflect in the global DNS system (depending on the TTL and refresh values). In case of challenges with propagation after 8 hrs, please contact AFRINIC at This email address is being protected from spambots. You need JavaScript enabled to view it..

Section 4: Reverse DNS troubleshooting ( WHAT CAN GO WRONG !)

1. Error message if IP utilisation assignments are not registered in the AFRINIC database:

It is a must to register IP utilisation assignments/sub-allocation in the AFRINIC whois database before submitting your domain object(s) for LIR resource members.

With reference to section 10.5 of AFRINIC’s Consolidated Policy Manual (CPM), it is stated that “No reverse delegation of administered/allocated IP address space is allowed unless an assignment or sub-allocation from the specific address allocation is registered appropriately in the AFRINIC WHOIS database”,

Failure to abide by the above policy requirements will generate the message below:
Image

2. Authentication error when creating on whois web portal & email.

When submitting a new domain object via web whois or email, authentication against the mnt-domains is required; thus, the password of your maintainer object is needed.

In case your password can not be traced, the following steps will assist in resetting the password:
  1. Go to WHOIS Crypt and other Utilities
  2. Input the new password you wish to use for the maintainer.
  3. Click on "Generate hash".
  4. Please send us the BCRYPT hash value that will be generated. We shall then use this to reset your object.
Note that to authenticate against your maintainer after successfully resetting the password, you must use the clear text password you submitted in Step 2 above.
Image

Section 5: Important Policy Sections

The AFRINIC AFRINIC's Consolidated Policy Manual (CPM) covers reverse delegation in Section 10 and the two key sections to pay close attention to are:

1. Section - 10.5 - Validity of the Reverse Delegation

The policy section strictly stipulates that:

No Reverse DNS service in the absence of registered assignments:

  • No reverse delegation of administered/allocated IP address space is allowed unless an assignment or sub-allocation from the specific address allocation is registered appropriately in the AFRINIC whois database.
  • For a /24 reverse delegation, at least one assignment or sub-allocation must be registered in the AFRINIC Database for that specific /24. The entire /24 does not have to be assigned in order for the reverse delegation to be allowed.

2. Section 10.7 - Removal of ‘Lame’ Delegations

What is Lame Delegation?

A DNS name server is considered lame when it does not adequately respond to DNS queries either by:

  • Not responding at all.
  • Responding in some way, but not for the specific domain queried.
  • Responding to the correct domain, but without the authority bit set.

Lame delegations can lead to:

  • Denial of certain services and delays due to DNS malfunctions.
  • Timeouts from unresponsive servers can increase DNS traffic between caching and authoritative DNS servers, resulting in possible load on infrastructure and increased operating costs.

What Member can do? ( Lame Delegation Test )

AFRINIC has developed a tool to test for lame DNS delegations within the in-addr.arpa and ipv6.arpa domains. https://afrinic.net/whois/lame

If a given ‘nserver’ attribute has been determined to be lame for a given domain object, Members are advised to
  • Configure the nameservers authoritative for the relevant zones
  • Edit the list of nameservers in the "nserver" attributes of the relevant "domain" objects. Objects with lame delegations can be updated by one of the mechanisms of interacting with the WHOIS database identified above.

Resolving Lame Delegations

DNS operations are critical services for a well-performing Internet hence to ensure an effective DNS service, AFRINIC implemented an automated procedure to help resource members identify and fix lame delegation issues. In the eventuality of failure to fix the issues, the persistent lame DNS delegations are removed in line with CPM section 10.7 to maintain accurate reverse DNS delegation data.

The full procedure is documented here.

More details about the complete "lameness" checking approach and notification schedule can be read here.
Print Friendly, PDF & Email
Last Modified on -
enarfrpt