On Oct 17 2014, Darcy Kevin (FCA) wrote:
FYI,
If you had to do this all over again, and your tools are flexible
enough to handle arbitrary RRTYPEs, you might consider using a private
RRTYPE (in the 65280-65534 range). See
On Oct 8 2014, Tony Finch wrote:
Terry Burton t...@terryburton.co.uk wrote:
This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated by some
provisioning system that owns the serial number.
Our provisioning system used to
-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Thompson
Sent: Friday, October 17, 2014 12:23 PM
To: Bind Users Mailing List
Cc: Tony Finch
Subject: Re: Inline-signing feature request: Directly set the signed zone's
serial number
On Oct 8
Hi,
After reinitialising the inline-signing process (for example by
removing the journal files or redeploying the master server) the
freshly signed zone's serial number will usually be behind the
authoritative version on the slaves causing transfers to fail
possibly leading to expired
Terry Burton t...@terryburton.co.uk wrote:
This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated by some
provisioning system that owns the serial number.
Our provisioning system used to think it owned zone serial numbers,
Hi,
After reinitialising the inline-signing process (for example by
removing the journal files or redeploying the master server) the
freshly signed zone's serial number will usually be behind the
authoritative version on the slaves causing transfers to fail —
possibly leading to expired
On 10/7/2014 9:49 AM, Terry Burton wrote:
This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated by some
provisioning system that owns the serial number.
By setting the number backwards, you are breaking all of your slave
On 7 Oct 2014 18:42, Alan Clegg a...@clegg.com wrote:
On 10/7/2014 9:49 AM, Terry Burton wrote:
This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated by some
provisioning system that owns the serial number.
By setting
On 10/7/14 11:03 AM, Terry Burton wrote:
With inline signing you have a hidden serial number in the unsigned zone
and an exposed serial number in the signed versions which your slaves
track. After redeployment (following DR, emergency relocation, elastic
capacity expansion, etc.) I want to be
On 7 Oct 2014 21:44, Doug Barton do...@dougbarton.us wrote:
On 10/7/14 11:03 AM, Terry Burton wrote:
With inline signing you have a hidden serial number in the unsigned zone
and an exposed serial number in the signed versions which your slaves
track. After redeployment (following DR,
On 10/7/2014 2:03 PM, Terry Burton wrote:
On 7 Oct 2014 18:42, Alan Clegg a...@clegg.com
mailto:a...@clegg.com wrote:
On 10/7/2014 9:49 AM, Terry Burton wrote:
This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated
-Original Message-
From: bind-users-boun...@lists.isc.org [mailto:bind-users-
boun...@lists.isc.org] On Behalf Of Alan Clegg
Sent: Wednesday, 8 October 2014 8:35 AM
To: bind-users@lists.isc.org
Subject: Re: Inline-signing feature request: Directly set the signed
zone's serial number
On 7 Oct 2014 22:35, Alan Clegg a...@clegg.com wrote:
On 10/7/2014 2:03 PM, Terry Burton wrote:
On 7 Oct 2014 18:42, Alan Clegg a...@clegg.com
mailto:a...@clegg.com wrote:
On 10/7/2014 9:49 AM, Terry Burton wrote:
This is especially useful in bootstrapping scenarios where the zone
On 10/7/2014 7:39 PM, Terry Burton wrote:
Separate the data provider and DNS infrastructure provider and this
predicament ensues.
Ah, but here-in lies trouble. You are becoming the data provider as
soon as you do the signing on the data. But I digress.
What about rndc sign -force that
14 matches
Mail list logo
