On 5/7/12 5:57 PM, "Barry Margolin" wrote:
> In article ,
> michoski wrote:
>> note: keeping replies on-list, so others can also chime in and help...
>> On 5/7/12 2:41 PM, "James Sheffer" wrote:
>>> My mistake - I thought "allow-notify" was telling the slave to only accept
>>> transfers from th
In article ,
michoski wrote:
> note: keeping replies on-list, so others can also chime in and help...
>
> On 5/7/12 2:41 PM, "James Sheffer" wrote:
> > My mistake - I thought "allow-notify" was telling the slave to only accept
> > transfers from the ip address supplied (Master).
>
> allow-not
Please add a Subject next time.
Please log a bug report with you Mail User Agent vendor that it is
doing unnessecary quoted-printable escaping. Comma does not need
to be escaped and as the purpose of quoted-printable is to be
readable by humans any unnecessary quoting should be avoided.
In mess
note: keeping replies on-list, so others can also chime in and help...
On 5/7/12 2:41 PM, "James Sheffer" wrote:
> On May 7, 2012, at 3:56 PM, michoski wrote:
>> On 5/7/12 1:02 PM, "James Sheffer" wrote:
>>> My first question is about my options. For now, I want to "receive"
>>> transfers
>>> f
In message ,
"Bischof, Ralph F. (MSFC-IS40)
[NICS]" writes:
> Hi,
>
> I am testing with BIND 9.9.0 and inline signing. I have run upon
> something that I cannot figure out. W
> hen I update the SOA record of the master zone file, if I reload the zone
> with "rndc reload", the SOA record
On 5/7/12 1:02 PM, "James Sheffer" wrote:
> We have been running name servers using QDNS (Mac) for eons but now I want to
> change that.
welcome to bind.
> I still have "NS1" (Master) set up and running with QDNS. It is also set to
> be the master for "NS2" so that shouldn't need changing (I ho
Hi everyone-
Newbe here...
We have been running name servers using QDNS (Mac) for eons but now I want to
change that.
I still have "NS1" (Master) set up and running with QDNS. It is also set to be
the master for "NS2" so that shouldn't need changing (I hope, although NS1 is
running BIND 4.x
thanks for the feedback!
From: sun-g...@live.com
To: b...@wingenbach.org
Subject: RE: Why does a non-delegated sub-domain work?
Date: Mon, 7 May 2012 15:44:38 -0400
Thanks for the feedback John.
Date: Mon, 7 May 2012 13:23:30 -0400
From: b...@wingenbach.org
To: bind-users@lists.is
Hi Evan,
> -Original Message-
> From: Evan Hunt [mailto:e...@isc.org]
> Sent: Monday, May 07, 2012 12:44 PM
> To: Spain, Dr. Jeffry A.
> Cc: Bischof, Ralph F. (MSFC-IS40)[NICS]; bind-users@lists.isc.org
> Subject: Re: Inline Signing does not update SOA?
>
> > Ralph: There was a lot of dis
> Ralph: There was a lot of discussion about this issue on the bind forum
> around the first of the year. My recollection is that with inline-signing
> enabled, stopping named, editing the zone file, and restarting named
> isn't a supported method of updating zone data.
That was unsupported in the
s6 is a subdomain of the parent domain. Unless otherwise specified,
subdomains are mastered (NS'd) by the parent (or extended parent domain)
containing NS records. As such, because you didn't put any NS records
in the zone file for s6, it follows the NS records of the parent which
happen to b
You are getting "lucky" that they are on the same server and when asked
about anything in the subdomain the server notices it loads it and answers
for it. It is however a landmine waiting for someone in thee future. If
you move the subdomain to another server without fixing the delegation the
subd
On 5/7/12 11:32 AM, "M. Meadows" wrote:
>
> So ... if we have
>
> exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers
>
> and ... we manage the s6.exacttarget.com zone file from ns1 and
> ns2.exacttarget.com
>
> but we don't delegate s6 in the exacttarget.com zone file
On Mon, May 7, 2012 at 7:31 AM, Spain, Dr. Jeffry A.
wrote:
>> When I update the SOA record of the master zone file, if I reload the zone
>> with "rndc reload", the SOA record is updated. If I perform a stop/start of
>> the named executable, the SOA change is not updated.
>
> Ralph: There was a
So ... if we have
exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers
and ... we manage the s6.exacttarget.com zone file from ns1 and
ns2.exacttarget.com
but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter
it in the zone file ...
how is it
> When I update the SOA record of the master zone file, if I reload the zone
> with "rndc reload", the SOA record is updated. If I perform a stop/start of
> the named executable, the SOA change is not updated.
Ralph: There was a lot of discussion about this issue on the bind forum around
the fi
On 5/7/12 8:29 AM, "hugo hugoo" wrote:
> Dear all,
>
> I have the following situation in my zone migration for one server (A) to
> another server (B)
>
> The zone is called toto.be and contains the following record:
>
> www.toto.be 86400 IN CNAME www.titi.be
>
>
> ==> the zone titi.be is i
If that's an exact copy of your record, I'm going to also assume that
the ORIGIN at the time of the record is "toto.be". As such, the
resulting record becomes:
www.toto.be.toto.be. 86400 IN CNAME www.titi.be.toto.be.
Note that trailing '.'s are required to prevent the automatic addition
of t
On 07/05/2012 15:29, hugo hugoo wrote:
Hi Hugo,
> I have the following situation in my zone migration for one server
> (A) to another server (B)
>
> The zone is called toto.be and contains the following record:
>
> www.toto.be 86400 IN CNAME www.titi.be
>
> ==> the zone titi.be is in the sam
Hi,
I am testing with BIND 9.9.0 and inline signing. I have run upon
something that I cannot figure out. When I update the SOA record of the master
zone file, if I reload the zone with "rndc reload", the SOA record is updated.
If I perform a stop/start of the named executable, the SOA c
Dear all,
I have the following situation in my zone migration for one server (A) to
another server (B)
The zone is called toto.be and contains the following record:
www.toto.be 86400 IN CNAME www.titi.be
==> the zone titi.be is in the same server (A) but is not transferred to the
server (
21 matches
Mail list logo