IPv4 reverse DNS configuration for /24 blocks using RIPE and authoritative DNS
Introduction
Correct reverse DNS configuration for an IPv4 /24 block requires coordination between authoritative DNS servers and the RIPE database. This article explains the full technical process using a concrete example and focuses on why DNS must be prepared before any RIPE action.
Scenario used throughout the article
-
IPv4 block:
217.60.1.0/24 -
Reverse zone:
1.60.217.in-addr.arpa -
Nameservers:
ns1.hyperict.com,ns2.hyperict.com
1. Why DNS must be prepared before RIPE changes
RIPE does not host reverse DNS zones. It only delegates authority for reverse zones by pointing to nameservers. Before RIPE accepts a reverse delegation, the following must already be true:
-
The nameservers must exist in forward DNS.
-
The reverse zone must be properly configured and authoritative.
-
SOA and NS records must be present and consistent.
-
RIPE must be able to validate the delegation by querying DNS.
If DNS is not ready, RIPE validation fails even if the IP block is correctly registered.
RIPE NCC requirements for reverse DNS domain object creation, emphasizing authoritative nameservers, SOA consistency, and DNS validation prerequisites.
Source: RIPE NCC Documentation
2. DNS prerequisites for reverse DNS delegation
2.1 Forward DNS requirements for nameservers
Each nameserver used for reverse DNS must have valid A or AAAA records.
Without resolvable IP addresses, RIPE cannot verify the delegation.
2.2 Correct reverse zone naming for a /24
For IPv4 /24, the reverse zone is always:
Rule:
-
Reverse the first three octets.
-
Do not include the host portion.
2.3 SOA and NS records
Your authoritative DNS must host the reverse zone with correct SOA and NS records.
Key points:
-
SOA primary server must match one of the NS records.
-
Serial must increment on changes.
-
NS records must match what will be entered in RIPE.
2.4 PTR records
Each IP address that requires reverse DNS must have a PTR record.
PTR records are optional per IP but the zone itself must exist before RIPE delegation.
2.5 Validation using dig
Before touching RIPE, validate DNS locally.
Expected results:
-
SOA is returned from your nameserver.
-
NS list matches exactly.
-
PTR queries resolve correctly.
3. RIPE validation checks and common errors
RIPE performs live DNS checks when you create or modify a reverse domain object.
Common error
This error usually means one of the following:
-
The parent zone already has different NS records.
-
Forward DNS and reverse DNS NS records do not match.
-
A previous delegation exists with stale nameservers.
-
Glue records or DNS caches are inconsistent.
RIPE expects a clean and unambiguous delegation chain.
4. Correct RIPE domain object configuration for /24
In the RIPE database, create a domain object:
Important:
-
RIPE does not store PTR records.
-
RIPE only delegates authority.
-
All DNS data lives on your nameservers.
5. Ownership versus upstream assignment
Owning the /24
If your organization holds the allocation or assignment:
-
You create and manage the RIPE domain object.
-
You control DNS and RIPE data.
-
Reverse DNS is fully under your responsibility.
Receiving the /24 from an upstream provider
If the block is provided by an upstream:
-
The upstream may retain control of the RIPE domain object.
-
You may need an internal delegation or coordination.
-
DNS authority might still be yours, but RIPE updates depend on the provider.
Always confirm who controls the reverse delegation.
6. Separation of responsibilities
DNS responsibility
-
Zone files
-
SOA, NS, PTR records
-
Nameserver availability
-
DNS correctness
RIPE responsibility
-
Domain object creation
-
Delegation reference
-
Registry consistency
-
Authentication and authorization
Confusing these roles is a common cause of reverse DNS issues.
Common mistakes
-
Creating RIPE objects before DNS exists.
-
Using nameservers without A records.
-
Incorrect reverse zone naming.
-
Mismatched NS records between DNS and RIPE.
-
Forgetting to increment SOA serial numbers.
Checklist summary
-
Forward DNS for nameservers exists
-
Reverse zone name is correct
-
SOA and NS records are valid
-
PTR records are optional but tested
-
dig validation passes
-
RIPE domain object matches DNS exactly
Comparing the traditional IPv4 ownership model with the modern leasing approach: Lowering entry barriers for global internet services.
This diagram depicts IPv4 leasing in VPS platforms, where IPv4 address space remains registered to the original holder while being contractually leased to a VPS provider, which announces the prefixes via BGP and aligns inetnum, route, and ROA objects for operational use during the lease term.
The diagram illustrates the architectural difference between IPv4 leasing and CGNAT for service providers: IPv4 leasing assigns a routable public address directly to each customer, while CGNAT aggregates multiple customers behind a translation gateway that shares a limited pool of public IPv4 addresses.