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
| Scenario | Benefit |
|---|---|
| Large distributed RADIUS deployment | Automatic endpoint rotation & scaling |
| Roaming / federation environment | Seamless partner endpoint changes via DNS |
| Zero/low manual reconfiguration | Updates propagate through DNS TTL changes |
| Multi-protocol migrations (e.g. adding RadSec) | Controlled adoption by publishing new NAPTR records |
Core Elements
| Directive / Block | Required | Description |
|---|---|---|
naptr_patterns [...] | Yes | Ordered list of NAPTR service names (e.g. _radius._udp, _radsec._tcp) to attempt. |
challenge_timeout <ms>; | Yes | Timeout for Access-Challenge / round-trip operations. |
server_template { ... } | Yes | Default parameters (secret, timeouts, retries, status, etc.) applied to discovered endpoints. |
pre-proxying { ... } | No | Modify / filter request before upstream forwarding. |
post-proxying { ... } | No | Modify / filter reply before returning to client. |
statistics { ... } | No | Optional 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)
- Iterate
naptr_patternsin order:- Perform NAPTR query for each pattern.
- For each resulting service, perform SRV lookups obtaining priority/weight/port/target.
- Resolve target hostnames to A/AAAA addresses.
- Construct candidate endpoint list (host/IP + port + transport protocol implied by pattern).
- Apply load selection or fallback strategy implicitly (for DNS-SD backend the strategy is governed by current DNS answers; explicit
server-selectionis replaced by DNS weighting). - 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
| Field | Purpose |
|---|---|
secret | Shared secret used for signing/encrypting RADIUS messages with discovered endpoints. |
timeout | Milliseconds to wait per request (excluding retries). |
retries | How many retransmissions before marking attempt failed. |
status | Enables Status-Server health polling if supported. |
connections | Maximum concurrent transport connections (mainly for TCP/TLS). |
idle_timeout | Connection 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.