What difference would it make to you as a user between "this domain doesn't exist" and "this domain doesn't exit, but I refuse to give you valid proof that it doesn't" (or even no answer at all)?
(NXDOMAIN is also somewhat special in DNSSEC and not signed by default, and requires special mechanisms to handle (NSEC, NSEC3), but IMHO that's not even very relevant to the block scenario)
> What difference would it make to you as a user between "this domain doesn't exist" and "this domain doesn't exit, but I refuse to give you valid proof that it doesn't" (or even no answer at all)?
If you're validating then the second answer should cause you to regard the reply as invalid and retry the request, possibly using a different DNS service.
True, a system that is setup with multiple resolvers of which only one censors might actually do get you the page in the end. But from the perspective of the DNS provider, they've done what they "intended"/were forced to do in any case: not give you the correct answer.
All that DNSSEC does is to let you validate whether a DNS response is authentic. If you don't get a result that validates successfully, you know there's something wrong, but you still don't know what the right result is, so it doesn't stop censorship.
So, in conventional DNS this is problematic since of course a false answer isn't valid under DNSSEC the server can't even deny the existence of a name without proof this denial is authoritative which it doesn't have. It may have to SERVFAIL or give an obviously inauthentic response.
In DoH the HTTP error codes provide a way for the server to explain why it can't (or won't) give you the correct answer to your query, for example because you set it to block advertising, or your government obliges it to censor domains, separate from the actual DNS answer or absence of one.
This will grow even more interesting under oblivious DNS, a planned future upgrade to the DPRIVE protocols in which you'd send your questions to an intermediate (e.g. quad 9 in this case) but those questions are encrypted so they can't read the details, and the intermediate forwards them to an authoritative name server (which thus doesn't learn your IP address) that can decrypt them, before sending the response back to you without being able to read it.
This obliviousness means that on the one hand Google, Cloudflare and similar large DNS providers don't see what exactly it is you wanted to know about example.com (if www.example.com is the only thing that exists this isn't much help, but if clown-porn.example.com, adopt-a-puppy.example.com and holocaust-survivor.example.com are all under example.com then this makes a real difference to your privacy) and yet on the other the people operating example.com don't get your IP address (at least until you connect directly to their servers over plain TCP) and yet you still get the answer you wanted.
