Create NAPTR Records in DNS for Improved International Roaming

In July 2018, the South Africa eduroam NRO introduced support for RadSec and dynamic realm routing on the two federation-level RADIUS servers. Coupled together, these two things dramatically improve the efficiency and security of international roaming.

In order to take advantage of this development, identity providers need to make a small change in their DNS. Any institution that regularly has users travelling outside South Africa is strongly encouraged to make this change.

What you need to do

You need to add the following DNS NAPTR record for each realm your users might use: IN NAPTR 100 10 "S" "x-eduroam:radius.tls" ""

If you have more than one realm (e.g. and, you need to create a separate NAPTR record for each realm your users might use, even if you're relying on sub-realm routing in your RADIUS configuration.

How you do this will depend on what DNS software you use:

  • In BIND you can copy-and-paste the above record. You should enter the record exactly as-is, varying only the bit to match your own realm.

  • Jisc has helpfully provided documentation on how to add NAPTR records in Windows DNS. If you follow their documentation, you only need to complete up-to step 5 and the replacement string must be as above (NB: you do not need to create an SRV record per step 6 onwards).

  • In other DNS software, the required fields in the NAPTR record are as follows: Order = 100; Preference = 10; Flags = S; Service = x-eduroam:radius.tls; Regexp should be blank; Replacement =

If you have any questions or need assistance, please get hold of us.

Testing and monitoring

Our monitoring system checks for NAPTR records and ensure they're correctly formatted.

Institutions that have enrolled in eduroam CAT can use CAT's "Check realm reachability" function to check that everything is working (see the dynamic connectivity tab).

Technical explanation

TL;DR - the following is background for those who're interested; you don't need to understand this to take advantage of NAPTR, and can stop reading if you want.

Dynamic realm routing uses DNS records to determine the correct RADIUS server to route requests to.

RadSec is an extension to RADIUS that allows it to run over TCP secured by TLS/SSL. eduroam's implementation of this uses mutual certificate authentication to establish the trust relationship between the various roaming operators who're implementing it. This way we can connect directly to another NRO (bypassing the ETLR servers) and they can still have confidence that we're really part of eduroam.

The NAPTR record you create in DNS tells other eduroam NROs that your realm can support RadSec, and where to find more details. It points at the SRV record at, which in turn provides details of the South African FLR servers that support RadSec. This separation puts you in control of how your realm routes, and puts the operational details of the FLR servers under our control.

By making use of DNS, we can connect directly to the correct roaming operator rather than following the traditional eduroam hierarchy via the top-level RADIUS servers in Europe. This means more efficient paths, fewer points of failure, and lower latencies for authentication. Historically, if a South African user travelled to Kenya and used eduroam there, their authentication would route from Kenya up the East coast of Africa, through the Mediterranean, across Europe to Denmark and then back to South Africa along the West cost of Africa; with dynamic realm routing, we can take advantage of the much shorter East-African fibre route and connect directly from Kenya to South Africa.

Cross-border RADIUS between NROs that support it will be done using RadSec, but our FLR servers will still talk traditional RADIUS-over-UDP to your institutional identity provider. This means you do not need to understand how to implement RadSec on your own RADIUS servers in order to take advantage of the improved efficiency.

GÉANT have published a more comprehensive explanation of how this works.