[Date Prev][Date Next]
Re: DNSSRV (was: Splitting directory over backends)
Hello Adam Williams,
> >Just curious: How many domains have a SRV RR _ldap._tcp.<domain> so that
> >it's worth thinking about offloading root.openldap.org?
> On the public side? We don't, but I'd certainly be willing to add one
> if somebody actually wrote something that used it. This sounds very
This is just the problem why SRV records have difficulties getting adopted
-- most DNS admins say "interesting, now let's wait until it's used" while
application makers don't use the records because there are hardly any
domains publishing SRV records. Catch-22.
DNS admins have nothing to loose. A query for A records will not return
the SRV records that are independently defined for it, as in
_ldap._tcp.example.com. IN SRV 0 0 389 zeus.example.com.
ldap.example.com. IN CNAME zeus.example.com.
Note that the IN A form, although commonly used, is abuse of the CNAME
facility, which is intended for hostname aliasing, not server pointers.
Since LDAP has a default port allocated, almost all servers run there.
So the port-lookup feature of SRV records is "just" and add-on gimmick that
specifies how load should be distributed over master/slave servers. But hey,
you can simulate 3:1 ratios with IN A RR too, by using decls like
ldap.example.com. IN A 126.96.36.199
IN A 188.8.131.52
IN A 184.108.40.206
IN A 220.127.116.11
But we can probably agree quickly that this is ugly. Not to mention that
hardly any socket code will actually iterate over all IPs returned for the
name. Thereby loosing one big advantage of replication, namely that of
One true advantage of SRV records is that it allows you to get rid of that
unprofessional "ldap." prefix before your domain name and that you can
still relay the protocol anywhere you want it. Useful if you host your
website at an LDAP-neglecting web service.
It's the total SRV-package that can help improve reliability of the
Internet, but someone must make a start -- a DNS admin for instance.
Sorry if my view on this issue is somewhat biased ;-)
Rick van Rein.