Memory statistic
start - 570M
1 min - 913M
2 min - 958M
3 min - 1092M
4 min - 1074M
5 min - 1082M
10 min - 1217M
15 min - 1234M
60 min - 1513M
max-cache-size 800M;
Port installed only with Threads parameter, and patch in Makefile
.if (${ARCH} == amd64)
ARCH= x86_64
.endif
JINMEI Tatuya / 神明達哉 wrote:
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
I test patch, add to bind95/Makefile
.if (${ARCH} == amd64)
ARCH= x86_64
.endif
Future versions of BIND9 will support amd64 in its configure script to
workaround the FreeBSD
Hi,
is it possible to see your named.conf
what is the methodology of the test? is it for authoritative queries?
recursive? or both? at the same time?
my patch for the port is the same as yours...
thanks!
===
.if ${ARCH} == amd64
ARCH=x86_64
.endif
--- On Thu, 12/11/08, Dmitry
On Oct 25 2008, Stephane Bortzmeyer wrote:
On Fri, Oct 24, 2008 at 08:14:42PM +1100,
Mark Andrews [EMAIL PROTECTED] wrote
a message of 38 lines which said:
Because the Atlas servers are based on old code and because
there are delegations that only work in COM and NET because
I frequently send short messages to some cellphone users on
tmomail.net. Several weeks ago I started noticing that bind is having
problems keeping records for tmomail once they get stale. Specifically
the MX record. If I restart bind, I can immediately get the MX record
again.
I'm running
In article [EMAIL PROTECTED],
David Ford [EMAIL PROTECTED] wrote:
I frequently send short messages to some cellphone users on
. Several weeks ago I started noticing that bind is having
problems keeping records for tmomail once they get stale. Specifically
the MX record. If I restart bind,
Sam Wilson wrote:
I hadn't noticed it but all the records in the response to a request for
the MX for tmomail.net have a TTL of 60 seconds, that's the MX record,
the NS authority record and the additional A record. The names in the
delegation NS records for for tmomail.net are different
I did some testing with this couple a months ago and it seams like AD is
following the NS directive in the SOA.
The design I used in my test-case was to put AD as an authoritative updater
of the specified zone on my master, once updated the BIND master was
responsible for updating the slaves.
Nicholas F Miller [EMAIL PROTECTED] wrote:
I have a couple of questions regarding how a Microsoft domain
controller updates a dynamic zone.
1 ) When a domain controller tries to update the zone does it try the
DNS servers it has listed in its network settings or does it follow
the SOA for
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
JINMEI Tatuya / 神明達哉 wrote:
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
I test patch, add to bind95/Makefile
.if (${ARCH} == amd64)
ARCH= x86_64
.endif
Future
Barry Jonathan,
Thanks for the quick replies. your responses go along with my findings
as well. I am trying to clean up some of our configs. The DDNS zones
just didn't look right to me and I wanted to confirm what I was
thinking.
Jonathan, I tested things on a test DC by pointing it at
On Wed, Dec 10, 2008 at 4:00 PM, Mark Andrews [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Nicholas F
Mille
r writes:
I have a couple of questions regarding how a Microsoft domain
controller updates a dynamic zone.
1 ) When a domain controller tries to update the zone does
I'm migrating away from my 12 year old Solaris master DNS server to a
new Linux based master server. I'm looking for suggestions on how to
make the transition smooth without any downtime. The IP address of the
new server will be different and so will be the hostname that will
show up in the whois
Step 1: Set up the new master as a clone of the old master.
Step 2: Reconfigure/demote the old master to the status of slave. All
other slaves will continue to get updates from the old master/new
slave, and the magic of DNS notify will make replication from new
master to old master to
14 matches
Mail list logo
