Set up of Dynamic Discovery (in federations which have RADIUS/TLS enabled)
What is Dynamic Discovery?
eduroam has traditionally used a hierarchy of RADIUS servers. All national roaming authentication traffic was aggregated into a national proxy server; all international roaming traffic was aggregated into a set of international proxy servers.
While this works quite well under most circumstances, there are some drawbacks in efficiency, and a rather unpleasant inflexibility when it comes to routing realms which do not fit into the national aggregations model because they do not use the national .TLD ending of their federation (e.g. realms in ".net", ".org", etc.).
Dynamic Discovery places routing hints towards the responsible authentication server or national proxy into DNS, making routing more efficient.
As an IdP, you do not have to know much about the mechanics behind this - the only required step to make your realm dynamically discoverable is by adding a single resource record into your domain's DNS zone.
While adding this DNS record is optional, it has advantages for you in that it reduces the time it takes to authenticate your users when roaming internationally, so eduroam Operations RECOMMENDS to add these records if your national federation supports dynamic discovery.
For realms in generic top-level domains like .net, .org, .com etc. it is also RECOMMENDED to add these entries; and it may become mandatory at a later point in time.
Adding Dynamic Discovery hints to the IdP's DNS zone
To add Dynamic Discovery hints to your zone, you must first contact your national eduroam operator to determine which target name they have set up on the national proxy server; because you need to enter that discovery target in your DNS entry. In this documentation example, let's assume your national operator told you that the target name in your federation "Antarctica" is "_radsec._tcp.eduroam.aq". Let's further assume that your realm for eduroam and DNS domain is "greatidp.aq".
The DNS entry is of resource record type Network Authority PoinTeR (NAPTR). These records look quite complex, but eduroam's deployment profile of the NAPTR is making it simple to understand. The full entry as required for eduroam dynamic discovery in your DNS zone is:
greatidp.aq. 43200 IN NAPTR 100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.eduroam.aq.
This is all! This entry says, paraphrased, "The eduroam authentication for the realm greatidp.aq works over RADIUS with TLS encryption and is handled by the service target "_radsec._tcp.eduroam.aq". Note that this does not replace your normal RADIUS uplink to your national server; this is only an additional hint to streamline international roaming.
Don't worry, RADIUS software knows how to interpret this further 
If you are curious though, the next section explains what all these entries mean.
NAPTR explained
NAPTR records are more complex than, say, "A" records - the A record has only one piece of information to convey, namely the IP address which belongs to a name.
In contrast to that, NAPTR records are a generic entry to any kind of service. As such, it needs to specify which service this particular NAPTR entry is for, how that service is handled, and finally, who is handling it. It also provides basic failover and load-balancing mechanisms; there can be multiple NAPTR entries for the same service, with different priority and different weighting.
So let's take a look at the parts of the above entry:
| Entry | Meaning |
|---|---|
| greatidp.aq. | This is the zone name (label) for which the NAPTR entry is defined |
| 43200 | DNS caching lifetime of the entry (just like any other DNS resource record) |
| IN | This entry is meant for consumption in the INternet (just like any other DNS resource record) |
| NAPTR | This entry is a Network Authority PoinTeR |
| 100 | Order: if multiple NAPTR entries are defined for the label, prefer lower order number over higher ones (Note: since eduroam requires only one single entry, any number is fine here, unless your national federation operator instructs you otherwise) |
| 10 | Preference: if multiple NAPTR entries with the same Order are defined for this label, alternate between all those entries when resolving names (Note: since eduroam requires only one single entry, any number is fine here, unless your national federation operator instructs you otherwise) |
| "s" | This NAPTR entry should be resolved to hostnames by doing a subsequent SRV lookup on the target label (Note: eduroam only works with "s" labels; it is a configuration error to use "a" or "u" targets) |
| "x-eduroam:radius.tls" | This is the service; only resolve the later target name if you want to use the service - otherwise ignore the NAPTR response (Note: this string is fixed in eduroam, as the roaming service with Dynamic Discovery is exclusively defined for RADIUS/TLS) |
| "" | Regular Expression: some very advanced uses of NAPTR records allow transformation of target names according to regular expressions. (Note: eduroam does not make use of this feature. The regular expression field MUST be the empty string; it is a configuration error to speciffy anything else) |
| _radsec._tcp.eduroam.aq | The target: please contact this server (after resolving its IP addresses and port numbers) if you want to use the "x-eduroam" service |
At this point you may wonder: so how does this eventually yield an IP address of my national authentication server?
The answer is: this is a first step of DNS resolution (and the only one you need to actively help with). The later steps are:
1) The server which queried for this NAPTR record will get the reply that he should resolve an SRV record (remember the "s" ?) of the target name "_radsec._tcp.eduroam.aq".
2) The querying server will then query the label _radsec._tcp.eduroam.aq and check for SRV records. The eduroam.aq zone is managed by your national eduroam admins, and the reply could look like the following:
_radsec._tcp.eduroam.aq. 43200 IN SRV 10 0 2083 tld2.eduroam.aq.
_radsec._tcp.eduroam.aq. 43200 IN SRV 0 0 2083 tld1.eduroam.aq.
As you see, this reply contains two hostnames of the national eduroam servers, and also the port number to connect to (2083).
Finally, the querying server will then either ask for A or AAAA records to get to the IP address of the responsible server - and the discovery process is complete.