Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The root DNS servers basically only tell you where the registry servers are, they don't contain records themselves. If someone censored a domain at the registry level then the root servers would be no help


This is true but I can imagine where they might go after the lowest reachable branch of the tree, up to threatening to remove country-level TLDs from the root servers for noncompliance. Only the US really has the leverage to do this, and it would just fragment the internet, as additional root servers would pop up to serve the missing TLDs. So it’s unlikely but possible.


"Additional root servers" popping up that would server missing TLDs would fail DNSSEC validation unless you modified the root hints and turned off DNSSEC or resigned the root zone and updated the trust anchors in validating resolvers.


Oh it would be chaos, but I’m sure there would be a workaround available within a week. Alternative roots already exist: https://en.wikipedia.org/wiki/Alternative_DNS_root


But the query is of the whole name. In theory they could nxdomain blocked names.

But long ttls and caches would mostly break this as an approach


Ever since the Verisign coup in 2003, the world has had the idea of "delegation-only" and suchlike filtering on responses from superdomain servers. More recently, query minimization was invented. Both of these can militate against the root content DNS servers doing that.

Better still, one can run one's own private root content DNS server. I've been doing that (in several ways) for a couple of decades. If ICANN decided to blackhole (say) www.microsoft.com. tomorrow, my DNS lookups wouldn't be affected.

To affect them, the aforementioned "court action" would have to target Verisign.


I'm curious: how did you implement your "private root content" DNS server such that it keeps up with (valid -- and how would you know?) updates made by the TLD registries via IANA?


Yes and no. See QNAME Minimization (https://datatracker.ietf.org/doc/html/rfc7816.html).




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

Search: