as one of the as112 co-authors, i'll chime-in here.
you're right, there's an opportunity to leverage an existing mechanism and
registry for this draft. both rfc 6303 and rfc 6304 were developed at
different times so there's a little bit of a disconnect between those as
well. i think my draf
The referenced draft seems strongly related to DNSOP as well,
but to avoid cross-posting, here's only the initial part of
my review just posted to the dnsext mailing list.
start of forwarded message
Hi,
I've performed a quick review of the DNSEXT-related I-D,
draft-cheshire-
I posted a –01 a short time ago
(http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) and
listed this in open items for the next version. I may have some questions on
the best way to include that.
Jason
On 3/27/12 2:04 PM, "Antoin Verschuren"
mailto:antoin.verschu...@sidn.nl>
Op 27 mrt. 2012, om 12:04 heeft Tony Finch het volgende geschreven:
>
> Do you mean insecure (no DS) or bogus (broken RRSIGs)?
Both, and also DS at parent but no RRSIGs or no DNSKEY in child.
Actually it does not matter how they are broken, but that the brokenness is not
meant to be fixed by a
On Mar 27, 2012, at 12:04 PM, Tony Finch wrote:
> Antoin Verschuren wrote:
>
>> I read the draft, and I seem to be missing a part where a domain is
>> intentionally insecure. Such a situation might occur f.e. in tools
>> investigating if DNSSEC is working properly from an end user
>> perspectiv
Antoin Verschuren wrote:
> I read the draft, and I seem to be missing a part where a domain is
> intentionally insecure. Such a situation might occur f.e. in tools
> investigating if DNSSEC is working properly from an end user
> perspective. I can also imagine there are other situations where DNS
I read the draft, and I seem to be missing a part where a domain is
intentionally insecure.
Such a situation might occur f.e. in tools investigating if DNSSEC is working
properly from an end user perspective.
I can also imagine there are other situations where DNSSEC validation is broken
on purp