Hacker Newsnew | past | comments | ask | show | jobs | submit | Hazelnut2465's commentslogin

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?


>How would that be Cloudflare's fault?

Because the reason they are getting blocked is because of the actions Cloudflare is taking. If cloudflare would stop streaming these pirate broadcasts, the blocking would stop. These blocks are not just random.


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 (to an extent) security theater.


"People" in this case includes Google, which does not sign its zones.


> 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).



And? The IETF RFC draft for ADoT still specifies that it relies on DNSSEC.

https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...


Check out the DPRIVE working group (ekr's comments in particular) for some of the backstory. DNSSEC isn't happening either way, but I think ADOX might.


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 protects the transport integrity of DNS responses. DNSSEC enabled zones 100% defeat on-path cache poisoning attacks to recursive resolvers that are DNSSEC enabled. Full stop.

ADo"X" protects the transport confidentiality of DNS responses. I suppose this "weakly" protects the transport integrity of DNS responses, but, again, the primary purpose is confidentiality.

After reading RFC 9539, it's clearly stated that it's opportunistic encryption. An on-path attacker will find it trivial to disable encryption and start poisoning caches. The RFC states in multiple places that if TLS setup fails, fall back to plaintext DNS.

If DNSSEC fails, an on-path attacker has no similar recourse. A properly configured recursive resolver will SERVFAIL and _never_ send back a potentially poisoned response to clients for DNSSEC signed zones.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: