If a device sends a request to https://example.com and someone spoofs the DNS response to redirect the request to some malicious server. Would the attacker be able to modify the packets during the TLS handshake to make the original request domain name match and therefore establish the connection?
The TLS connection needs to validate the server certificate, and the attacker will not have a valid
example.com certificate. He can either create a self-signed certificate, or a certificate signed by a CA (Certificate Authority) that he owns. And that attacker will not own a valid CA that is trusted by browsers unless he is a government, and even if he is, his CA will be blacklisted very fast.
On both cases, the client browser will show the "Invalid Certificate" warning, and the client will have to acknowledge that and tell the browser to load the site anyway.
That's why TLS was created: to defeat MitM attacks like that. With the certificates and list of trusted CAs, every client can be sure that he is talking to the server he thinks he is talking to, and nobody but he and the server can know what is being transmitted.
There are a couple issues with TLS (and SSL before it) that can allow an attacker to know what is being transmitted or change something, but those attacks are quickly patched.