• Home
  • Services
    • IPv4 Address Leasing | Lease /24 to /16 Blocks | Hyper ICT Oy
      • IPv4 Leasing ISP | Scalable RIR Compliant IP Blocks – Hyper ICT
      • IPv4 Leasing Hosting | Clean IPv4 Blocks for VPS & Cloud – Hyper ICT
      • Infrastructure Network Tools
        • IP Revenue Calculator
    • HPA – Zero Trust Access
    • RAGaaS / AI Assistant
  • Company
    • About Us
    • Contact Us
    • FAQ
    • Terms of Use
    • Privacy Policy
  • Blog
hyper-ict.com hyper-ict.com
  • Home
  • Services
    • IPv4 Address Leasing
      • IPv4 Leasing ISP | Scalable RIR Compliant IP Blocks – Hyper ICT
      • IPv4 Leasing Hosting | Clean IPv4 Blocks for VPS & Cloud – Hyper ICT
    • Infrastructure Network Tools
    • HPA
    • AI & Automation / RAGaaS
    • SASE / CASB
    • Security Consultation
    • Software Development
  • Company
    • About us
    • hpa-request-demo
    • FAQ
    • Terms of Use
    • Privacy Policy
  • Blog
hyper-ict.com

rdns configuration

Home / rdns configuration
20Apr

IPv4 Leasing Process and Typical Provisioning Timeline for Network Operators

April 20, 2026 Admin DNS, IP Leasing, Network Management, Notes & Tricks 53

IPv4 Leasing Process includes collecting basic customer information, assigning an IP block, and configuring routing objects such as IRR and RPKI. It also includes operational elements such as rDNS setup and maintainer access for managing database updates. For VPS providers and network operators, provisioning typically completes within a short timeframe once all required information is available.


What is IPv4 Leasing Process?

IPv4 Leasing Process refers to the operational steps required to assign an IP block to a customer and make it usable in a network.

This process does not involve ownership transfer. Instead, the provider assigns address space and configures the required routing and authorization elements.

Typically, the process includes:

  • Collecting customer details
  • Assigning an IP prefix
  • Creating IRR route objects
  • Configuring RPKI (ROA)
  • Setting up rDNS records
  • Providing maintainer access for RIPE database updates
  • Providing authorization if needed (LoA)

The goal is to ensure that the customer can announce and use the IP space without routing or validation issues.


How IPv4 Leasing Process Works

In practice, the IPv4 Leasing Process follows a simple sequence.

First, the customer provides basic information:

  • Name (individual or company)
  • Billing address
  • Abuse email
  • Billing email and WhatsApp contact
  • Country
  • RIPE ORG (if available)
  • ASN (customer ASN or upstream provider ASN)
  • LoA requirement (if needed)

Then, the provider prepares the network configuration:

  • Assigns the requested IP block
  • Creates IRR route objects
  • Configures RPKI ROA
  • Sets up rDNS (reverse DNS) based on customer requirements
  • Assigns or updates RIPE maintainer access for future changes
  • Prepares LoA if required

Finally, the IP space becomes ready for announcement.

In most cases, delays do not come from the provider. Instead, they occur when required information is incomplete or unclear.

IPv4 leasing process illustration showing IP allocation, routing setup, rDNS configuration, and maintainer control in network infrastructure Illustration of the IPv4 leasing process, including IP allocation, IRR and RPKI setup, rDNS configuration, and maintainer access for network operators.
Image generated using AI (ChatGPT).


Common Use Cases

IPv4 Leasing Process is commonly used in several infrastructure scenarios.

Hosting Providers

  • Expanding VPS capacity with additional IP ranges
  • Assigning dedicated IPs to customers
  • Managing outbound traffic policies
  • Using rDNS for service-specific configurations (e.g. mail or reverse mapping)

ISPs

  • Adding new address space for customer growth
  • Integrating leased IPs into existing routing policies
  • Delegating reverse DNS to customer infrastructure

