I'm not an ardent defender of Cloudflare by any means, but there is no grounds to sue Cloudflare. Their service is up. Their IP ranges are getting blocked by residential ISPs. How would that be Cloudflare's fault?
Google is aware and has enabled DNSSEC on their recursive resolvers for a long time. Unfortunately, most people do not DNSSEC sign their zones, so Google have to resort to also enabling 0x20, which is helpful, but also…
I think this is a bit of an apples and oranges moment. While I agree transport confidentiality is important, that is not what DNSSEC solves, nor should you see people saying that it does solve confidentiality. DNSSEC…
And? The IETF RFC draft for ADoT still specifies that it relies on DNSSEC. https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...
> there won't even be a real architectural argument for DNSSEC anymore ADoT relies on NS records to be DNSSEC signed. The TLS certificates that ADoT relies on need to be hashed into TLSA records (DANE, DNSSEC).
I'm not an ardent defender of Cloudflare by any means, but there is no grounds to sue Cloudflare. Their service is up. Their IP ranges are getting blocked by residential ISPs. How would that be Cloudflare's fault?
Google is aware and has enabled DNSSEC on their recursive resolvers for a long time. Unfortunately, most people do not DNSSEC sign their zones, so Google have to resort to also enabling 0x20, which is helpful, but also…
I think this is a bit of an apples and oranges moment. While I agree transport confidentiality is important, that is not what DNSSEC solves, nor should you see people saying that it does solve confidentiality. DNSSEC…
And? The IETF RFC draft for ADoT still specifies that it relies on DNSSEC. https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...
> there won't even be a real architectural argument for DNSSEC anymore ADoT relies on NS records to be DNSSEC signed. The TLS certificates that ADoT relies on need to be hashed into TLSA records (DANE, DNSSEC).