When a Windows computer wants to resolve a domain name, it offloads the request to a DNS resolver and tells the resolver that it wants to resolve with DNSSEC (by setting the 'DO' bit in the query). The DNS resolver will use DNSSEC and will validate every query it receives while it contacts authoritative name servers to resolve the domain.
But what of the last mile i.e, when the 'claimed' DNSSEC-signed query response is sent from the DNS resolver to the client computer? What is stopping an attacker who is connected to the client computer's local network (say via WiFi) from modifying the DNSSEC-signed query response? Is there some way the client (Windows) computer is able to validate the DNSSEC-signed response it receives?
I've done quite a bit of searching and I've gotten a hint of something called 'DNSSEC Client Validation' but that DNSSEC Client validation isn't enabled by default for example on Windows (a user has to manually install some external tool for DNS Client validation). But what exactly is DNSSEC Client validation? In particular, how does the process work?
Here (under the FAQ: How is DNSSEC validation enabled?):
The expectation is that validation by the client will increasingly become the norm. That arrangement would resolve the problem of the 'last mile'. It would also enable web browsers and other applications on the client to do their own validation. And that in turn would mean that the user could be provided with explanatory information when validation fails.
We are now seeing a prominent trend towards the use of DoT, DoH and DoQ in resolvers and applications. However, those technologies secure only transport between the resolver and application on the one side, and the configured DNS service on the other. They do not assure the authenticity of the DNS information; that still requires DNSSEC validation.
Side question: is the question of no DNS validation on the client side no longer an issue if TLS is pre-initiated before the client computer and the DNS resolver?
