diff --git a/CHANGES b/CHANGES
index d1f2519fe25b240b300e4eaa0f4e09241083ba39..c10cd26b6975ba67c1cc250638910fa191a5b6eb 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,6 @@
+2322.	[port]		MacOS: work around the limitation of setrlimit()
+			for RLIMIT_NOFILE. [RT #17526]
+
 2321.	[placeholder]
 
 2320.	[func]		Make statistics couters thread-safe for platforms
diff --git a/lib/isc/unix/resource.c b/lib/isc/unix/resource.c
index 73f47bf92adf444ce0246bbb3c8dece7e9c7d215..2e44b2ba1c2c06236a45550b75a46df64a7ae6e5 100644
--- a/lib/isc/unix/resource.c
+++ b/lib/isc/unix/resource.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resource.c,v 1.14 2007/06/19 23:47:18 tbox Exp $ */
+/* $Id: resource.c,v 1.15 2008/01/25 19:31:29 jinmei Exp $ */
 
 #include <config.h>
 
@@ -132,58 +132,27 @@ isc_resource_setlimit(isc_resource_t resource, isc_resourcevalue_t value) {
 		rlim_value = value;
 	}
 
-	/*
-	 * The BIND 8 documentation reports:
-	 *
-	 *	Note: on some operating systems the server cannot set an
-	 *	unlimited value and cannot determine the maximum number of
-	 *	open files the kernel can support. On such systems, choosing
-	 *	unlimited will cause the server to use the larger of the
-	 *	rlim_max for RLIMIT_NOFILE and the value returned by
-	 *	sysconf(_SC_OPEN_MAX). If the actual kernel limit is larger
-	 *	than this value, use limit files to specify the limit
-	 *	explicitly.
-	 *
-	 * The CHANGES for 8.1.2-T3A also mention:
-	 *
-	 *	352. [bug] Because of problems with setting an infinite
-	 *	rlim_max for RLIMIT_NOFILE on some systems, previous versions
-	 *	of the server implemented "limit files unlimited" by setting
-	 *	the limit to the value returned by sysconf(_SC_OPEN_MAX).  The
-	 *	server will now use RLIM_INFINITY on systems which allow it.
-	 *
-	 * At some point the BIND 8 server stopped using SC_OPEN_MAX for this
-	 * purpose at all, but it isn't clear to me when or why, as my access
-	 * to the CVS archive is limited at the time of this writing.  What
-	 * BIND 8 *does* do is to set RLIMIT_NOFILE to either RLIMIT_INFINITY
-	 * on a half dozen operating systems or to FD_SETSIZE on the rest,
-	 * the latter of which is probably fewer than the real limit.  (Note
-	 * that libisc's socket module will have problems with any fd over
-	 * FD_SETSIZE.  This should be fixed in the socket module, not a
-	 * limitation here.  BIND 8's eventlib also has a problem, making
-	 * its RLIMIT_INFINITY setting useless, because it closes and ignores
-	 * any fd over FD_SETSIZE.)
-	 *
-	 * More troubling is the reference to some operating systems not being
-	 * able to set an unlimited value for the number of open files.  I'd
-	 * hate to put in code that is really only there to support archaic
-	 * systems that the rest of libisc won't work on anyway.  So what this
-	 * extremely verbose comment is here to say is the following:
-	 *
-	 *   I'm aware there might be an issue with not limiting the value
-	 *   for RLIMIT_NOFILE on some systems, but since I don't know yet
-	 *   what those systems are and what the best workaround is (use
-	 *   sysconf()?  rlim_max from getrlimit()?  FD_SETSIZE?) so nothing
-	 *   is currently being done to clamp the value for open files.
-	 */
-
 	rl.rlim_cur = rl.rlim_max = rlim_value;
 	unixresult = setrlimit(unixresource, &rl);
 
 	if (unixresult == 0)
 		return (ISC_R_SUCCESS);
-	else
-		return (isc__errno2result(errno));
+
+#if defined(OPEN_MAX) && defined(__APPLE___)
+	/*
+	 * The Darwin kernel doesn't accept RLIM_INFINITY for rlim_cur; the
+	 * maximum possible value is OPEN_MAX.  BIND8 used to use
+	 * sysconf(_SC_OPEN_MAX) for such a case, but this value is much
+	 * smaller than OPEN_MAX and is not really effective.
+	 */
+	if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
+		rl.rlim_cur = OPEN_MAX;
+		unixresult = setrlimit(unixresource, &rl);
+		if (unixresult == 0)
+			return (ISC_R_SUCCESS);
+	}
+#endif
+	return (isc__errno2result(errno));
 }
 
 isc_result_t