DNS Delegation

When managing domain name infrastructure, there comes a time when offloading specific subdomains to specialized DNS servers becomes necessary. Whether you are setting up Global Server Load Balancing (GSLB), dynamic geolocation-based routing, or simply distributing control across team boundaries, DNS Delegation is the standard architectural pattern.

In this guide, we will walk through the conceptual underpinnings of DNS delegation and demonstrate how to delegate the subdomain gslb.roshankhatri8848.com.np from a parent zone (roshankhatri08.com.np) to an authoritative PowerDNS server.

What is DNS Delegation?

DNS delegation is the mechanism where a parent domain assigns authority over a specific subdomain (child zone) to a set of external, authoritative DNS servers.

Instead of handling query responses directly for gslb.roshankhatri8848.com.np on the primary nameservers, the primary zone simply points recursive DNS resolvers to a different set of nameservers equipped to handle queries for that specific subdomain.

Why Delegate to PowerDNS for GSLB?

Dynamic Routing & Geolocation: PowerDNS supports plugins and backends (like pipe or lua) that allow dynamic DNS response generation based on requester IP or health metrics.
Separation of Concerns: Keep core domain records (A, MX, TXT) on your stable static DNS servers while isolating high-frequency, dynamic traffic to dedicated GSLB instances.
High Availability & Scalability: Scales independent GSLB clusters without altering base domain zone files.

Architectural Overview

Let’s define our environment details:

Parent Zone: roshankhatri08.com.np
Subdomain to Delegate: gslb.roshankhatri8848.com.np
Target PowerDNS Server Name: ns1.gslb.roshankhatri8848.com.np
PowerDNS Server Public IP: 192.0.2.53 (Example IPv4)

                       [ Recursive DNS Resolver ]
                                   │
                1. Query: gslb.roshankhatri8848.com.np
                                   │
                                   ▼
              [ Parent NS: roshankhatri08.com.np ]
                                   │
         2. Referral (NS + Glue Record):
            - NS: ns1.gslb.roshankhatri8848.com.np
            - A:  192.0.2.53
                                   │
                                   ▼
             [ Child NS: PowerDNS Authoritative Server ]
                       (192.0.2.53 / Port 53)
                                   │
         3. Authoritative Answer: e.g., 203.0.113.10

Step-by-Step Implementation

Step 1: Configure the Parent Zone (`roshankhatri08.com.np`)

To establish delegation, you must add NS (Nameserver) records in the parent zone pointing to the delegated subdomain, alongside a Glue Record (A/AAAA record) if the child nameserver resides within the delegated subdomain itself.

Adding the Records to Parent Zone File:

; Parent Zone: roshankhatri08.com.np

; Glue Record (In-Bailiwick Nameserver IP)
ns1.gslb.roshankhatri8848.com.np.    IN    A    192.0.2.53

; Delegation NS Records
gslb.roshankhatri8848.com.np.        IN    NS   ns1.gslb.roshankhatri8848.com.np.

Why is the Glue Record needed? Because ns1.gslb.roshankhatri8848.com.np exists inside the subdomain being delegated (gslb.roshankhatri8848.com.np), resolvers would fall into a circular lookup dependency without an explicit IP provided at the parent level.

Step 2: Configure PowerDNS Authoritative Server

Now, let's configure the PowerDNS server (192.0.2.53) to act as the authoritative nameserver for gslb.roshankhatri8848.com.np.

1. Install PowerDNS

On Ubuntu/Debian:

sudo apt update
sudo apt install pdns-server pdns-backend-sqlite3 -y

2. Configure `/etc/powerdns/pdns.conf`

Ensure basic binding and listening configurations are active:

launch=gsqlite3
gsqlite3-database=/var/lib/powerdns/pdns.sqlite3
local-address=0.0.0.0
local-port=53
master=yes
dnssec=off

Initialize the SQLite database schema if required (usually handled automatically by default scripts on Ubuntu/Debian packages).

3. Create the Zone using `pdnsutil`

Execute the following commands to set up the child zone on the PowerDNS instance:

# 1. Create the new zone
sudo pdnsutil create-zone gslb.roshankhatri8848.com.np ns1.gslb.roshankhatri8848.com.np

# 2. Add self-referencing NS record
sudo pdnsutil add-record gslb.roshankhatri8848.com.np @ NS ns1.gslb.roshankhatri8848.com.np

# 3. Add A record for the nameserver itself
sudo pdnsutil add-record gslb.roshankhatri8848.com.np ns1 A 192.0.2.53

# 4. Add GSLB endpoints (e.g., app endpoint)
sudo pdnsutil add-record gslb.roshankhatri8848.com.np app A 203.0.113.10

Step 3: Verification & Testing

Once both parent and child servers are configured and zone files/databases reloaded, test the delegation flow.

1. Direct Query to PowerDNS Server

Check if PowerDNS answers authoritatively for the target record:

dig @192.0.2.53 app.gslb.roshankhatri8848.com.np A +norecurse

Expected Output: Should return status: NOERROR with flags: qr aa (Authoritative Answer) and the IP 203.0.113.10.

2. Trace Delegation from Root / Parent

Verify that recursive resolvers follow the referral chain correctly:

dig +trace app.gslb.roshankhatri8848.com.np A

In the dig +trace output, you should observe: 1. Referral from .np TLD servers to roshankhatri08.com.np NS. 2. Referral from roshankhatri08.com.np to ns1.gslb.roshankhatri8848.com.np (192.0.2.53). 3. Final authoritative response returned directly from PowerDNS.

Common Pitfalls to Avoid

Missing Glue Records: If your delegated NS resides within the delegated child zone, forgetting the glue record on the parent zone causes lookup loops.
Firewall Blocking Port 53: Ensure UDP and TCP port 53 are open on the PowerDNS host (192.0.2.53).
Lame Delegation: Occurs when the parent delegates to a child NS, but the child NS is not configured to answer authoritatively for the zone. Always ensure create-zone is complete in PowerDNS before adding parent NS records.