Subject: [Enum] New DNS record class values?

From: Sören Nyckelgård <[email-masked]>
Date: Wed, 19 Jan 2000 10:34:32 +0100

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 "" [email-masked].

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 [email-masked].

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
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Wed, 19 Jan 2000 10:32:41 -0600

>more, the protocol that the "potscall" service uses is a SCN-protocol like

I must agree with your basic premise. I've never been too happy with the 
place holder syntax myself. Your suggestions are most welcome.

>   SC NAPTR 102 10 u potscall+N2R "" [email-masked].

Now this is also very interesting. In private conversations I've heard talk 
about the possibility of the DNS record actually carrying the LRN [ 
Location Routing Number ] for the terminating switch or somehow creating a 
pointer to a database [LDAP?] for retrieving that data.

In your opinion what might be the best approach to this?

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Jan 2000 20:20:58 -0500

Insert standard disclaimer about not being an ENUM subject

> We have also found that service providers demand more control 
> over access to
> their data. Service providers and network operators want to 
> control who has
> access to entries down to the attribute level and service 
> level.  This is
> difficult to do with DNS alone.  Security of information such 
> as what is
> public and what is private can be eloquently supported using 
> LDAP servers
> with access control information.

Most, but not all, of this information is MINE, not a service provider's.
I own in, I want to control it.  It may be that service providers
have some information they keep for their own internal purposes (as
long as they disclose such purposes to me), so the problem is not anywhere
near
as simple as -an- LDAP query. I also will undoubtedly have multiple service
providers.  As a result, I may need multiple entries to do parallel 
searches in the DNS record. The question turns on whether any of the
information
a service provider needs to complete a call to another service provider
is in the service provider's database, thus requiring public record lookup,
or whether the information needed is all mine, and I can choose to release
portions of it depending on access controls.  The latter gets the problem
simpler, but I suspect the former is more likely, probably more due to 
intrangicence rather than need. 

I probably have at least two Voice mailboxes - personal and office, and I
might
have a shared home one too.  I would want a single configuration, where
common data is entered once, and VM service provider value-add data is
entered
separately, if possible on one web page.  The call forwarding logic of my
(cell,
home, work) telephony service provider may result in a call being handled
by
one of my VM service providers, handed off by any of my telephony service
providers.  
For example some one calls me personally, my home phone and my cell phone
ring
simultaneously, first answer gets the call, no answer forwards to my
personal
VM box.  I want, as much as possible, to have them behave the same, use the 
same basic configuration, etc.  My DNS record (it's mine, or possibly my
employer's) 
might be getting big, but so what?  

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Jan 2000 11:17:44 -0500

I think that Brian hits the nail on the head, and outlines the fundamental
problem with using phone numbers as DNS keys: you have to be able to tell
to whom the number belongs, so you can determine who has authority on the
record. This authority can vary depending on the way you look at it.
Candidates are:

1) The local provider of the phone service for that number. Looks
legitimate, but then it conflicts with the possibility to change providers
(local number portability) or, in the future, the possibility to be
multi-homed through several providers.

2) The owner of the phone. Again, this looks legitimate, but in many cases
you don't really own a phone number. You merely lease it, and you loose it
when you move to another city, or if you stop paying your bills.

3) A third party, such as the local authority in charge of regulation of
the telephone service. This type of authority varies with the locale, with
the government regime, etc.

A natural way to solve the problem is to provide a layer of indirection.
(Isn't that computer's science true and only tool?) In the case of the DNS,
the layer of indirection is the "Non-Terminal DNS Name Redirection"
mechanism described in RFC 2672 (Proposed Standard.) Using that mechanism,
a local telephone company could have the authority over a name such as:
	1.2.3.4.5.6.7.8.9.0.1.example.net
but it would at that point place a DNAME record refering further searches
to the owner's domain. For example, if the DNAME is defined as:
	1.2.3.4.5.6.7.8.9.0.1.example.net IN DNAME myphone.brian.brian-s-domain.net
the DNS request for:
	fax.tcp.1.2.3.4.5.6.7.8.9.0.1.example.net IN SRV
would return the value of:
	fax.tcp.myphone.brian.brian-s-domain.net  IN SRV
that was specified by Brian.

Defining that we will use this procedure is quite powerful. It allows us to
solve monopoly issues (there can be several numbering trees pointing to the
same subtree), multi-homing issues, delegation issues (If I trus my phone
company, I start with its tree). 
	
-- Christian Huitema