[Enum] New DNS record class values?

[Sören Nyckelgård <[e-mail]>]

Patrik's draft <draft-faltstrom-e164> suggests a SRV record format for the
"potscall" service where the SRV target host name is the reversed telephone
number. A problem with this solution is that RFC2052 (and
draft-ietf-dnsind-rfc2052bis-04) states that the target host name in a SRV
record MUST have an address record (an A record) and RFC1034 shows that an A
record can only refer to a 32-bit IP address, which is not very useful for a
"potscall" service. I can think of at least two solutions to this problem.

The first solution (1) would be not to use SRV records for non-internet
services, like the the "potscall" service. I believe that it's sufficient if
the NAPTR record indicates that the queried domain (QNAME) supports
"potscall" and that it provides an appropriate rewrite address. I'll soon
get back to this.

The second solution (2) would be to use SRV records as suggested in Patrik's
draft, but make the record indicate, in some way, that there is no A record
for the target host name.

Back again to the first solution (1) and let's use a NAPTR line from
Patrik's draft for an example:

  IN NAPTR 102 10 s potscall+N2R "" _potscall._tcp.paf.swip.net.   

I believe this NAPTR line ought to look something like this if we want to
omit the SRV record:

  IN NAPTR 102 10 p potscall+N2R ""
_potscall._tcp.2.8.0.4.6.2.6.5.8.6.4.e164.int.

I'm not quite happy with the format above since "potscall" is not an
internet service, although the CLASS parameter (class=IN) says so. Further
more, the protocol that the "potscall" service uses is a SCN-protocol like
ISUP, not TCP. 

RFC1034 defines some classes other than IN, but I guess the network types
they refer to don't exist anymore. Since we now try to make the DNS handle
non-internet addresses and targets, it might be adequate to define some new
classes. What about "SC" for Switched Circuit networks, "FR" for Frame Relay
networks and "AT" for ATM networks? Then we wouldn't be forced to put
irrelevant information in the record just to make it look "internetish".
Instead the NAPTR record could provide information that is adequate for a
non-internet target. The NAPTR line above could then look something like
this instead:

  SC NAPTR 102 10 p potscall+N2R "" _potscall._inap.46856264028.

or maybe like this (which I personally prefer):

  SC NAPTR 102 10 u potscall+N2R "" 46856264028.

Note the use of flags "p" and "u" instead of "s" in the NAPTR lines above.
This should be appropriate unless I've misunderstood RFC2219.

The ENUM requirement draft says that "The system MUST support existing local
number portability mechanisms" and should not "impede future global number
portability" So, does the solution above support number portability?

Well, the NAPTR record can rewrite a dialed number and, for instance, add a
routing prefix. However, global routing prefixes are seldom appreciated by
SCN operators since they often interfear with local number plans and local
routing prefix schemes. It's probably better to specify the terminating SCN
operator explicitly and let the operator map it to locally significant
routing information. The NAPTR record might then look something like this:

  SC NAPTR 102 10 u potscall+N2R "" [e-mail].

Personally, I'd prefer a solution like the one above, but let's anyway go
back to the initial SRV record problem and the second solution (2) that I
mentioned. Solution (2) suggests that we use the SRV record, as Patrik's
draft says, but we indicate to the client and the DNS mechanism that there
is no A record to search for. 

Setting CLASS=SC in the SRV record would be a good indicator that there is
no A record available since SC class targets don't use A records. To show
what I mean, I first pick a SRV line from Patrik's draft: 

  _potscall._tcp.tele2.se.  IN SRV 1 1 0 0.0.0.4.6.2.6.5.8.6.4.e164.int.

Using CLASS=SC enables us to provide information that is more adequate for a
non-internet target. The SRV record could look like this: 

  _potscall._inap.tele2.se.  SC SRV 1 1 0 [e-mail].

The SRV record format includes by definition a "port" number. It has here
been set to "0" since "port" makes no sence for a SCN target. Further more,
the target name above is not the "domain name of the target host" as RFC2052
(and draft-ietf-dnsind-rfc2052bis-04) specifies, rather a kind of URL. 

As a final comment, please note that RFC1034 states that QCLASS can be set
to "*" (class value 255) in a DNS query, thus making the DNS return both IN
records and SC records. This, of cause, includes both NAPTR and SRV records.



I'm looking forward to see your comments on these suggestions. 

--
Sören Nyckelgård, Telia Research 

_______________________________________________
enum mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/enum