Reverse DNS Delegation in ISP Networks

Reverse DNS Management & Delegation Audit in ISP Environment

(BIND9 + Public IP Pools Practical Guide)

• Author: Syed Jahanzaib ~A Humble Human being! nothing else 
• Platform: aacable.wordpress.com
• Category: ISP Infrastructure / DNS Engineering
• Audience: ISP Engineers, NOC Teams, Network Architect.

---

⚠️ Disclaimer & Note on Writing Style

Every network environment is unique. A solution that works effectively in one infrastructure may require modification in another. Readers are strongly encouraged to understand the underlying concepts and adapt the guidance according to their own architecture, operational policies, and risk tolerance.

Blind copy-paste implementation without proper validation, testing, and change management is never recommended — especially in production environments. Always ensure proper backups and risk assessment before applying any configuration.

The content shared here is based on hands-on experience from real-world deployments, ISP environments, lab testing, and continuous learning. While I strive for technical accuracy, no technical implementation is entirely free from the possibility of error. Constructive discussion and alternative approaches are always welcome.

Due to professional commitments, it is not always feasible to publish highly detailed or multi-part write-ups. The technical logic and implementation details are written based on my own practical experience. AI tools such as ChatGPT are used only to refine grammar, structure, and presentation — not to generate the core technical concepts.

This blog is not intended for client acquisition or follower growth. It exists solely to share practical knowledge and real-world experience with the community.

Thank you for your understanding and continued support.

---

Introduction

In ISP infrastructure, configuring reverse DNS (rDNS) is not optional — it directly impacts:

• Mail server reputation (PTR required for SMTP)
• Abuse traceability
• Customer hosting credibility
• Compliance audits
• Upstream validation

Why Reverse DNS Matters Beyond Basic Configuration

Reverse DNS is not just a technical formality. In ISP environments, it directly impacts:

• SMTP deliverability
• IP reputation scoring
• Abuse handling
• Hosting credibility
• Security validation

Forward-Confirmed Reverse DNS (FCrDNS)

A production-grade setup should implement Forward-Confirmed Reverse DNS (FCrDNS).

FCrDNS means:

1. IP → PTR → hostname
2. Hostname → A record → same IP

Example:

198.51.100.25 → mail.zaib.net

mail.zaib.net → 198.51.100.25

If this round-trip does not match, many mail systems flag the IP as suspicious. For any ISP hosting mail servers or customer VPS infrastructure, FCrDNS should be mandatory.

Many engineers configure reverse zones in BIND but overlook the most critical requirement:

👉 Registry-level delegation

This guide explains:

• Reverse DNS architecture
• Proper BIND9 zone structure
• How to verify IP ownership
• How to verify delegation
• Automated audit scripts
• Operational best practices

---

1️⃣ Reverse DNS Architecture

Example IP:

• 198.51.100.15
• Reverse zone:
• 100.51.198.in-addr.arpa

Resolution chain:

• Root DNS
• ↓
• in-addr.arpa
• ↓
• Regional Registry (Example: APNIC)
• ↓
• Your Authoritative DNS (ns1.zaib.net / ns2.zaib.net)

⚠ If registry does not delegate the reverse zone to your nameservers, your local BIND configuration will never be visible globally.

Reverse Zone Configuration vs Delegation (Critical Distinction)

A very common misunderstanding in ISP environments is confusing:

• Reverse zone configuration (inside BIND)
• Reverse zone delegation (at the registry level)

You can configure a zone perfectly in BIND, but if the parent registry (e.g., APNIC) does not delegate the zone to your nameservers, the reverse lookup will never work publicly.

Always remember:

Local Zone File ≠ Public Delegation

Both must be correctly configured.

---

🎯 This clarifies a major conceptual mistake many engineers make.

⚠ Critical ISP Reminder

Make sure:

✔ These reverse zones are delegated to your NS in APNIC / upstream
✔ Glue records exist
✔ Firewall allows TCP/UDP 53 from internet

Otherwise public reverse will not resolve.

2️⃣ Proper Reverse Zone Design in BIND9

Each /24 requires its own reverse zone.

Example:

• 198.51.100.0/24 → 100.51.198.in-addr.arpa

named.conf.local Entry

zone "100.51.198.in-addr.arpa" {
type master;
file "/etc/bind/zones/rev.198.51.100";
};

Reverse Zone File Template

$TTL 43200
@ IN SOA ns1.zaib.net. hostmaster.zaib.net. (
2026021101
14400
1800
1209600
3600 )
IN NS ns1.zaib.net.
IN NS ns2.zaib.net.
$GENERATE 1-254 $ IN PTR 198-51-100-$.zaib.net.

✔ Use $GENERATE for dynamic customer ranges
✔ Maintain consistent serial format YYYYMMDDNN
✔ Keep structured file naming

3️⃣ Verify IP Ownership

Ownership ≠ delegation.

Run:

whois -h whois.apnic.net 198.51.100.0

Check:

• inetnum
• netname
• mnt-by
• descr

