You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: questions

  • To: Jim Reid < >
    Max Tulyev < >
  • From: "Conroy, Lawrence (SMTP)" < >
  • Date: Tue, 25 Nov 2003 10:57:43 +0000
On 25 Nov 2003, at 9:53 am, Jim Reid wrote:


"Max" == Max Tulyev maxtul@localhost writes:

    Max> And can I use other type of records than NAPTR? For example,
    Max> TXT record to provide extra infromation about me, my name,
    Max> company, physical address, etc?

Of course. The DNS does not place any restriction on which resource
record types may or may not exist for some name.

    Max> So when I do call to ENUM-enabled application, it looks up my
    Max> extra data and gives it to my peer with my phone number?

Probably not. Though in theory the application could do that if it has
prior knowledge that these other record types exist and contain that
sort of information. An ENUM-aware application will expect to process
NAPTR records, so it's unlikely to lookup other types of records for
an ENUM name. Or make sense of any TXT record (say) if such a thing
existed. How could the application know that this TXT record encoded a
postal address? Even harder would be determining what that postal
address was for or to do anything sensible with it.
Hi Jim, Max, Folks,

Yes, one can add anything - it's a domain. Strictly, there are a couple
of issues in practice.
(i) ENUM domains I've seen "out there" tend to have more than one NAPTR.
Making a request for NAPTRs can return an answer that's several hundred
bytes long. If there are other Resource Record types (such as TXT) then
the answer can grow beyond 500 octets. This can be a problem as ALL the
resource records won't fit into a UDP answer, so it may be truncated.
=> If you expect there may be TXT records, do two queries - one for NAPTRs
and one for TXT records (or MX, or ...).
Note that (as Jim points out) one can get a mail address in a NAPTR.

(ii) Many DNS servers return resource records in a random order; thus if
there's more than one TXT record, you have to guess which one to handle
first.

(iii)TXT records do ASCII - thus there can be an issue with a useful address
[or your .sig, Max - the "(MT6561-RIPE, 2:463/253@localhost)" is OK, but...]

(iv) In some countries, folk still have a 20th Century attitude to privacy;
Doing a query on a phone number will get you the name (if there's a TXT
record with this data). Some people consider this "sensitive" data.
=> It's an "opt-in" service; such paranoid folk won't put in a TXT Record
with their name, so you can't expect one to be available always. A query
for TXT records may return no content.
Plus... you will be doing two DNS queries, even if there's no data for the
second; that will have a major impact on DNS query volume. I think that's
what Jim meant when he said "prior knowledge" - to just guess and always do
a second query for TXT records is not "polite".

Having said that, we run a split-view DNS setup; for "internal" use we have
TXT records in the zones, whilst the "external" view doesn't. This seems to
be a typical setup for a company, and some folk even have these as global
entries.

(Our lookup web at <http://www.sienum.co.uk/lookup.php> will try to find
a TXT record and display it, if one exists - we're not polite.
For example, try <http://www.sienum.co.uk/loopup.php?%2B878108781087810>)


One could instead use a NAPTR in the ENUM domain with a web URL pointing
to a .PNG of the name (and/or picture). This could be used:
- as a link to a distributed directory to give name and picture, if this
is not considered a privacy issue, or
- with a lookup of the called number to give a graphical caller display.

all the best,
Lawrence



  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>