radius-dns-sd (RADIUS DNS Service Discovery Backend)

The radius-dns-sd backend discovers upstream RADIUS servers dynamically using DNS Service Discovery (typically a choreography of NAPTR -> SRV -> A/AAAA lookups), then proxies authentication / authorization (and potentially accounting) requests to currently resolvable endpoints. It removes the need to hard-code server IPs and supports elastic / multi-region or rotating infrastructure.

When to Use

Core Elements

A discovered server inherits every applicable setting from server-template. If a dynamic endpoint later disappears from DNS, new requests will stop being routed to it once caches expire.

The template connect block can set independent deadlines for dns-timeout, connection-timeout, and TLS handshake-timeout. Each defaults to 5s.

The secret is required when DNS discovery can select the transport or when the template permits RADIUS/1.0. It may be omitted only when connect explicitly sets protocol tls; and its tls block sets exactly radius_versions 1.1;. This restriction prevents a discovered RADIUS/1.0 endpoint from being used without the shared secret required for packet authentication and attribute transforms.

Discovery Flow (Conceptual)

1. Iterate naptr-service entries in order:
   • Perform NAPTR query for each pattern.
   • For each resulting service, perform SRV lookups obtaining priority/weight/port/target.
2. Resolve target hostnames to A/AAAA addresses.
3. Construct candidate endpoint list (host/IP + port + transport protocol implied by pattern).
4. Apply load selection or fallback strategy implicitly (for DNS-SD backend the strategy is governed by current DNS answers; explicit server-selection is replaced by DNS weighting).
5. Proxy the request to a chosen endpoint.

Example

backends {
    radius-dns-sd "RADIUS_ROAMING" {
        naptr-service "_radius._udp";
        naptr-service "_radsec._tcp";
        challenge-timeout 5000;

        server-template {
            secret "FederationSecret2024!";
            timeout 4000;
            retries 1;
            status true;
            connections {
                max 8;
                min 1;
                idle-timeout 300;
            }
            # Optionally override transport if discovery lacks explicit hints:
            # connect { protocol tls; }
        }

        @pre-proxying {
            filter {
                # Remove sensitive local-only attributes if needed
                # Tunnel-Password;
            }
            modify {
                # Example (pseudo):
                # radiusproxy.request.attr.Operator-Name := "EXAMPLE_REALM";
            }
        }

        @post-proxying {
            filter {
                # Strip vendor attributes not permitted downstream
                # vendor-specific;
            }
        }
    }
}

> **Note:** The `@` prefix is required for pipeline blocks. The legacy syntax without `@` (e.g., `pre-proxying {}`, `post-proxying {}`) is deprecated and emits warnings. Use `@pre-proxying {}` and `@post-proxying {}` for new configurations.

naptr-service

Ordered preference. First successful pattern anchors subsequent SRV queries. A common deployment might start with secure transport (_radsec._tcp) and fall back to _radius._udp if secure endpoints are not yet published. Repeat the statement for each pattern:

naptr-service "_radsec._tcp";
naptr-service "_radius._udp";

Server Template Fields

If DNS returns transport explicitly (e.g. from the NAPTR service pattern), those should take precedence internally; the connect override is a fallback hint.

The connect block accepts:

• protocol - Transport protocol: udp, tcp, or tls.
• buffer - Requested receive and send socket buffer size in bytes. The default is 1048576.
• tls { ... } - TLS configuration block (when using tls protocol).