Table of Contents Table of contents: Radiator® AAA Server <AddressAllocator DHCPv6> 3.116 - <AddressAllocator DHCPv6> <ServerDIAMETER> 3.118 - <ServerDIAMETER>

3.117. <Resolver>

<Resolver> provides DNS and name resolution services for the <AuthBy DNSROAM> clause. For more information, see Section 3.75. <AuthBy DNSROAM>. Use <Resolver> only if you use <AuthBy DNSROAM> in your configuration. Other AuthBys do not require using <Resolver>.
<AuthBy DNSROAM> uses <Resolver> to do NAPTR, SRV, A, and AAAA lookups on a DNS name server in order to discover the name, address, and other possible attributes, such as protocol and whether to use TLS encryption, of a server that is used to handle requests for a certain Realm.
By default, <Resolver> consults DNS using the standard resolver configuration for your host. On Unix or Linux systems, it finds the resolver details by consulting /etc/ resolv.conf, $HOME/.resolv.conf or ./.resolv.conf. You can override these defaults and specify the used DNS name server, search path, and other options by using parameters in the Resolver clause.
<Resolver> requires the Net::DNS Perl module. Depending on the Net::DNS and Perl version, it may require the Socket6 module and the IO::Socket::INET6 module if you want to consult a DNS server via IPv6. These are all available as source from CPAN, or possibly as pre-built packages for your operating system or Perl distribution. For more information, see Section 2.1.2. CPAN.
<Resolver> uses the following algorithm to discover server names and addresses for a given Realm:
  1. Look for NAPTR records for the Realm.
  2. For each found NAPTR record, examine the Service field and use it to determine the transport protocol and TLS requirements for the server. The Service field starts with 'AAA' for insecure and 'AAAS' for TLS secured. The Service field contains '+RADSECS' for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' for RADIUS protocol over UDP. The most common Service field is 'AAAS+RADSECT' for TLS secured RadSec over TCP.
  3. If the NAPTR has the 'S' flag, look for SRV records for the name. For each SRV record found, note the Port number and look for A and AAAA records corresponding to the name in the SRV record.
  4. If the NAPTR has the 'A' flag, look for A and AAAA records for the name.
  5. If no NAPTR records are found and DirectAddressLookup is enabled, look for A and AAAA records based directly on the realm name. For example, if the realm is 'examplerealm.edu', it looks for records such as '_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu' and '_radius._udp.examplerealm.edu'.
  6. All A and AAAA records found are ordered according to their Order and Preference fields. The most preferable server address is used as the target server address, along with any other server attributes discovered from DNS. If no SRV records was found for the address, the DNSROAM configured Port is used.
For example, if the user name is fred@example.com, the Realm is 'example.com', and DNS contains the following records:
example.com.IN NAPTR 50 50 "s" "AAAS+RADSECT" "" _radsec._tcp.example.com.
_radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com.
radsec.example.com. IN AAAA 2001:db8::202:44ff:fe0a:f704
In the previous example, the selected target is a RadSec server on port 2083 at IPv6 address 2001:db8::202:44ff:fe0a:f704. The connection is made over TCP/IP, and TLS encryption is used. This complete specification of the realm is the most flexible and is recommended.
More concise DNS configurations are possible, too:
example.com. IN NAPTR 50 50 "a" "AAAS+RADSECS" "" radsec.example.com.
radsec.example.com. IN AAAA 2001:db8::202:44ff:fe0a:f704
In this case, the selected target is a RadSec server at IPv6 address 2001:db8::202:44ff:fe0a:f704. The connection is made over SCTP, and TLS encryption is used. The port used is the default Port configured into <AuthBy DNSROAM>.
The DNS can contain just this record:
_radius._udp.example.com. IN A 203.0.113.10
In this case, the selected target is a RADIUS server at IPv4 address 203.0.113.10. The connection is made over UDP. The Port and Secret used are the defaults configured into <AuthBy DNSROAM>.
Tip
The simplest Resolver clause you can have is: 
<Resolver>
</Resolver>
This definition gets all its configuration from /etc/resolv.conf or the equivalent on your platform.

3.117.1. Nameservers

