Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

What Is Reverse DNS (PTR) for IPv4? Who Controls It During a Lease?

Understand IPv4 PTR records and reverse DNS delegation, who controls reverse lookups during a lease, and what to confirm for mail, hosting, and service changes.

The mail queue is filling and the rejection says no PTR record. Or a support form wants a hostname for the IP and refuses to accept an address. Or an upstream log names your addresses by number and you would rather it named them by name.

All three end up in the same place: someone needs reverse DNS for a block they do not hold in their own name.

That is when the useful distinction shows up, because there are two things in this picture and only one of them is the record.

Definition Box: Reverse DNS resolves an IP address back to a domain name. For IPv4 it uses the in-addr.arpa domain and the PTR record type, both defined in RFC 1035. Turning it on for a block takes two separate steps: delegating the reverse zone to your name servers, and then publishing PTR records inside that zone. During a lease, the two steps rarely sit with the same party.

In one line: the PTR record is what people ask about, and the delegation is what determines whether you are allowed to answer.

White-Face Xiaolu turns a small key to open a locked drawer, while a blank card that is already inside stays untouched.

The delegation opens the zone; the PTR records are what you put inside it afterwards.

1. Reverse DNS and PTR, in One Minute

Forward DNS maps a name to an address: mail.example.net → 203.0.113.25, held in an A record. Reverse DNS does the opposite, and because DNS is a name-indexed system, the address has to be turned into a name first.

For IPv4, that means reversing the four octets and appending in-addr.arpa:

Address:        203.0.113.25
Reverse name:   25.113.0.203.in-addr.arpa
PTR record:     25.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.net.

203.0.113.0/24 here is a documentation range reserved by RFC 5737; substitute your own prefix when reading it.

The PTR record itself is unremarkable. RFC 1035 defines its data as a single field — "A <domain-name> which points to some location in the domain name space" — and notes that PTR records "are simple data, and don't imply any special processing similar to that performed by CNAME". A PTR is a pointer. It carries no authority, no policy, and no validation.

What makes IPv4 reverse DNS operationally awkward is the granularity. Each label in the reverse name is one octet, so the natural unit of delegation is one /24. RFC 1035 gives the reason in a sentence worth remembering: "The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space."

That single design decision explains most of the constraints that follow — why a /22 needs four delegations, why a sub-/24 range needs a separate technique rather than a straightforward one, and why the granularity of reverse DNS does not match the granularity of the prefixes people actually deploy.

IPv6 works the same way at a finer grain, using reversed hexadecimal nibbles under ip6.arpa. The rest of this article stays with IPv4.

2. Delegation and Records Are Two Different Things

RIPE's own documentation splits the work explicitly: as an address holder you have to do two things — "First, you have to configure your zone for reverse DNS. Second, you have to request reverse delegation of your zone. The second part is done by creating a domain object in the RIPE Database."

Reverse delegation PTR record
What it establishes Which name servers are authoritative for the reverse zone Which name answers for one specific address
Where it lives The parent zone and the RIR database Your own authoritative zone file
Who controls it The registry maintainer responsible for the address block Whoever runs the authoritative name servers
Granularity One delegation per zone; the smallest byte-boundary zone is a /24 One record per address
Failure looks like Queries never reach your server Queries reach your server and return nothing useful

A useful mental model: the delegation points the internet at your name servers. The PTR records are what those servers say when someone asks. You can have a perfect zone file and no delegation — in which case nobody ever sees it — and you can have a delegation pointing at servers that answer nothing.

Before a delegation can exist, someone has to be authorised to create it. In the RIPE Database that authority is expressed through the mnt-domains: attribute on the object covering the address block: the maintainer named there is the one allowed to create and maintain domain objects for that space. This is the attribute that decides who holds the pen, and it is the reason a lease does not automatically grant reverse DNS control.

The zone also has to be built at a workable granularity, and here two different cases get mixed up constantly. A delegation is a zone, and the smallest zone IPv4 can delegate is one /24:

  • A block larger than a /24 covers several /24 zones and therefore needs one delegation per zone. A /22 becomes four /24 zones, four domain objects, and four sets of name servers to get right.
  • A block smaller than a /24 cannot be delegated on a byte boundary, because there is no byte boundary to cut at. That does not mean it cannot be delegated. RFC 2317 describes delegating it as a classless sub-zone: the parent /24 zone carries an NS record for the range plus one CNAME per address, redirecting each query into a child zone whose name encodes the range. See the FAQ below.
Allocation:      203.0.112.0/22          →  four /24 zones
Reverse zones:  112.0.203.in-addr.arpa
                113.0.203.in-addr.arpa
                114.0.203.in-addr.arpa
                115.0.203.in-addr.arpa

Sub-range:     203.0.113.64/26           →  no byte-boundary zone,
               delegated as a classless sub-zone instead:
               NS + per-address CNAMEs in 113.0.203.in-addr.arpa
               (RFC 2317)

