NAPTR – Name Authority Pointer

A Name Authority Pointer (NAPTR) is a type of resource record in the Domain Name System of the Internet

NAPTR records are most commonly used for applications in Internet telephony, for example, in the mapping of servers and user addresses in the Session Initiation Protocol (SIP). The combination of NAPTR records with Service Records (SRV) allows the chaining of multiple records to form complex rewrite rules which produce new domain labels or uniform resource identifiers (URIs).

# host -t NAPTR example.com
example.com NAPTR 10 100 “S” “SIP+D2U” “” _sip._udp.example.com.
example.com NAPTR 20 100 “S” “SIP+D2T” “” _sip._tcp.example.com.
example.com NAPTR 30 100 “S” “E2U+email” “!^.*$!mailto:info@example.com!i” _sip._tcp.example.com.

 

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.