performs a NAPTR query

Question 1

The RFC you are looking for is "Session Initiation Protocol (SIP): Locating SIP Servers".

Here's an abbreviated summary of how to select the transport protocol and resolve the SIP server address.

If transport parameter is specified it takes precedence,
If no transport parameter and target is an IP address then sip should use udp and sips tcp,
If no transport parameter and target is a host name with an explicit port then sip should use udp and sips tcp and host should be resolved using an A or AAAA record DNS lookup (section 4.2),
If no transport protocol and no explicit port and target is a host name then the client should do an NAPTR lookup and utilise records for services SIP+D2U, SIP+D2T, SIP+D2S, SIPS+D2T and SIPS+D2S,
If NAPTR record(s) are found select the desired transport and lookup the SRV record,
If no NAPTR records are found lookup SRV record for desired protocol _sip._udp, _sip._tcp, _sips._tcp, _sip._tls,
If no SRV records found lookup A or AAAA record.

In the real World virtually no SIP providers use NAPTR records, probably half or less use SRV records and the rest rely solely on A records. In my own SIP software I turned off the NAPTR lookup since it just wasted time and it's highly likely that if a SIP provider has bothered to set up NAPTR records they are also going to have set up the standard SRV records.

In hindsight the SIP protocol designers should probably have left the whole SIP server address resolution alone and let implementers use standard IP load balancing and failover mechanisms. Because SIP clients don't all support SRV records, again in my experience less than half, using such records is better than nothing but is not a great solution for failover or load balancing.

If you are looking for a hostname with SIP NAPTR records try columbia.edu and snom.com last time I checked they both had some.

Question 2

A NAPTR record in DNS is just like any other record in DNS (SRV, CNAME, etc.)

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).

The DNS type code for the NAPTR record is 35.

To query for them you can use the command line tool dig and specify the type of query using the -t switch. For example:

$ dig -t naptr 4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa

; <<>> DiG 9.10.6 <<>> -t naptr 4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64886
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN  NAPTR

;; ANSWER SECTION:
4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa. 86400 IN NAPTR 100 20 "u" "E2U+pstn:tel" "!^(.*)$!tel:\\1!" .
4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa. 86400 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+441865332(.*)$!sip:\\1@nominet.org.uk!" .

;; Query time: 356 msec
;; SERVER: 192.168.1.85#53(192.168.1.85)
;; WHEN: Sat Oct 13 12:31:29 EDT 2018
;; MSG SIZE  rcvd: 179

You can read more about E.164 & ENUM if you're interested:

Question 3

NAPTR records and SRV records are common in LTE (4G) solution. EPC nodes (network node) use DNS to select other EPC nodes using S-NAPTR & SRV records. This gives operator lot of freedom in adding/removing the nodes without changing any configuration on the MME node. You can refer to some of the 3gpp standards 29.003 or 23.401 or google on the topic "epc node selections using DNS" . https://ericlajoie.com/nodeselection.html