[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP and DNS
Exactly. They best of both worlds would be to manage the ip address, it's
DNS name, and any related info in LDAP, but have a gateway to do zone
transfer of ip/dns info from LDAP to "real" DNS servers, which DNS
clients talk to. Gives you the ability to tie all your info together in LDAP,
yet still have the performance optimizations of DNS servers. As Mark said,
it's not really practical to have LDAP replace DNS. Another option
would be to have something like a perl script that periodically searches LDAP
for all DNS info (easy if you build it right), dynamically builds your DNS
files from this, then tells your DNS server to reload. Wouldn't require
any hacks to DNS software. Gets trickier if you add dynamic DNS to
the picture...
Similar to what I've heard some people do (or try to do) with relational
databases- i.e., I have a big Oracle HR database, want to serve LDAP from
it. I can set up a master LDAP server that backends to oracle,
replicates to one or more standard replica ldap servers, and all clients
access the replicas only (read-only access). 'Course mapping something like a
Peolesoft database on Oracle to LDAP is a real pain, not to mention
finding/writing something to interface the LDAP server to the Oracle backend
and figuring out how to handle LDAP clients that want to write to LDAP...
I think in all these situations, the real goal I would be looking at is getting
as close to a single place to write/manage all of an enterprises info, so I
have one database to manage, can build relationships between the info, can
build a
single interface to manage everything, etc, then find ways to export this
data as read only to the various services. It's not such a big deal to manage
the same info in many databases as long as only one is considered the "owner"
where the data is maintained and the data gets automatically exported to other
systems - the biggest problem is then just timing issues. The problem comes
when data is mastered in many places (such as if you stored it in LDAP, then
hand edited and updated it in your DNS files - inevitably, someone will edit
one and forget to edit the other).
Mark Wilcox wrote:
> Well if you follow any of the interviews with Tim Howes (aka the Father of
> LDAP), you'll realize that LDAP is not designed to replace DNS. DNS is a
> very specific directory application that requires special optimizations.
> LDAP of course can help store some DNS information (e.g. the InterNIC WhoIs
> database would be a perfect example), but using LDAP for traditional DNS
> lookups probably isn't pratical in the long-run. While I think LDAP security
> and replication are top-notch, it's write performance stinks. DNS changes
> alot, so that's something to really consider.
>
> DNS does need to be reworked (but the fact that it has scaled as well as it
> has says a lot), but I think it's going to require a very similar solution
> that will need to be highly optimized for this environment.
>
> on the other hand, it probably does make sense for LDAP to store some
> information including IP/hostname information about an object. This will
> probably become more apparent when JINI network devices start to appear.
> E.g. a device connects to the network, finds an LDAP server (probably
> through the service location protocol), then registers itself with the LDAP
> server, e.g. I'm a toaster, here's my current specs (I can handle two slices
> of bread, I'm electric, my current setting is golden-brown, etc). Then the
> JINI server can issue an IP address (and perhaps a hostname) to the toaster,
> perhaps placing it in the LDAP server so that the toaster doesn't have to
> query DNS or something similar to find it's hostname each time it wants to
> communicate.
>
> later,
>
> Mark
>
> -----Original Message-----
> From: Jeff Clowser <jclowser@aerotek.com>
> To: Jon Sellers <jsellers@manatee.brev.lib.fl.us>
> Cc: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
> Date: Tuesday, June 22, 1999 5:07 PM
> Subject: Re: LDAP and DNS
>
> >I would think that a nice compromise in a product would be something
> >like the following:
> >
> >DNS entries are maintained in LDAP - you could keep ip and hostname
> >info in a record, and expand it to include all kinds of other info
> >for record keeping (i.e. person responsible for the machine, machine
> >type, location, etc).
> >
> >Have a "primary" DNS server that backends to LDAP - this would have to
> >be a custom hack to something like bind.
> >
> >Have 2 or more secondaries that do their zone transfers from this
> >"primary" server. These could be unmodified versions of bind.
> >
> >Register only these secondary DNS servers for users, Internic, etc.
> >i.e. the _only_ purpose of the "primary" server would be to read
> >LDAP and do zone transfers to your other DNS servers, so you manage
> >it in LDAP, but for performance, you use standard tuned bind DNS servers.
> >
> >As a side note, I would make the ip/dns record just have ip/hostname info
> >in it, have a separate record for the machine (for inventory purposes,
> >recording what it is, SN, inv. #, etc), and a separate record for the
> >user responsible. The IP/hostname record would hold the DN of the
> >machine it is used on, and the machine record would hold the
> >dn of the responsible person (maybe even the location would be a dn
> >to an office/location record) - building these relations can avoid
> >duplicate/bad data, though it will require more lookups to gather all
> >the data related to the ip (i.e. 4 lookups to find the ip, machine,
> >user responsible, and location of the machine). The DNS server
> >is only worried about the ip to name mapping, so only needs the first
> >record. These additional lookups only happen when managing a dns address.
> >Allows you to create a nice user management console where deleting a user
> >automagically tells you what equiment they have signed out so you can
> >collect it. If it's a server tied to a users record that also has
> >email info, you can do things like monitor the a server and know who
> >to email via a script if it goes down by finding the IP # and tracing
> >it to the machine, then the user(s).
> >Nice managed enterprise :)
> >
> >Long way to get to my final point, which is that I don't know of
> >any software that actually does this... Just some ideas in case someone
> >wants to build it - this would take care of the performance question,
> though.
> >
> >Jon Sellers wrote:
> >
> >> Don't know. That is the kind of thing I was hoping to find out with my
> original
> >> message. I would expect that there isn't right now, but if LDAP becomes
> as
> >> ubiquitous as DNS won't it need to come close?
> >>
> >> Another question might be "Is there an LDAP server that can handle the
> number
> >> of queries per second that my DNS handles?
> >>
> >> Jon
> >>
> >> >On Tue, 22 Jun 1999, you wrote:
> >> > Jon,
> >> >
> >> > Is there an LDAP server that can handle the number of queries
> >> > per second that DNS can handle?
> >> >
> >> > --Pete
> >> >
> >> > Jon Sellers wrote:
> >> > >
> >> > > Has anyone done any work on integrating OpenLDAP and DNS? I suppose
> the right
> >> > > way to approach it would be to patch bind to query an LDAP server
> instead of
> >> > > it's standard configuration files (though I know zip about bind's
> internals).
> >> > > Or maybe someone knows of a DNS implementation that already does
> this?
> >> > >
> >> > > Jon
> >> >
> >> > --
> >> > ====================================================================
> >> > Peter E. Stoddard, Consultant Pete.Stoddard@compaq.com
> >> > ISP Solutions Business Unit Tel. (603) 884-5128
> >> > Compaq Computer Corporation Fax. (603) 884-0627
> >> > 110 Spit Brook Road, ZKO2-2/N87
> >> > Nashua, New Hampshire 03062-2698
> >> > USA
> >> > ====================================================================
> >
> >--
> > Jeff Clowser
> > mailto:jclowser@aerotek.com Hanover MD 21076 USA
> > Phone: (410)-579-4328 7312 Parkway Drive
> >
> >
> >
> >
> >
--
Jeff Clowser
mailto:jclowser@aerotek.com Hanover MD 21076 USA
Phone: (410)-579-4328 7312 Parkway Drive