Name Authority Pointer
Il Name Authority Pointer (NAPTR) è un tipo di record di risorse nel DNS (Domain Name System) di Internet.
I record NAPTR sono usati principalmente da applicativi di telefonia Internet (VOIP), ad esempio nella mappatura tra i server e gli indirizzi utente del protocollo SIP - Session Initiation Protocol - utilizzato per questo tipo di chiamate. La combinazione di record DNS del tipo NAPTR con record DNS del tipo Service Records (SRV) permette il concatenamento di record multipli che vanno a formare complesse regole di riscrittura che producono una nuova etichetta di dominio o uniform resource identifiers (URIs).
Il codice del tipo di record DNS NAPTR è 35.[1]
Razionale
modificaGli Uniform Resource Names (URNs) sono un sottoinsieme di Uniform Resource Identifiers (URIs) usati come identificatori astratti, tipo il nome delle persone o il loro numero di telefono. Perché gli URN siano significativi, questi devono essere mappati a delle risorse concrete di qualche tipo. Gli Uniform Resource Locators (URLs) sono spesso utilizzati per descrivere tali risorse, come un nome macchina (hostname), o un file locale.
Il NAPTR record aiuta la standardizzazione degli URNs. I records NAPTR costituiscono dei riferimenti tra insiemi di URNs, URLs e nomi di dominio in chiaro, suggerendo all'utilizzatore i protocolli disponibili per la comunicazione tra le risorse. Ogni record NAPTR è costituito da un service name, un insieme di flags, un'espressione regolare, un ordinale, una preferenza e un pattern di sostituzione. Records multipli possono essere concatenati assieme in cascata per riscrivere degli URIs in maniera deterministica. Queste regole di concatenazione sono state standardizzate nelle RFC2915 e RFC3403.
Esempio
modificaUn uso comune dei record NAPTR è quello fatto dal SIP - Session Initiation Protocol -, dove questi sono utilizzati per instradare il traffico telefonico delle varie sessioni avvalendosi delle reti IP. Per esempio, il SIP URN utilizzato dal numero di telefono 1-800-555-1234 potrebbe essere tel:+1-800-555-1234 e il suo nome di dominio 4.3.2.1.5.5.5.0.0.8.1.e164.arpa. Il client SIP che interroga quel nome riceverebbe :
$ORIGIN 4.3.2.1.5.5.5.0.0.8.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:customer-service@example.com!" . IN NAPTR 102 10 "U" "E2U+email" "!^.*$!mailto:information@example.com!" .
Il primo record ha un ordinale di 100, che è più basso di 102 e per questo ha la precedenza. La preferenza di 10 è ininfluente in quanto non ci sono altre regole con lo stesso ordinale 100. Il service name E2U+sip iè una stringa ENUM che indica che il record può essere utilizzato nelle interrogazioni da numero di telefono-a-SIP-URI. il client applica l'espressione regolare !^.*$!sip:customer-service@example.com!, che sostituisce l'intero URN tel:+1-800-555-1234 con sip:customer-service@example.com. il flag U indica che la stringa sostituita è un SIP URN, e che non ci sono altre regole da applicare.
Per risolvere il SIP URN, il client esegue un secondo NAPTR lookup— ad example.com, ottenendo:
$ORIGIN example.com. IN NAPTR 100 10 "S" "SIP+D2U" "!^.*$!sip:customer-service@example.com!" _sip._udp.example.com. IN NAPTR 102 10 "S" "SIP+D2T" "!^.*$!sip:customer-service@example.com!" _sip._tcp.example.com.
Come nel primo esempio, il client punta al primo record perché è quello con l'ordinale più basso. L'espressione regolare sostituisce l'URN interrogato, questa volta con il nome di dominio _sip._udp.example.com. Il flag S indica che il risultante nome di dominio punta ad un record SRV. Il client per questo finisce con _sip._udp.example.com, per il quale di conseguenza interroga il record SRV per iniziare una chiamata telefonica.
Supporto
modifica| Vendor | Product | NAPTR support? |
|---|---|---|
| ISC | BIND | Yes |
| Cisco Systems | CNR | Yes |
| Daniel J. Bernstein | djbdns | No (requires patch) |
| Microsoft | Windows Server 2003 DNS Server | No |
| Microsoft | Windows Server 2008 R2 DNS Server | Yes |
| Microsoft | Azure DNS | No |
| Secure64 | Secure64 DNS Authority DNS Server | Yes |
| PowerDNS/Open-Xchange | PowerDNS | Yes |
| NLnet Labs | NSD | Yes |
| Amazon Web Services | Amazon Route 53 | Yes |
| Sam Trenholme | MaraDNS | version 1.4 on |
| Unixservice, LLC. | unxsBind | Yes |
| Simon Kelley | Dnsmasq | Yes |
| F5 Networks | F5 Networks BIG-IP DNS | Yes |
| Google Cloud DNS | Yes | |
| OVH | DNS | Yes |
| DNS.com | 51DNS DNS | No |
| Citrix Systems | NetScaler GSLB | Yes |
| Voip Dialing | Yes |
L'implementazione del NAPTR generalmente prevede anche l'implementazione di EDNS questo perché la risposta a questo tipo di query ritorna più records NAPTR ed è normalmente più grande del limite massimo dei pacchetti UDP, che richiederebbe per questo una meno efficiente alternativa su TCP invece che usare UDP come protocollo di trasporto.