Your SlideShare is downloading. ×
NAPTR Records in .tel
NAPTR Records in .tel
NAPTR Records in .tel
NAPTR Records in .tel
NAPTR Records in .tel
NAPTR Records in .tel
NAPTR Records in .tel
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

NAPTR Records in .tel

706

Published on

Telnic

Telnic

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
706
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. NAPTR Records in .tel
  • 2. NAPTR records in .tel September 2008 ABSTRACT .Tel is a Sponsored Top Level Domain managed by the Sponsoring Organisation Telnic Ltd. This top-level domain differs from others in that it is designed to support storage and use of per- sonal communications contacts. These are published in DNS, and the domains in which they are stored can be queried to provide a list of these contacts. This list shows the ways in which the domain owner chooses to be contacted, and entries can be selected by a querying user to initiate communications with the domain owner. Technically, communications contacts are stored within domains in the DNS using Naming Au- thority Pointer (NAPTR) resource records. NAPTRs are communications - specific type/value pairs that can be ordered. For example, you could have a phone number (one NAPTR of type "voice:tel" with value "+13105551212"), followed by an email address (another NAPTR of type "email:mailto" and value "a@b.com"). This paper describes the NAPTR record type, its key ad- vantages and usage in the DNS. Table of Contents Abstract .......................................................................................................................................... 2 References ...................................................................................................................................... 2 Background .................................................................................................................................... 3 Standards around NAPTR ........................................................................................................... 3 Enumservice Support in .tel ......................................................................................................... 4 Descriptive Enumservices ............................................................................................................. 5 Main advantages of NAPTR records ........................................................................................... 7 REFERENCES 1. RFC2915, http://tools.ietf.org/html/rfc2915 2. RFC3401, http://tools.ietf.org/html/rfc3401 3. RFC3402, http://tools.ietf.org/html/rfc3402 4. RFC3403, http://tools.ietf.org/html/rfc3403 5. RFC3761, http://tools.ietf.org/html/rfc3761 6. draft-ietf-enum-experiences-09.txt, http://tools.ietf.org/html/draft-ietf-enum-experiences- 09.txt 7. IANA Enumservices http://www.iana.org/assignments/enum-services 8. IETF http://tools.ietf.org/html/draft-timms-encrypt-naptr-01 9. .tel Developer Website, http://www.dev.telnic.org 10. Privacy in .tel, whitepaper September 2008, http://www.dev.telnic.org/naptr.pdf 2 ©2008 Telnic Limited. All rights reserved.
  • 3. NAPTR records in .tel September 2008 BACKGROUND The Naming Authority Pointer (NAPTR) record is a powerful resource record type that holds a URI (Uniform Resource Identifier), which can identify arbitrary endpoints for any form of com- munication: telphony, VoIP, IM, email, etc. The record specifies the type of contact it represents and the contact itself. A NAPTR can even point to another domain with a set of records, in which case it is called a non-terminal NAPTR, NTN. In addition, a NAPTR has Order and Preference fields, which allow creation of sorted lists of contacts to convey messages like "If you cannot send a fax, send me an email" or "Don't call me on my cell phone when I'm overseas; use Skype instead". The full NAPTR packet content is de- scribed in RFC 3403 [4]. STANDARDS AROUND NAPTR The NAPTR DNS resource record specified in RFC 3403 [4] "was originally produced as a way to encode rule-sets in DNS" [1], so that the delegated sections of URI could be changed and re- delegated over time. As a result, the NAPTR record included a regular expression that a client program could use to rewrite a string into a domain name. "Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet." [1] They are a combination of a POSIX Extended Regular Expres- sion and a replacement string similar to Unix sed-style substitution expression; for the syntax, see RFC 3402 [3]. NAPTRs have found application in Dynamic Delegation Discovery Systems (DDDS), which "implement lazy binding of strings to data, in order to support dynamically configured delegation systems" [2]. In a DDDS, a unique string is mapped to data stored within a DDDS Database "by iteratively applying string transformation rules until a terminal condition is reached". With NAPTRs, individual records act as rules stored in the DNS, used as the DDDS Database, and domain names are keys. This is the variant of DDDS on which the .tel service is based, as de- scribed in RFC 3761 [5]. This specification specifies the "E2U" DDDS Application, ENUM to URI. Each NAPTR references an Enumservice of a particular type. More clarification and inter- pretation of these standards is given in draft-ietf-enum-experiences-09.txt [6]. This document covers the aspects not considered in the specifications and focuses on the services people can expect to use to populate their .tel domain names, and the extra elements and services that will be supported in .tel-compliant programs. 3 ©2008 Telnic Limited. All rights reserved.
  • 4. NAPTR records in .tel September 2008 ENUMSERVICE SUPPORT IN .TEL The .tel platform operates on a number of standardized Enumservices and additional Enumservices adopted especially for .tel TLD operation. The TelHosting Software, the web proxies and client application need to support all those Enumservice types. LEFT: List of supported standardized Enumservices, see their descriptions at the IANA Number Registry web site [7]. RIGHT: List of experimental Enumservic- es, which include VoIP/IM contacts, en- crypted data, descriptive and auxiliary ser- vices. Each type starts with facet "X-". Voice over IP and Instant Messaging Enumservices These indicate that this contact can be used to start a communications session including voice/video and Instant messaging with a user of typical services, such as AIM, Skype, and so on. Conversely, x-im is used to start an Instant Messaging chat session with the user listed in the URI, and x-voice – for other session types. Because most existing services allow the user to switch between vid- eo/voice and IM chats in mid-session, the Enumservice indicates merely the type of session to start. The sub-type of a VoIP/IM NAPTR indicates the particular service within which the associated URI exists. This holds the service-specific URL scheme (e.g. gtalk, ymsgr) in the form skype:jamesbrown, gtalk:awebuser, or msnim:alive1. In addition, legacy Enumservic- es that have been used in other public contexts are still supported by the client programs and web proxies, and are treated as if they are equivalent to appropriate services; for example, x- skype:callto is replaced by x-voice:skype. Protected Content Enumservice This Enumservice [8] stores information encrypted by the 1024-bit RSA algorithm with PKCS#1.5 padding and no additional crypto- graphic hash. Owners of .tel domains encrypt contact data with public keys, and readers decrypt it with provided private keys. Telnic has funded development of all of the components needed for protected contacts. From a developer or user‟s perspective, this infrastructure includes client programs for various devices and computers, a web proxy client, the Sponsoring Organization web site and service, and the TelHosting Software used by accredited Providers. All of these systems working together sup- port publication and reading of protected contacts, and initiation of relationships between readers and publishers. See the whitepaper on protected contacts for more information on the security mechanism [10]. 4 ©2008 Telnic Limited. All rights reserved.
  • 5. NAPTR records in .tel September 2008 DESCRIPTIVE ENUMSERVICES The auxiliary Descriptive Enumservices label a containing NAPTR with textual information that can be presented to a querying user. They cannot exist alone in a NAPTR, but must be used with one of the Enumservices listed above. These descriptive services are subdivided into Location Indicator Hints and Descriptive Labels. No “active” service is implied by the presence of one or more of these Auxiliary Enumservices. Location Indicator Hints These services can hint to the location of the publishing user or cha- racterize the contact that this NAPTR represents; for example, that the publishing user is at work or at home, that this NAPTR is the main contact or that calling this number would involve a premium- rate call. Unlike Label Enumservices (see next), Location Indicator Hints need not be presented literally to the user. Instead, a client application may interpret the hint and act on it by displaying a specific icon or label. Descriptive Labels The Descriptive Label class is highly flexible and intended merely for presentation to the user. This Enumservice adds further information on the service that this NAPTR represents, and is independent of the ap- plication and of the URI generated by the NAPTR that contains it. The intended action for this Enumservice is for the sub-type labels to be presented to the end us- er and/or interpreted by a suitable client program acting on their behalf. The subtypes include one or more strings that fulfill the limitations of an Enumservice type or sub-type [4], the main being 32-character maximum length and consisting only of alpha, digit, or „-‟ characters. If there is more than one such Enumservice, the text these contain should be handled in a left-to-right order. Thus "+x-lbl:one+x-lbl:two:bar" could be presented as “one two bar”. Note that it is recommended that the length of labels should be limited where possible. For ex- ample, in a protected NAPTR, the service field is encrypted along with the rest of the NAPTR. Because the total length of the protected content is limited, the maximum length of the REGEXP field will depend on the Services field and any labels that contains. 5 ©2008 Telnic Limited. All rights reserved.
  • 6. NAPTR records in .tel September 2008 EXAMPLES A simple example, how to reach a SIP gateway for +44 1698 852881: 1.8.8.2.5.8.8.9.6.1.4.4.e164.arpa. NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:jim@sip.rfc1035.com!" . Decoded: 100 – order, in which NAPTRs must be processed (lowest first) 10 – preference, priority for sequencing NAPTRs with same order value (lowest first) "u" – flag meaning URI mapping "E2U+sip" - Enumservice type ENUM to URI for SIP voice end-point "!^.*$!sip:jim@sip.rfc1035.com!" – regular expression and substitution Result of DDDS algorithm is sip:jim@sip.rfc1035.com . - replacement field, empty in this example A more complex example on reaching an HTTPS site for +44 1698 852881: 1.8.8.2.5.8.8.9.6.1.4.4.e164.arpa. NAPTR 100 11 "u" E2U+web:https" "!^.*([0-9]{6})$!https://www.rfc1035.com/jim1!" Decoded: 100 - order 11 - preference (priority) "u" - flag "E2U+web:https" – Enumservice type ENUM to URI with subtype HTTPS end-point "!^.*([0-9]{6})$!https://www.rfc1035.com/jim1!" Result of DDDS algorithm is https://www.rfc1035.com/jim852881 . - replacement field, empty in this example This is an example of a non-terminal NAPTR, NTN, which shows that more NAPTR records are to be found at the specified URL, that 1.8.8.2.5.8.8.9.6.1.4.4.e164.arpa. NAPTR 500 10 "" "" "" foo.example.com. 6 ©2008 Telnic Limited. All rights reserved.
  • 7. NAPTR records in .tel September 2008 MAIN ADVANTAGES OF NAPTR RECORDS Non-Terminal NAPTRs .tel supports provisioning and use of sub-domains to partition the information published by do- main owners. For this reason, it also makes extensive use of non-terminal NAPTRs to “point” to these sub-domains. Non-terminal NAPTRs (NTN) are a core element of the DDDS standard, and thus of the "E2U" DDDS Application, on which .tel is based. An NTN holds, as its target, anoth- er domain with a set of NAPTRs. It is also possible to have an NTN in a domain that points to another domain that itself holds another NTN pointing to yet another domain, so that the three form a “chain”. Non-terminal NAPTRs enable users to apply rich structuring to the presentation of their data in the .tel TLD. Ordering Records Among other fields, a NAPTR includes “order” and “preference” fields that together specify the order in which the NAPTR records of a domain must be processed. If two records have the same order/preference values, then they are considered to be the same rule and should be selected based on the Services offered. Labeling Records An enhancement made possible by the standard NAPTR record format is the x-lbl auxiliary ser- vice, which allows addition of freeform text to characterize individual records. Without the la- bels, you may not be able to distinguish between your home and work phones, your office IM and private chat login, etc. Other resource record types do not allow labels to be added within the record. Whilst labeling can be done using TXT records, DNS does not guarantee the order in which these records are delivered, so that labels in TXT records can become disassociated with the item they are in- tended to characterize. This problem is completely avoided with the use of NAPTRs that can car- ry around their own label embedded within the record. LOC records have no ability to carry la- bels or other identifiers either, so that you cannot identify the address you entered as your home, office, or temporary location. Extensibility New NAPTR service types can be created as new means of communications are developed, mak- ing the .tel solution a very powerful long-term communications hub. 7 ©2008 Telnic Limited. All rights reserved.

×