A couple of remarks below:
On Nov 4, 2014, at 18:07, Brian Dickson wrote:
> The good news is, for most cases, setting up a DLV-based "fix" can be done,
> with only the DNSKEY(KSK).
> I.e. modifying responses is not required AT ALL, and no new DNSKEYs or
> signatures are needed.
Recall that DL
TL;DR
As Tony Finch observed, the benefit is only seen when SEP failures occur,
most often in key-rolls. I'd argue that the vast majority of observed
DNSSEC failures have been of the key-roll (or initial set-up) variety with
mismatches between DS and DNSKEY, but otherwise properly signed (by ZSK)
Sent from my iPhone
> On Nov 1, 2014, at 4:30 PM, Warren Kumari wrote:
>
> On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson
> wrote:
>> I think it is good to minimize disruption caused by broken DNSSEC domains,
>> for all the reasons listed in the document.
>>
>> However, I also believe there
On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson
wrote:
> I think it is good to minimize disruption caused by broken DNSSEC domains,
> for all the reasons listed in the document.
>
> However, I also believe there is a second-order negative effect of
> implementing NTAs as described.
>
> Validating s
Brian Dickson wrote:
> For anyone using an open, well-known resolver (either provided by their
> ISP, or operated as a "public service"), include instructions on use of a
> provider-specific DLV and provider-specific "alternative trust anchor
> (DNSKEY)".
I think your suggestion will only work f
I think it is good to minimize disruption caused by broken DNSSEC domains,
for all the reasons listed in the document.
However, I also believe there is a second-order negative effect of
implementing NTAs as described.
Validating stub resolvers and validating forwarding resolvers, will still
break