Subject: RE: draft-ietf-dnsext-apl-rr-01.txt

From: Mike Burns <[email-masked]>
Date: Mon, 4 Dec 2000 10:13:56 -0500

> -----Original Message-----
> From: Dennis Glatting [mailto:[email-masked]]
> Sent: Sunday, December 03, 2000 1:00 AM
> To: Patrik F=E4ltstr=F6m
> Cc: Randy Bush; Paul A Vixie; namedroppers
> Subject: Re: draft-ietf-dnsext-apl-rr-01.txt
>=20
>=20
> Patrik F=3DE4ltstr=3DF6m wrote:
> > At 14.35 -0800 00-12-02, Dennis Glatting wrote:
> >> But there is, isn't there? LDAP, as in, for example,=20
> ldap.cisco.com.
>=20
> > Ok, I have to take one step further down this slippery path:
> > Question: You want to know the phone number of "Eva Fr=3DF6lich". =
What
> > LDAP database do you search in?
>=20
> The same is true of DNS: which domain should you search? If you can't
> find something in DNS then how do you find it in LDAP, and visa =
versa?
> By pushing garbage from DNS to LDAP you at least have a hint of
> directory and database (the DAP part). DNS, it seems to me, is more =
of
> a locator service but people are trying to make it a database.
>=20
>=20

There is already a service that is used for user information and it =
does not
require any knowledge of containers or server location.  Finger is used =
to
retrieve user information based on email address.  DNS is supposed to =
be a
small, lightweight, quick program.  If we include a large amount of
information in the data for DNS, the resulting searches will become =
slower.

-------------------------------------
Mike Burns
net-linx Publishing Solutions - Ann Arbor
Senior Systems Engineer/
Systems Engineering Manager
ICQ#39636054
email: [email-masked]

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Michael Mealling <[email-masked]>
Date: Mon, 4 Dec 2000 11:36:35 -0500

On Mon, Dec 04, 2000 at 10:13:56AM -0500, Mike Burns wrote:
> does not require any knowledge of containers or server location.  
> Finger is used to retrieve user information based on email address.  
> DNS is supposed to be a small, lightweight, quick program.  If we include 
> a large amount of information in the data for DNS, the resulting searches 
> will become slower.

While doing the NAPTR stuff I was walking this line very closely.
My rule of thumb is that DNS should be used for pointing to services
that actually contains the data your interested in but never should
the actual data be in DNS....

For the LDAP folks, take a look at www.ldap.research.netsol.com for some 
ideas on how to get around the 'disconnected islands' aspect of LDAP. Its not
a true LDAP directory becauses its insanely expensive to search 
the entire tree. 

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 04 Dec 2000 10:48:41 -0800

> For the LDAP folks, take a look at www.ldap.research.netsol.com for
> some ideas on how to get around the 'disconnected islands' aspect of
> LDAP. Its not a true LDAP directory becauses its insanely expensive
> to search the entire tree.

Off-topic observation, their structure is malformed.

For example, I have ntrg.com, ntrg.org and ntrg.net zones. Searching
through their repository returns data that is practically unusable.

You would think ntrg.com would be dc=ntrg,dc=com but instead they use
dc=ntrg,c=us. c=us is an assumption, nor does dc=ntrg,c=us allow for
multiple occurances of dc=ntrg.

ntrg.org and ntrg.net are both stored as dc=ntrg (no secondary qual)
resulting in zone collision in the referral database.

This is a good idea as it provides a psuedo-root for LDAP, whereby any
registered zone in the DNS root zone can have an LDAP link. But the
implementation is really lacking.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/