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
It can provide that as well if you configure your DNS server with a list of
authorized IP addresses for certain zones. In other words, you let your DNS
server know from which IP addresses it can accept updates for a particular zone.
In this case, CGA-TSIG can be helpful,as well, as it can provide t
Usually, DNSSEC can stop cache poisoning attack. And for such event where the
Resource Records are wrongly updated, maybe the method provided by
draft-jabley-dnsop-dns-flush-00 is useful to flush the bad resource records on
recursive DNS servers.
Guangqing Deng
CNNIC
From: Hosnieh
Date: 20
Cga-tsig approach can make sure that the content transferred between resolvers
and DNS servers is not maliciously modified by others; while this approach
cannot prevent the Resource Record (RR) from being wrongly updated by the
registrar (namely man-made mistakes). Then it seems that one kind of
Follow up,
If you have a secure mechanism that does not allow attackers to do cache
poisioning on the client's stub resolver, then this solve the problem of
malicious websites as well.
Best,
Hosnieh___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.
I think this problem has a solution in IPv6, but I am not sure for IPv4. The
current draft, cga-tsig proposed to automate the process of authentication of
resolvers (DNS query resolution) and DNS servers (DNS update) in a secure
manner.
You can take a look on that draft.
Best,
Hosnieh
> On August
