Hi,
How does the OpenLDAP client library handle multiple A records being returned for a DNS query for an LDAP server?
That is to say, if "host ldap" returns 1.1.1.1, 2.2.2.2 and 3.3.3.3, will the OpenLDAP client library only connect to 1.1.1.1? If a connection to 1.1.1.1 fails, will it try 2.2.2.2 and then 3.3.3.3?
Basically we're trying to achieve redundant servers and load balancing using a round-robin-style DNS entry.
Tim Gustafson BSOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
Tim Gustafson wrote:
Hi,
How does the OpenLDAP client library handle multiple A records being returned for a DNS query for an LDAP server?
OpenLDAP doesn't alter hosts resolution behavior. As usual, the first address (A record) returned would be used.
That is to say, if "host ldap" returns 1.1.1.1, 2.2.2.2 and 3.3.3.3, will the OpenLDAP client library only connect to 1.1.1.1? If a connection to 1.1.1.1 fails, will it try 2.2.2.2 and then 3.3.3.3?
It will not try 2.2.2.2 or 3.3.3.3 automatically if a connection attempt to 1.1.1.1 fails. It might happen to try them on the next connection, if the host needs to resolve the LDAP server's name again, and either 2.2.2.2 or 3.3.3.3 is the first A record returned.
Basically we're trying to achieve redundant servers and load balancing using a round-robin-style DNS entry.
Tim Gustafson BSOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
George Holbert wrote:
Tim Gustafson wrote:
Hi,
How does the OpenLDAP client library handle multiple A records being returned for a DNS query for an LDAP server?
OpenLDAP doesn't alter hosts resolution behavior. As usual, the first address (A record) returned would be used.
That is to say, if "host ldap" returns 1.1.1.1, 2.2.2.2 and 3.3.3.3, will the OpenLDAP client library only connect to 1.1.1.1? If a connection to 1.1.1.1 fails, will it try 2.2.2.2 and then 3.3.3.3?
It will not try 2.2.2.2 or 3.3.3.3 automatically if a connection attempt to 1.1.1.1 fails. It might happen to try them on the next connection, if the host needs to resolve the LDAP server's name again, and either 2.2.2.2 or 3.3.3.3 is the first A record returned.
False. If multiple A records are returned, if the first address fails it will continue on to the next, stopping when something succeeds or it runs out of alternatives.
Howard Chu wrote:
George Holbert wrote:
Tim Gustafson wrote:
Hi,
How does the OpenLDAP client library handle multiple A records being returned for a DNS query for an LDAP server?
OpenLDAP doesn't alter hosts resolution behavior. As usual, the first address (A record) returned would be used.
That is to say, if "host ldap" returns 1.1.1.1, 2.2.2.2 and 3.3.3.3, will the OpenLDAP client library only connect to 1.1.1.1? If a connection to 1.1.1.1 fails, will it try 2.2.2.2 and then 3.3.3.3?
It will not try 2.2.2.2 or 3.3.3.3 automatically if a connection attempt to 1.1.1.1 fails. It might happen to try them on the next connection, if the host needs to resolve the LDAP server's name again, and either 2.2.2.2 or 3.3.3.3 is the first A record returned.
False. If multiple A records are returned, if the first address fails it will continue on to the next, stopping when something succeeds or it runs out of alternatives.
Wow. Then OpenLDAP handles this a lot more intelligently than I thought. Thanks Howard!
--On Tuesday, March 17, 2009 2:21 PM -0700 Tim Gustafson tjg@soe.ucsc.edu wrote:
Basically we're trying to achieve redundant servers and load balancing using a round-robin-style DNS entry.
Stanford has used Round Robin DNS entries for its ldap servers for over a decade. It works quite well for most things, except java.
Try host -t txt ldap.stanford.edu
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Awesome, thanks for all the feedback.
So what I'm hearing is that the OpenLDAP client does indeed fail over to the second and third (and so on) A record until it finds one that works, and that Stanford has been doing this for year. Good stuff. Thanks so much!
Tim Gustafson BSOE Webmaster UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
Tim Gustafson tjg@soe.ucsc.edu writes:
Awesome, thanks for all the feedback.
So what I'm hearing is that the OpenLDAP client does indeed fail over to the second and third (and so on) A record until it finds one that works, and that Stanford has been doing this for year. Good stuff. Thanks so much!
Stanford does something different. We return a different CNAME to every DNS query, which bounces between our LDAP servers based on their current monitoring status, load, and the number of hits they've gotten recently. This is done using lbnamed and lbcd. It has other drawbacks, though, such as the fact that some clients retain DNS results without regard to TTL and therefore will never rebind to a different LDAP server without restarting the application.
Quanah Gibson-Mount wrote:
--On Tuesday, March 17, 2009 2:21 PM -0700 Tim Gustafson tjg@soe.ucsc.edu wrote:
Basically we're trying to achieve redundant servers and load balancing using a round-robin-style DNS entry.
Stanford has used Round Robin DNS entries for its ldap servers for over a decade. It works quite well for most things, except java.
Try host -t txt ldap.stanford.edu
What are the TXT RRs for?
Russell Jackson raj@csub.edu writes:
Quanah Gibson-Mount wrote:
Stanford has used Round Robin DNS entries for its ldap servers for over a decade. It works quite well for most things, except java.
Try host -t txt ldap.stanford.edu
What are the TXT RRs for?
lbnamed returns pool participants and their current weights and increments as TXT records for debugging and informational purposes.
% dig +short -t txt ldap.best.stanford.edu @lbdns1.stanford.edu " 60/1.000 ldap4.stanford.edu" " 60/1.000 ldap1.stanford.edu" " 60/1.000 ldap3.stanford.edu"
openldap-software@openldap.org
-
George Holbert -
Howard Chu -
Quanah Gibson-Mount -
Russ Allbery -
Russell Jackson -
Tim Gustafson