skip to content

A DNS reverse lookup of your new mail server 203.0.113.25 returns a generic hosting name; why can't you fix that in example.com's zone, and who can?

level: seniorimportance: should knowfreq 24%

answer

  1. addresses become names
  2. octets written backwards
  3. whoever holds the address block
  4. forward and reverse drift apart

basics

~10 s

The PTR record lives at 25.113.0.203.in-addr.arpa, a name delegated along address allocations to whoever holds 203.0.113.0/24, normally the hosting provider. They must set the PTR, or delegate that reverse name to you.

solid answer

~40 s

Reverse lookups query a `PTR` record at a name built from the address: for IPv4 the octets are reversed under `in-addr.arpa`, so 203.0.113.25 becomes `25.113.0.203.in-addr.arpa` (RFC 1035 §3.5). The reversal exists so the reverse tree can be delegated along address allocations, which means that name belongs to the address holder, not to the owner of `example.com`. So the fix is on the provider's side: they set the `PTR` to `mail.example.com`, or delegate the reverse name to a zone you run. For a block smaller than a /24, delegation is often done by a `CNAME` from each reverse name into your zone, which works because RFC 2181 §10.2 lets a `PTR` lookup pass through an alias. Then publish a matching `A` record for `mail.example.com`, since the DNS never keeps forward and reverse consistent for you.

code

dns · 5 lines
dns
; in the provider's zone 113.0.203.in-addr.arpa
25.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.

; in the domain owner's zone example.com
mail.example.com.          3600 IN A   203.0.113.25

go deeper

for a junior

Recall that reverse lookups use PTR records under in-addr.arpa for IPv4 and ip6.arpa for IPv6, and that the address is written backwards.

for a middle

Build the reverse name correctly for both address families and explain that the reversal lets reverse zones be delegated along address blocks.

for a senior

Diagnose deliverability problems from reverse DNS: identify who holds the address block, get the PTR set or delegated, and make forward and reverse agree yourself.

for a principal

Plan reverse DNS as part of address strategy: provider-held blocks mean ticket-driven PTR changes, while holding your own space means operating reverse zones too.

## What a PTR record is A **PTR** ("domain name pointer", type 12) record maps a name to another name. Its main use is the **reverse lookup**: given an IP address, find a host name. The DNS has no index from addresses to names, so the address itself is turned into a domain name, and the `PTR` record sits at that name. ## How the reverse name is built **IPv4** (RFC 1035 §3.5): the four octets are written in reverse order, as decimal labels, under `in-addr.arpa`. 1. Take `203.0.113.25`. 2. Reverse the octets: `25.113.0.203`. 3. Append the suffix: `25.113.0.203.in-addr.arpa.` **IPv6** (RFC 3596 §2.5): the 128-bit address is written as 32 hexadecimal nibbles, **low-order nibble first**, separated by dots, under `ip6.arpa`. `2001:db8::25` becomes a 32-label name ending in `...8.b.d.0.1.0.0.2.ip6.arpa.`. Every zero nibble is written out; there is no `::` shorthand in the reverse name. ## Why the reversal matters: delegation follows the address RFC 1035 explains that the reversal, "though awkward to read, allows zones to be delegated which are exactly one network of address space." The most significant part of the address becomes the label nearest the root, so `113.0.203.in-addr.arpa` is the natural zone for `203.0.113.0/24`. Reverse zones are therefore delegated along **address allocations**: whoever allocates an address block delegates the matching reverse zone to the block's holder. When a hosting provider holds `203.0.113.0/24`, the provider runs `113.0.203.in-addr.arpa`. Your `example.com` zone sits in a different part of the tree, and nothing you publish there is consulted during a reverse lookup of `203.0.113.25`. | Lookup | Name queried | Zone that answers | Who controls it | |---|---|---|---| | forward | `mail.example.com`, type `A` | `example.com` | the domain owner | | reverse | `25.113.0.203.in-addr.arpa`, type `PTR` | `113.0.203.in-addr.arpa` | the address-block holder | ## Getting it fixed - **Ask the address holder** to set the `PTR` for `203.0.113.25` to `mail.example.com.`. Providers usually expose this per address. - **Get the reverse name delegated** to a zone you operate. For a whole block on an octet boundary, that is an ordinary delegation. For a block smaller than a /24, the holder can publish a `CNAME` from each reverse name into a zone you run; RFC 2181 §10.2 allows a `PTR` lookup to encounter an alias on the way, as long as the final `PTR` value is not itself an alias. - **Publish the matching forward record**: `mail.example.com. A 203.0.113.25`. ## What the DNS does and does not guarantee - **No consistency check.** Nothing in the DNS requires the `PTR` name's `A` record to contain the original address. Forward and reverse are separate data in separate zones, often run by different parties. - **Receivers check anyway.** Many mail receivers look up the `PTR`, then resolve that name forward and compare it with the connecting address. That is a receiving-server practice, not a DNS rule, and it is why a generic provider name hurts deliverability. - **Several PTR records are legal.** RFC 2181 §10.2 calls the belief that a `PTR` RRset must hold exactly one record incorrect. Many consumers use only one of them, so one clear name is the practical choice. - **The `PTR` value must not be an alias.** It should name a host directly, not a `CNAME`. ## Common mistakes when setting it up 1. **Publishing the `PTR` in the forward zone.** Written without a trailing dot in the `example.com` zone file, `25.113.0.203.in-addr.arpa` is a relative name, becomes `25.113.0.203.in-addr.arpa.example.com`, and is never queried. 2. **Writing the octets in forward order.** `203.0.113.25.in-addr.arpa` is a different name, in a different reverse zone. 3. **Pointing the `PTR` at a name that has no matching address record**, so a receiver's forward check fails even though the reverse lookup succeeds. 4. **Forgetting IPv6.** A mail server that also sends over IPv6 needs a `PTR` under `ip6.arpa` for that address as well; the IPv4 reverse record does not cover it. ## What interviewers probe The core is the ownership split: forward data belongs to the name holder, reverse data to the address holder. Strong answers build the `in-addr.arpa` name correctly, say why the octets are reversed, mention the IPv6 nibble form, and separate what the DNS guarantees (nothing about consistency) from what mail receivers enforce.

  • What name holds the PTR record for the IPv6 address 2001:db8::25?
    RFC 3596 §2.5 writes all 32 nibbles in reverse, low-order first, under `ip6.arpa`: `5.2.0.0`, then 20 zero nibbles, then `8.b.d.0.1.0.0.2.ip6.arpa.`. Every zero is written out, and the reverse zone again follows the address allocation, so the holder of that IPv6 prefix controls it.
  • Is it wrong to publish two PTR records for one address?
    Not per the DNS: RFC 2181 §10.2 says nothing limits a `PTR` RRset to one record and calls that belief incorrect. The practical risk is that many consumers use only one returned name, so which one a mail receiver checks is unpredictable. One clear name that resolves back to the address is the safer choice.

saying these in an interview costs you the question

  • You add the PTR record to your own example.com zone like any other record.
  • The reverse name for 203.0.113.25 is 203.0.113.25.in-addr.arpa.
  • DNS rejects a PTR whose name does not resolve back to the same address.
  • A PTR RRset may legally contain only one record.
  • Reverse DNS is computed automatically from the forward A records.