This optional parameter specifies the name or address of one or more DNS Name Servers passed to Net::DNS. Nameservers with IPv6 addresses are supported if your system supports IPv6. Defaults to the value of nameserver in resolv.conf. For more information, see Section 3.117. <Resolver>.
Note
Current Net::DNS implementations appear not to use multiple nameservers with the bgsend method Radiator uses. Only the first server is used for the query. 
# Look first on one server and then another if it times out:
Nameservers 203.63.154.100
Nameservers 203.63.154.101

3.117.2. Debug

This optional flag enables debugging within the Net::DNS module. It will print to stdout the details of all DNS requests sent and replies received. Defaults to no debugging.
# Enable debug logging in Net::DNS:
Debug
If Radiator starts with systemd, you can make a local systemd configuration change to redirect stdout and stderr to a file. For the details, see Section 5.1. Systemd service unit file

3.117.3. Recurse

This optional flag enables recursive DNS lookups. Defaults to no recurse.

3.117.4. TCPTimeout

This optional flag specifies the timeout (in seconds) for DNS lookups over TCP connections. Defaults to 5 seconds.

3.117.5. UDPTimeout

This optional flag specifies the timeout (in seconds) for DNS lookups over UDP connections. Defaults to 5 seconds.

3.117.6. TCPPersistent

Note
This parameter is obsolete since Radiator 4.20. Multiple outstanding queries are not supported by Net::DNS when using persistent sockets.
This optional flag tells Net::DNS to keep a TCP socket open for each host:port to which it connects. This is useful if you are using TCP and need to make a lot of queries to the same nameserver. The default value is false.

3.117.7. UDPPersistent

Note
This parameter is obsolete since Radiator 4.20 Multiple outstanding queries are not supported by Net::DND when using persistent sockets.
This optional flag tells Net::DNS to keep a single UDP socket open for all DNS queries. This is useful if you are using UDP and need to make a lot of queries to the same nameserver. The default value is false.

3.117.8. GetIPV4

This optional flag specifies whether Resolver will attempt to find an IPv4 (A) address for any names it discovers. Defaults to true.

3.117.9. GetIPV6

This optional flag specifies whether Resolver will attempt to find an IPv6 (AAAA) address for any names it discovers. Defaults to true.

3.117.10. GetRadius

This optional parameter specifies whether Resolver is required to attempt to discover RADIUS servers from
  • NAPTR records of type AAA with +RADIUS
  • IPv4 (A) or IPv6 (AAAA) records for ‘_radius._udp.realmname’
Defaults to true.

3.117.11. GetRadSec

This optional parameter specifies whether Resolver is required to attempt to discover RADSEC servers from
  • NAPTR records of type AAA or AAAS with +RADSECS or +RADSECT or
  • IPv4 (A) or IPv6 (AAAA) records for '_radsec._sctp.realmname'
  • IPv4 (A) or IPv6 (AAAA) records for '_radsec._tcp.realmname'
Defaults to true.

3.117.12. DirectAddressLookup

If DirectAddressLookup is enabled, and if there are no NAPTR records for the requested Realm, Resolver will attempt lookups of A and AAAA records for _radsec._ sctp.<REALM>, _radsec._tcp.<REALM> and _radius._udp.<REALM> Enabled by default.

3.117.13. NAPTR-Pattern

NAPTR-Pattern is an optional parameter that specifies a regexp that will be used to match the contents of NAPTR records during Resolver service discovery.
If NAPTR-Pattern is defined and matches a NAPTR DNS record, it will be used to determine the protocol and transport to be used. The regexp is expected to match 2 substrings. The first is the protocol and can be 'radsec' or 'radius'. The second is the transport to use, and can be 'tls', 'tcp' or 'udp'.

3.117.14. NegativeCacheTtl

This optional value specifies how long a negative lookup (ie failure to resolve the realm) will be cached until another lookup will be made. Defaults to 21600 seconds (6 hours).

3.117.15. FailureBackoffTime

If the lookup failed to discover any results and there was a timeout when waiting for the nameserver, this optional value specifies how long Radiator will wait before another lookup will be made. This will give the target server time to become available without resorting to potentially long NegativeCacheTtl. Defaults to 3 seconds.
Table of Contents Table of contents: Radiator® AAA Server <AddressAllocator DHCPv6> 3.116 - <AddressAllocator DHCPv6> <ServerDIAMETER> 3.118 - <ServerDIAMETER>