[core] CoAP Other Transports: DNS usage

[Markus Becker <[e-mail]>]

Hi,

during the last IETF meeting draft-silverajan-core-coap-alternative-transports  was discussed. The document among other things presents alternative ways of integrating 
different transports into the URI scheme compared to what is done in draft-becker-core-coap-sms-gprs.

What I picked up (when listening remotely) was that there were opinions mostly for having the transport identifier in the scheme and some against it, and that it should 
be checked with the URI people. It was also pointed out that DNS could in some application cases be used. We (@ComNets) have discussed this for the use case we have in 
mind and came to the conclusion that it might work for us, but not in the general case.

Nevertheless, we tried to figure out the way to use DNS for giving out several transport addresses.

There are several options that could facilitate handing out different addresses, namely the following DNS resource record types:
* TXT   (RFC1035,RFC1464)
* SRV   (RFC2782)
* NAPTR (RFC3403)
* ISDN  (RFC1183)
* new DNS resource record type

Let's assume the following DNS entries:
===========
device1.example.com.  IN  A  192.0.2.1
device1.example.com.  IN  AAAA  2001:DB8::1
device2.example.com.  IN  A  192.0.2.2
device2.example.com.  IN  AAAA  2001:DB8::2
1.2.0.192.in-addr.arpa.  IN PTR   device1.example.com.
2.2.0.192.in-addr.arpa.  IN PTR   device2.example.com.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.1.0.0.2.ip6.arpa.  IN  PTR   device1.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.1.0.0.2.ip6.arpa.  IN  PTR   device2.example.com.
# The entries might need to be dynamically updated for dynamic IPs.
===========

So what whould the different RR types look like?

===========
; ISDN records:
device1.example.com.   IN   ISDN      150862028003217
device2.example.com.   IN   ISDN      150862028003218
# Looks OK for SMS. Other transports would not fit in here.

===========
; SRV records:
; _service._proto.name TTL class SRV priority weight port target
_coap._udp.device1.example.com. 86400 IN SRV 0 5 5683 device1.example.com.
_coap._udp.device2.example.com. 86400 IN SRV 0 9 5683 device2.example.com.
_coap._tel.device1.example.com. 86400 IN SRV 0 5 5683 device1.example.com.
_coap._tel.device2.example.com. 86400 IN SRV 0 9 5683 device2.example.com.
# How should SRV be used for SMS? service _tel allowed/registered?
# Note: port does not make sense for _tel.

===========
; SRV + ISDN records:
device1.tel.example.com.   IN   ISDN      150862028003217
_coap._tel.device1.example.com. 86400 IN SRV 0 5 5683 device1.tel.example.com.

===========
; NAPTR records:
;        order pref flags service        regexp
$ORIGIN 4.3.2.1.5.5.5.0.0.8.1.e164.arpa.
IN NAPTR 100   10   "U"   "E2U+coap"     "!^.*$!coap://device1.example.com!" .
IN NAPTR 102   10   "U"   "E2U+coap+tel" "!^.*$!tel:[phone]!" .

# NAPTR RR only solves E.164 to IP/URI. How could this be extended to other transports?

# which service should be used for NAPTR?

#                        "E2U+coap"
#                        "E2U+coap+udp"

#                        "E2U+coap+tel"
#                        "E2U+coap+sms"
#                        "E2U+coap+sms+tel"

#                        "E2U+web+coap"
#                        "E2U+sms+tel" reuse E2U+sms from RFC4355

===========
; TXT records: possibly in RFC6763 DNS-SD format?
device1.example.com   IN   TXT   "\0x0dtransport=sms\0x10sms=[phone]"

===========
; new DNS resource record type?

===========

We would be interested in hearing what others think about the usage of DNS for storing other transports addresses and of the resource type usage laid out above.

Markus


P.S.: For your convenience here are the relevant RFC numbers.

RFC1035:
DOMAIN NAMES (TXT RR)

RFC1464:
Using the Domain Name System To Store Arbitrary String Attributes (TXT RR)TXT

RFC1183:
New DNS RR Definitions (ISDN RR)

RFC2782:
A DNS RR for specifying the location of services (DNS SRV RR)

RFC3401 ff:
Dynamic Delegation Discovery System (NAPTR RR: RFC 3403)

RFC6118:
Update of Legacy IANA Registrations of Enumservices

RFC3966:
The tel URI for Telephone Numbers

RFC4355:
IANA Registration for Enumservices email, fax, mms, ems, and sms

RFC2916:
E.164 number and DNS (Service E2U)

RFC3761 obsoletes RFC2916:
The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application (ENUM)

------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [e-mail]
| telephone: [phone]
| building: NW1 room: N2260
------------------------------------------------