On 7 Oct 2014 22:35, "Alan Clegg" wrote:
>
> On 10/7/2014 2:03 PM, Terry Burton wrote:
>>
>> On 7 Oct 2014 18:42, "Alan Clegg" > <mailto:a...@clegg.com>> wrote:
>> >
>> > On 10/7/2014 9:49 AM, Terry Burton wrote:
>>
On 7 Oct 2014 21:44, "Doug Barton" 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
On 7 Oct 2014 18:42, "Alan Clegg" 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 "
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 signatures
On 14 February 2014 12:01, Tony Finch wrote:
> Terry Burton 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 is the node i
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
83cfeec8dbe315e9f93e9ec87beda3619033876f1f9672
6 matches
Mail list logo
