Please also note that the below test is successful with a prefetch value of 0.
To me this really looks like prefetching forgets to update RRSIGs.
Thomas
> On 06.07.2016, at 15:29, Thomas Sturm wrote:
>
> Hi Mark,
>
> I may have found another (possibly related?) bug:
>
>
n review and should be in the next maintainance
> release.
>
> Mark
>
> In message <16a2cdfd-694d-444a-a760-17c9d7517...@open.ch>, Thomas Sturm
> writes:
>>
>> I am now able to reliably reproduce the behaviour with dig querying BIND
>> 9.10.4-P1 (not
re be an issue
processing cached client requests during cache expiry, and since it only
happens on 9.10, potentially related to prefetching?
> On 16.06.2016, at 10:00, Thomas Sturm wrote:
>
> Hi,
>
> We are experiencing strange intermittent issues when resolving
> outlook.
> If you're running bind 9.10, then bind 9.10 doing prefetch is a normal
> use-case.
>
> You make a good point that a prefetch-enabled resolver might show different
> behaviour to a non-prefetch one. But we've been on prefetch-enabled resolvers
> for the whole length of our o365 rollout IIRC,
Hi,
We are experiencing strange intermittent issues when resolving
outlook.office365.com, but also with other domains like e.g. amazonaws.com or
snort.org. But let’s choose office365.com as example for now.
outlook.office365.com is a CNAME to lb.geo.office365.com, and office365.com
delegates t
On 03.02.2016 09:36, Mark Andrews wrote:
No. Insecure != invalid. Insecure zones don't have a DNSSEC chain
of trust to a configured trust anchor.
OK, understood. However, in the case of an unsigned private domain that
is forwarded, it would be insecure and not invalid, right? What's the
rea
Dear all,
According to the documentation of the option 'dnssec-must-be-secure',
which reads like
"Specify hierarchies which must be or may not be secure (signed
and validated). If yes, then named will only accept answers if
they are secure. If no, then normal DNSSEC validation app
7 matches
Mail list logo