RIPE's delegation process runs automated checks and rejects any update that produces an ERROR or CRITICAL result, and it can take up to 24 hours before the delegation is visible in the DNS.

White-Face Xiaolu holds a ring of keys beside four drawers, with a smaller child drawer connected beneath the first.

Delegation is per zone: a block larger than a /24 needs several, and a block smaller than a /24 is delegated as a classless sub-zone, RFC 2317 style.

3. How PTR Relates to Forward DNS

A PTR and an A record answer opposite questions, and neither one validates the other.

A record PTR record
Direction Name → IP address IP address → name
Stored in Your forward zone Your reverse zone, under in-addr.arpa
Answers "What address is this name?" "What name is this address?"
Needed when the service is reached by hostname over IPv4 Yes — this is what resolves the name No
Needed when far-end software looks up an address and wants a name No Yes

The practice that connects them is forward-confirmed reverse DNS: look up the address, get a name, then look that name up and check it points back at the same address. Both halves matching is a stronger signal than either one alone. Whether a given receiving system performs that check, and what it does with the result, is that system's own policy decision — the check itself is optional, and practice varies by operator.

Two honest caveats belong here, because this is where expectations usually go wrong.

A PTR record does not guarantee mail delivery. What a receiving system does with a missing or mismatched PTR is its own policy decision, and it generally weighs that against other evidence: authentication results, sending history, blocklist status, complaint rates, and traffic patterns. A clean PTR helps; it is not a pass.

A PTR record does not repair an IP's reputation. If the addresses arrived with a history, renaming them does not erase it. That is a separate review, and the IPv4 lease IP reputation checklist covers the checks that belong alongside this one.

4. Who Does What During a Lease

This is the part that decides how much work a lease actually creates, and it is usually settled in the wrong order — after delivery, when mail is already failing.

The trap is assuming that receiving the addresses implies the ability to configure reverse DNS for them. It does not. The ability follows the delegation authority, and the delegation authority follows the registry object.

Task Typically held by
The registry object covering the prefix The resource holder / LIR
Authority to create the domain object (mnt-domains:) The holder, through the designated maintainer
Running the authoritative reverse zone Either party, by agreement
Choosing PTR hostnames Usually the customer — they know what the service is
Publishing PTR records Whoever runs the zone
Requesting changes to the delegation Whoever holds the authority
Removing the delegation at lease end Whoever holds the authority — and this one gets forgotten

Three of those rows are where leases go wrong.

Reverse delegation is not part of "you get the addresses". Whether a lessee can manage PTR records directly depends on whether the holder delegates the reverse zone to name servers the lessee controls. Some leases do that, some hand it over on request, and some keep PTR management with the holder and accept hostnames through a change request.

Self-management has a prerequisite. To receive a delegation at all, the address holder has to configure the zone on at least two authoritative name servers and pass the registry's tests. A customer who wants to run their own reverse zone needs working name servers before the delegation can be created — not after.

The end of the lease has to be planned. If the delegation stays in place after the block has gone back, the former lessee's name servers remain authoritative for addresses they no longer hold. That is a live misconfiguration, and it is easy to leave behind because nothing breaks at the moment it happens.

White-Face Xiaolu holds a key out toward a compact server cabinet, while a blank registry card lies nearby.

Delegation authority and zone operation can sit with different parties — as long as the split is written down.

5. What to Confirm Before Delivery

The point of confirming this early is that reverse DNS dependencies show up in places that are not obviously DNS: mail acceptance, some monitoring and logging formats, verification checks in third-party platforms, and any service that expects a hostname rather than an address.

Six things are worth writing into the Order or the delivery material:

1. Who manages the reverse delegation for this prefix
2. Whether the customer can manage PTR records directly,
   or whether changes go through a request
3. How a change is submitted, and the expected turnaround
4. Whether a response time is committed, or only a best-effort path
5. The hostname format in use, and any template the holder requires
6. What happens to the delegation when the lease ends

Two of these are easy to skip and expensive to skip.

Turnaround. A delegation request that depends on a registry update is not an instant operation — RIPE's own documentation allows up to 24 hours for propagation after a successful update, and a malformed zone means starting again. If a project has a cutover window, that window should include the delegation step.

The end state. "We will remove it later" is not a plan. Write down who removes the delegation, when, and what evidence confirms it was done.

White-Face Xiaolu writes on a small checklist card, with one line marked at the bottom and a calendar sheet beside it.

A change path and an end state are both part of the delivery scope, not afterthoughts.

SKNK lists Reverse DNS among the items that can be customised by agreement or Order on the IPv4 address leasing service. That is the right level for the decision: prefix, delegation model, change path, and lease-end handling — the same shape as the route, ROA, and LOA arrangements that a lease needs in parallel.

6. How to Check Reverse DNS

Checks split along the same line as the setup. First confirm the delegation covers the prefix, then confirm what each address actually returns.