If upstream provider owns block → they must delegate reverse DNS to you.

4️⃣ Verify Reverse Delegation

Check NS Records

• dig NS 100.51.198.in-addr.arpa +short

Expected:

• ns1.zaib.net.
• ns2.zaib.net.

If empty → not delegated.

5️⃣ Full Delegation Trace

dig +trace -x 198.51.100.1

You should see:

• Root
• in-addr.arpa
• Registry
• Your NS

If chain stops before your NS → delegation issue.

6️⃣ Multi-Zone Delegation Audit Script

for Z in 100.51.198 113.0.203 2.0.192
do
echo "==== Checking $Z.in-addr.arpa ===="
dig NS $Z.in-addr.arpa +short
echo
done

How to Interpret the Script Output

Case 1 – Correct Delegation

• ns1.zaib.net.
• ns2.zaib.net.

→ Reverse zone properly delegated.

Case 2 – Empty Result

No output returned.

→ Zone not delegated at registry.

Case 3 – NXDOMAIN

status: NXDOMAIN

→ Zone does not exist at parent.

Case 4 – Timeout

→ Possible firewall block or authoritative DNS unreachable.

Always test from an external VPS to avoid cached responses.

🎯 This improves clarity for mid-level engineers.

7️⃣ Functional PTR Test

for IP in 198.51.100.1 203.0.113.1 192.0.2.1
do
echo "Checking PTR for $IP"
dig -x $IP +short
echo
done

Run from external VPS for accurate validation.

What is Lame Delegation?

A lame delegation occurs when:

• The registry delegates a reverse zone to your NS
• But your nameserver does not properly serve the zone

Common causes:

• Zone file missing
• Wrong zone name
• Firewall blocking TCP 53
• BIND service down
• Incorrect SOA

Symptoms:

• dig NS 100.51.198.in-addr.arpa

Shows your NS, but:

• dig -x 198.51.100.1

Times out or fails. This is why delegation checks must be combined with live resolution tests.

8️⃣ Common ISP Mistakes

❌ Reverse zone created but not delegated
❌ Wrong reverse zone format
❌ Glue records missing
❌ Firewall blocking TCP 53
❌ Serial number not incremented
❌ Authoritative DNS behind NAT

Correct reverse format:

• 100.51.198.in-addr.arpa

Wrong:

• 198.51.100.in-addr.arpa

9️⃣ Quarterly Reverse DNS Audit Checklist

Infrastructure

• Two authoritative DNS servers
• Hosted on separate infrastructure
• TCP/UDP 53 publicly accessible
• Monitoring enabled

Reverse DNS

• All public pools delegated
• Consistent PTR naming policy
• Mail servers have matching A + PTR
• No stale PTR entries

Monitoring

• Delegation check via cron
• Alert on NXDOMAIN
• DNS service monitoring in NMS

Production DNS Monitoring Strategy

Reverse DNS must not only be configured — it must be continuously monitored. Recommended controls:

• Monitor TCP & UDP port 53 availability
• Monitor SOA serial changes
• Detect delegation changes
• Alert on NXDOMAIN responses
• Track response time from external probes

Recommended tools:

• LibreNMS
• Zabbix
• Nagios
• Cron-based dig monitoring scripts

Quarterly audits should include full reverse validation for all public pools.

🔟 Workflow for New Public IP Allocation

When ISP receives new /24:

1. Verify allocation ownership
2. Create reverse zone in BIND
3. Validate with named-checkzone
4. Configure registry delegation
5. Confirm using dig NS
6. Perform external PTR test

---

❌ Why You Cannot Use One File for All Pools

Because:

• Reverse DNS works on delegation boundaries
• Each /24 is delegated separately by upstream/RIPE/APNIC
• BIND loads zones individually
• A single file cannot serve multiple unrelated in-addr.arpa domains

🔎 Quick Diagnostic Table

Test	Command	What It Confirms
Ownership	whois IP	Who owns block
Delegation	dig NS zone	Is reverse delegated
Full path	dig +trace -x IP	Delegation chain
Public test	dig -x IP @8.8.8.8	Global visibility

🔥 Pro ISP Tip

Run from an external VPS (not your own DNS server) to avoid:

• Cached responses
• Local recursion masking delegation problems

---

Best Practices for Growing ISPs

✔ Version control zone files
✔ Separate recursive and authoritative DNS
✔ Automate reverse zone creation
✔ Maintain delegation inventory

Operational Workflow Summary

When receiving a new public /24 allocation:

1. Verify allocation ownership
2. Create reverse zone in BIND
3. Validate using named-checkzone
4. Configure delegation at registry
5. Confirm NS delegation publicly
6. Test PTR resolution externally
7. Document in IPAM
8. Add monitoring

This structured workflow prevents future operational issues.

---

Conclusion

Reverse DNS is:

• A reputation mechanism
• A compliance requirement
• An operational responsibility

Creating zone files is simple.
Maintaining delegation integrity and audit discipline is what makes an ISP production-grade.