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.

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