Zitat von Nicholas Weaver :
One thought on DNSSEC and this (nytimes.com) attack.
Nickolas,
your suggestion try to solve the problem by inspecting common behaviour.
What about providing a policy statement?
I imagine an extension, where the subdomain declares an explicit
statement to the TL
On Aug 28, 2013, at 8:37 AM, Paul Wouters wrote:
...
> Sounds like certificate pinning or CT-DNSSEC. It has the same problems.
> There will be more false positives then actual attacks, and people will
> disable it.
Of course, that argument also says "Ditch DNSSEC altogether, bypass the
recurs
One thought on DNSSEC and this attack.
DNSSEC couldn't have prevented this attack, as anyone authorized to update the
.com zone for a domain can update the DS records just as easily as the NS+glue
records. And the attack could have done orders of magnitude more damage.
Yet DNSSEC can create a
On Wed, 28 Aug 2013, Nicholas Weaver wrote:
How does the following policy strike people for DNSSEC recursive resolvers
which perform validation:
Keep all seen DS and PARENT NS+glue RRSETs in a much-longer-than-normal (2 day
timeout) cache.
When the DS or parent NS+glue RRSET changes, record
