PTR Record Not Resolving Because a More-Specific Reverse DNS Zone Is Authoritative – UltraDNS Support

Overview

A PTR record may not resolve as expected when the record is created in a broader parent reverse DNS zone, but DNS resolution is being delegated to a more-specific child reverse DNS zone.

PTR records are used for reverse DNS lookups. For IPv4 address a.b.c.d, the full PTR owner name is d.c.b.a.in-addr.arpa. The PTR record must exist in the reverse DNS zone that is authoritative for that full PTR owner name.

Symptoms

A PTR record exists in UltraDNS, but a reverse DNS lookup does not return the expected hostname.
A trace lookup follows a more-specific reverse DNS zone instead of the parent reverse DNS zone where the PTR record was created.
The PTR owner name appears to belong under a child reverse DNS zone that is delegated or otherwise authoritative.

Example

In this example, the reverse lookup is for IP address 10.11.12.13.

IP address: 10.11.12.13
Full PTR owner name: 13.12.11.10.in-addr.arpa
Parent reverse zone: 11.10.in-addr.arpa
More-specific child reverse zone: 12.11.10.in-addr.arpa

If 12.11.10.in-addr.arpa is delegated or authoritative for the lookup path, the PTR record for 10.11.12.13 must be created in 12.11.10.in-addr.arpa using record name 13.

In that case, a PTR record created only in 11.10.in-addr.arpa is not used for the lookup of 13.12.11.10.in-addr.arpa.

Why This Happens

DNS resolution follows the authoritative delegation path for the queried name. If a more-specific reverse DNS zone is authoritative for the full PTR owner name, that child zone is used instead of the broader parent reverse DNS zone.

Because of this, a PTR record created in the parent reverse DNS zone may not answer for the IP address when the child reverse DNS zone is authoritative for the queried PTR owner name.

How to Confirm the Authoritative Reverse DNS Zone

Run a trace lookup for the IP address:
```
dig -x 10.11.12.13 +trace
```
Review the delegation path returned in the trace output.
Identify which reverse DNS zone is authoritative for the full PTR owner name.
In this example, if the trace follows 12.11.10.in-addr.arpa, then the PTR record in 11.10.in-addr.arpa is not used for that lookup.

How to Resolve the Issue

Identify the reverse DNS zone that is authoritative for the full PTR owner name.
Create the PTR record in that authoritative reverse DNS zone.
If the more-specific child reverse DNS zone should not be authoritative, remove or correct the child zone delegation before relying on the parent reverse DNS zone.
Re-test the reverse lookup:
```
dig -x 10.11.12.13 +trace
```

Expected Outcome

After the PTR record is created in the authoritative reverse DNS zone, the reverse DNS lookup should follow the delegation path to that zone and return the configured PTR response.

Important Notes

PTR records must be created in the applicable reverse DNS zone, not in the forward DNS zone.
For IPv4 address a.b.c.d, the full PTR owner name is d.c.b.a.in-addr.arpa.
For a standard /24 reverse DNS zone, the zone is usually c.b.a.in-addr.arpa, and the PTR record name inside that zone is d.
Do not confuse the full PTR owner name with the reverse DNS zone name.
If a more-specific child reverse DNS zone exists and is authoritative, create the PTR record in that child zone unless the child delegation is removed or corrected.

Related to