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 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 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 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
Hi,
Is the following expected or is it a bug?
All the best,
Terry
; This wildcard allows the lookup of test.domain A:
;
*.domain IN A 1.2.3.4
;
; This TLSA record breaks the lookup of test.domain A:
;
_443._tcp.test.domain IN TLSA 1 0 1
On 14 February 2014 12:01, Tony Finch d...@dotat.at wrote:
Terry Burton t...@terryburton.co.uk wrote:
Is the following expected or is it a bug?
It is correct. See RFC 4592 for the full explanation of how wildcards work.
For sake of Google...
RFC 4592 3.3.1 defines The closest encloser
6 matches
Mail list logo
