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 other
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 r
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
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 it try the
> DNS servers it has listed in its network settings or does
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
At Wed, 10 Dec 2008 11:48:40 -0500,
David Ford <[EMAIL PROTECTED]> wrote:
> 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
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
>
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 S
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.
Som
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
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
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 9.5.0
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 the zone?
2) In the configs below does the
Hi, Ivan!
Methodology test - one of production dns servers. It has over 900
authoritative zones and 50'000 online clients via recursive. 1
queries per 8,9 second. Also server use views.
=== named.conf ===
key "rndc-key" {
algorithm hmac-md5;
secret "XXx";
}
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 R
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
> workar
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 becaus
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
.endi
18 matches
Mail list logo
