(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)
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.
Resolvers could also just drop the connection. The only thing they can't do with DNSSEC is falsifying a NXDOMAIN result.
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.
Its impossible to prevent denial of service generally, but you can use crypto to detect when it might be happening.