Re: draft-ietf-dnsext-apl-rr-01.txt

[Simon Josefsson <sj@extundo.com>]

Dennis Glatting <dennis.glatting@software-munitions.com> writes:

> Patrik Fältström wrote:
> > At 14.35 -0800 00-12-02, Dennis Glatting wrote:
> >> But there is, isn't there? LDAP, as in, for example, ldap.cisco.com.
> 
> > Ok, I have to take one step further down this slippery path:
> > Question: You want to know the phone number of "Eva Frölich". What
> > LDAP database do you search in?
> 
> 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?

Now we're getting to the heart of the problem.  It all depend on what
you want to look up.  If you want to search for personal names, DNS is
not the right tool by any mean.  In fact, no global directory would be
the right tool, personal names are not unique enough to be useful as
an address on a global scale.  Department-wide, company-wide or
perhaps country-wide LDAP directories is probably better suited.

But if we consider things that got a natural hostname, such as
servers, zones, ip addresses, email addresses, it's very appealing to
use DNS to look up information attached to these addresses.  This is
because, DNS already support this infrastructure, and when it comes to
servers (hostnames) DNS _is_ this infrastructure.

My point is that some things are "natural" to store in the X.400
(L)DAP model, and other things are "natural" to store in the DNS
model.  Some things can be easily located in DNS and not in LDAP, and
vice 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.

I agree!  But I still want to see garbage (like certificates) stored
in DNS because they are vital when "locating" someone.  In a secure
world, knowing the address of someone isn't enough to contact someone.
The certificate is similar to addresses, in that it's required to
contact the remote entity.



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.