Hijack of Amazon’s domain service used to reroute web traffic for two hours

Re:Hijack of Amazon’s domain service used to reroute web tra... by tialaramex on Tuesday April 24, 2018 @08:37PM (#16917887)

So, you should not be surprised (but perhaps you are anyway) that how to work around not having DNSSEC on end systems is exactly what this work was about. Specifically, the idea is you shove DNSSEC RRs into TLS. Now the client doesn't need working DNSSEC, because the DNSSEC records were delivered with the connection. Hence the pinning question.

[ Parent | on HN ]

Re:Hijack of Amazon’s domain service used to reroute web tra... by raldi on Wednesday April 25, 2018 @09:10AM (#16921182)

There's also https://tools.ietf.org/html/rfc4956 , which allows a domain to sign that a range of DNS entries does not exist; under this system, a client resolver could demand cryptographic proof that a domain was missing certain records, which stops the MitM RR-stripping attack.

[ Parent | on HN ]

Re:Hijack of Amazon’s domain service used to reroute web tra... by tptacek on Wednesday April 25, 2018 @11:04AM (#16922131)

You're describing authenticated denial, which has been a characteristic of DNSSEC since 1994.

[ Parent | on HN ]

Re:Hijack of Amazon’s domain service used to reroute web tra... by raldi on Wednesday April 25, 2018 @11:26AM (#16922370)

Yes, exactly. The RFC I linked to specifically refers to Authenticated Denial in the Security Considerations section.

[ Parent | on HN ]