When configuring BIND (Berkeley Internet Name Domain), two critical concepts often cause confusion: recursion and forwarding. Both relate to how DNS queries are resolved, but they serve different purposes and have distinct security implications. This article clarifies their differences, use cases, and potential risks.

Recursion occurs when a DNS server resolves queries on behalf of clients by traversing the DNS hierarchy. Here’s a simplified example of enabling recursion in named.conf:

options {
    recursion yes;
    allow-recursion { trusted-clients; };
};

Key characteristics:

• The server queries root servers, TLDs, and authoritative servers
• Builds a complete resolution path for the client
• Caches results for future queries

Forwarding directs queries to specific upstream resolvers instead of performing full recursion. Example configuration:

options {
    forwarders { 8.8.8.8; 1.1.1.1; };
    forward only; // or "first" to try forwarders before recursion
};

Key differences from recursion:

• Relies on designated resolver(s) to handle the heavy lifting
• Typically faster for local networks with good upstream connections
• Can create dependency on forwarders' availability

While both features can be abused for amplification attacks, they present different risk profiles:

Feature	Attack Surface	Mitigation
Recursion	Open to internet (worst case)	Restrict to trusted clients
Forwarding	Limited to forwarder infrastructure	Use internal forwarders only

Forwarding generally offers better performance for:

• Networks behind restrictive firewalls
• Organizations with limited bandwidth
• Scenarios where upstream resolvers have better cache hit rates

Recursion provides more control but requires:

• Proper root hints configuration
• Adequate server resources
• Careful cache management

Many real-world implementations combine both methods. This example shows conditional forwarding:

options {
    recursion yes;
    allow-recursion { localnets; };
};

zone "internal.example.com" {
    type forward;
    forwarders { 10.0.0.53; };
};

This configuration:

• Allows recursion for internal clients
• Forwards specific domains to designated resolvers
• Maintains security while optimizing resolution paths

For most deployments:

1. Disable open recursion (restrict to authorized clients)
2. Use forwarding for external resolution when appropriate
3. Monitor query patterns for abuse
4. Consider using Response Rate Limiting (RRL)

---

In BIND (Berkeley Internet Name Domain), recursive queries and forwarding serve distinct purposes in DNS resolution:

• Recursive queries: The DNS server does all the work to resolve the query by contacting multiple authoritative servers
• Forwarding: The DNS server delegates resolution to another designated resolver

Open recursion (allowing recursive queries from any client) is dangerous because:

// Bad practice - open recursion
options {
    recursion yes;
    allow-recursion { any; };
};

Whereas forwarding is safer as it only sends queries to trusted resolvers:

// Safe forwarding configuration
options {
    forward only;
    forwarders {
        8.8.8.8;
        1.1.1.1;
    };
};

Forwarding typically provides faster responses since the forwarder likely has cached results. Recursive resolution must traverse the DNS hierarchy for each unique query:

// Mixed configuration example
options {
    recursion yes;
    allow-recursion { 192.168.1.0/24; };
    forwarders {
        192.168.1.100;
    };
    forward first;
};

For enterprise networks, a common pattern is:

• Internal clients → Local recursive resolver (restricted recursion)
• Local resolver → Forward to ISP or public resolver
• For internal zones → Authoritative answers

// Enterprise configuration example
acl internal { 10.0.0.0/8; 192.168.0.0/16; };

options {
    recursion yes;
    allow-recursion { internal; };
    allow-query { internal; };
    forwarders {
        10.1.1.1;  // Corporate resolver
    };
    forward only;
};

zone "internal.example.com" {
    type master;
    file "/etc/bind/db.internal.example.com";
};

To protect against amplification attacks:

// Secure recursive configuration
options {
    recursion yes;
    allow-recursion { trusted-clients; };
    rate-limit {
        responses-per-second 10;
    };
    // Additional protections
    max-cache-size 90%;
    max-cache-ttl 3600;
};