Network Operators

  • Announcing additional prefixes via existing ASN
  • Using upstream providers for BGP announcement
  • Managing RIPE objects directly through maintainer credentials

In all cases, the process focuses on routing readiness and operational control.


Explained for Network Engineers

From an operational perspective, IPv4 Leasing Process involves coordination between registry data, routing systems, and DNS configuration.

Key points include:

  • IRR and RPKI must align with the announcing ASN
  • Route objects define routing intent but do not enforce it
  • ROA defines origin validation and must match BGP announcements
  • LoA is required when announcing via a third-party ASN

In addition, operational control depends on two key elements:

  • rDNS (reverse DNS)
    Used for mapping IP addresses to hostnames. This is especially important for services such as mail servers and logging systems. Incorrect or missing rDNS may affect service behavior or reputation.
  • RIPE maintainer access
    Allows the customer to update objects such as route, domain, and abuse information. With proper maintainer access, operators can make changes directly without provider intervention.

Geolocation introduces a separate challenge.

Geolocation data does not come from RIPE or routing configuration. Instead, third-party databases maintain it. Therefore:

  • Changes do not apply immediately
  • Updates depend on external providers
  • Traffic usage often influences how databases classify IP ranges

As a result, even if the country is set correctly in registry data, external services may continue to show outdated locations.

In practice, consistent usage from the target region improves geolocation accuracy over time.


Summary

IPv4 Leasing Process is a structured workflow that enables customers to use IP address space with full routing and operational readiness. It includes not only routing configuration but also DNS setup and access control through RIPE maintainers.

Provisioning delays are usually caused by missing input data rather than technical limitations. Once completed, IP space becomes immediately usable at the routing level.

Geolocation behavior remains independent from routing and registry configuration. Since third-party databases control it, updates may take time and depend on actual usage patterns rather than immediate changes.

Read more
22Jan

IPv4 reverse DNS configuration for /24 blocks using RIPE and authoritative DNS

January 22, 2026 Admin DNS, IP Leasing, Network Management 74

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 reverse DNS requirements for creating domain objects, including authoritative nameservers and SOA record validation. 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.

ns1.hyperict.com. IN A 192.0.2.10
ns2.hyperict.com. IN A 192.0.2.11

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:

1.60.217.in-addr.arpa

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.

$ORIGIN 1.60.217.in-addr.arpa.
@ IN SOA ns1.hyperict.com. hostmaster.hyperict.com. (
2026012201
3600
900
1209600
3600
)
IN NS ns1.hyperict.com.
IN NS ns2.hyperict.com.

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.

1 IN PTR host1.example.net.
10 IN PTR mail.example.net.
254 IN PTR router.example.net.

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.

dig SOA 1.60.217.in-addr.arpa
dig NS 1.60.217.in-addr.arpa
dig PTR 217.60.1.10

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

IP in parent refers to multiple nameservers

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:

domain: 1.60.217.in-addr.arpa
descr: Reverse DNS for 217.60.1.0/24
admin-c: AA12345-RIPE
tech-c: AA12345-RIPE
zone-c: AA12345-RIPE
nserver: ns1.hyperict.com
nserver: ns2.hyperict.com
mnt-by: MNT-HYPERICT
source: RIPE

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

Read more

Get in Touch with Us!

Have questions or need assistance? We're here to help!

Address: Soukankari11, 2360, Espoo, Finland

Email: info [at] hyper-ict [dot] com

Phone: +358 415733138

Join Linkedin
logo

Hyper ICT is a Finnish company specializing in network security, IT infrastructure, and digital solutions. We help businesses stay secure and connected with Zero Trust Access, network management, and consulting services tailored to their needs.

    Services

    IPv4 Address Leasing
    IPv4 Lease Price
    HPA – Zero Trust AccessAI & Automation / RAGaaSSecurity ConsultationSoftware Development

    Quick Payment

    Quick Menu

    About us
    Contact Us
    Terms of use
    Privacy policy
    FAQ
    Blog

    © 2023-2025 Hyper ICT Oy All rights reserved.

    whatsapp-logo