# 1. Is the zone delegated, and to whom?
dig NS 113.0.203.in-addr.arpa +short

# 2. What does one address return?
dig -x 203.0.113.25 +short

# 3. Forward-confirmed check: does the returned name point back?
dig +short A mail.example.net

Reading the results:

  • No NS records for the reverse zone usually means the delegation was never created, or was created for a different zone than the one you queried. Check the exact zone boundaries before assuming anything.
  • NS records for the wrong zone happen when a block larger than a /24 spans several zones. A /24 delegated inside a /22 allocation is fine; the one you queried may simply be the neighbour.
  • A delegation that exists but returns nothing means the name servers answer for the zone but the specific address has no PTR record.
  • A PTR that does not match forward DNS is a configuration error on one side or the other, and both sides are worth checking before you file anything.

The Reverse DNS Lookup & Delegation Check automates the first part — it shows whether a prefix has delegation in place and which name servers hold it. It does not replace checking individual records: a delegated zone with no PTR records in it passes a delegation check and still fails a mail server's reverse lookup.

White-Face Xiaolu follows one pointer line that splits into two tracks, one reaching an open gate and the other stopping at a blank panel.

Delegation coverage and record content are two different checks, and passing one says nothing about the other.

FAQ

Does every IPv4 address need a PTR record?

No. Reverse DNS is optional, and addresses that only make outbound connections, VPN endpoints, or internal services work fine without one. It matters most where something checks it: mail reception, some platform verification steps, and logs or tools that expect a hostname.

Does a PTR record guarantee email delivery?

No. It is one signal among several. Receiving systems weigh PTR against authentication, sending history, blocklist status, and traffic behaviour, and they apply their own policy. A correct, forward-confirmed PTR removes one reason for rejection; it does not create a reason for acceptance.

Can a lessee change PTR records directly?

Only if the holder delegates the reverse zone to name servers the lessee controls. If the delegation points at the holder's name servers, changes go through the holder as a request. Which model applies is a contract and Order question, not something to infer from having the addresses.

What happens to reverse DNS when a lease ends?

The delegation should be removed or repointed. What happens to the zone content afterwards is a matter of agreement between the parties, not a general rule — some arrangements keep it as a record for a defined period, others clean it up at termination, and the Order should say which. Leaving the delegation in place after the block returns is a real misconfiguration: the former lessee's servers stay authoritative for addresses they no longer hold. Agree on this before signing, not at termination.

What changes for prefixes smaller than /24?

IPv4 reverse zones are cut on byte boundaries, and there is no byte boundary inside a /24 — so a range smaller than a /24 cannot be delegated the normal way. It can still be delegated, as a classless sub-zone. RFC 2317 describes the technique: the holder of the parent /24 zone places an NS record for the range and a CNAME for each address in it, redirecting queries into a child zone whose name encodes the range (for example 64/26.113.0.203.in-addr.arpa), which is served by the name servers the sub-range's operator controls. The parent /24 zone still has to exist first — the sub-zone's delegation lives inside it. The routing side of small prefixes is a separate set of constraints, covered in IPv4 Leasing Below /24.

Conclusion

The PTR record is the visible part. The delegation is the part that has to be arranged.

Reverse DNS looks like a single setting and behaves like a chain: registry authority creates the delegation, the delegation points at name servers, the name servers publish PTR records, and a receiving system somewhere decides what to make of the result. Every link in that chain can belong to a different party, and on a lease, several of them usually do.

So the workable question during a lease is not "do I get reverse DNS" but "who holds the delegation, who runs the zone, and how does a change get made". Answer those three before delivery, include the end-of-lease handling in the same conversation, and reverse DNS stops being the thing that surfaces as a mail failure two weeks after cutover.

Key Takeaways

  • Reverse DNS for IPv4 uses the in-addr.arpa domain and PTR records, defined in RFC 1035; the address's octets are reversed to build the name.
  • Setting it up is two steps: delegate the reverse zone, then publish PTR records inside it. They are frequently held by different parties.
  • Delegation authority is expressed through the registry object's maintainer scope — for RIPE Database objects, the mnt-domains: attribute.
  • IPv4 delegation is per zone, and zones are cut on byte boundaries, so the smallest conventional zone is a /24: a larger block needs one delegation per zone, while a smaller block cannot be delegated on a byte boundary and is instead delegated as a classless sub-zone using RFC 2317.
  • A PTR record neither guarantees mail delivery nor repairs IP reputation; it removes one reason for rejection.
  • Plan the lease-end handling: a delegation left pointing at a former lessee's name servers is a live misconfiguration.

In One Sentence

Reverse DNS takes two steps — delegating the reverse zone and publishing PTR records — and during a lease the step that decides everything is the delegation, because the authority to create it sits with the registry maintainer that protects the address block, not with whoever is using the addresses.

Continue Reading

References