Documentation

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

ScenarioBenefit
Large distributed RADIUS deploymentAutomatic endpoint rotation & scaling
Roaming / federation environmentSeamless partner endpoint changes via DNS
Zero/low manual reconfigurationUpdates propagate through DNS TTL changes
Multi-protocol migrations (e.g. adding RadSec)Controlled adoption by publishing new NAPTR records

Core Elements

Directive / BlockRequiredDescription
naptr_patterns [...]YesOrdered list of NAPTR service names (e.g. _radius._udp, _radsec._tcp) to attempt.
challenge_timeout <ms>;YesTimeout for Access-Challenge / round-trip operations.
server_template { ... }YesDefault parameters (secret, timeouts, retries, status, etc.) applied to discovered endpoints.
pre-proxying { ... }NoModify / filter request before upstream forwarding.
post-proxying { ... }NoModify / filter reply before returning to client.
statistics { ... }NoOptional metrics configuration if supported.

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.

Discovery Flow (Conceptual)

  1. Iterate naptr_patterns 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_patterns ["_radius._udp", "_radsec._tcp"];
        challenge_timeout 5000;

        server_template {
            secret "FederationSecret2024!";
            timeout 4000;
            retries 1;
            status true;
            connections 8;
            idle_timeout 300;
            # Optionally override transport if discovery lacks explicit hints:
            # connect { protocol udp; port 1812; }
        }

        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;
            }
        }
    }
}

naptr_patterns

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.

naptr_patterns ["_radsec._tcp","_radius._udp"];

Server Template Fields

FieldPurpose
secretShared secret used for signing/encrypting RADIUS messages with discovered endpoints.
timeoutMilliseconds to wait per request (excluding retries).
retriesHow many retransmissions before marking attempt failed.
statusEnables Status-Server health polling if supported.
connectionsMaximum concurrent transport connections (mainly for TCP/TLS).
idle_timeoutConnection idle close threshold (TCP/TLS).
connect { ... }Optional override (protocol, port) if DNS data insufficient.

If DNS returns port/transport explicitly (e.g. SRV), those should take precedence internally; the connect override is a fallback hint.

Navigation
Parents