Measures to protect against DNS spoofing are either aimed at including more random information in the DNS message that the attacker has to guess or protecting the message with cryptographic techniques. Since the Kaminsky attack became known, all common name servers have been using source port randomization. In addition to the transaction number, the source port of a DNS request in the UDP header is also randomly selected. Depending on the implementation, this results in an additional 11-16 bits, which the attacker also has to guess correctly.
Another method is 0x20-bit encoding, in which letters in the requested domain name are randomly placed in upper and lower case letters, for example thecustomizewindows.com. When it comes to name resolution, uppercase and lowercase letters are generally equivalent, with RFC 1034 saying that the spelling of the response should correspond to the request name. The length of the additional randomness depends on the number of letters in the domain name.
What these methods have in common is that the message format does not need to be adapted and the methods are therefore largely compatible with the existing DNS infrastructure. DNS spoofing is still feasible in principle, but the increased space of the parameters to be guessed reduces the probability of success of a remote attacker. None of the methods to increase randomness protects against an attacker who can read the DNS request (on-path attacker).
---
Another category of protection measures is to extend the DNS message format with digital signatures or message authentication codes, which are generated and verified using cryptographic methods. An attacker can generate spoofed DNS responses, but without knowledge of the secret key, they cannot generate a matching signature.
A well-known method is DNSSEC, in which resource records are signed with asymmetric cryptosystems. DNSSEC is partly used in practice, but the majority of DNS Internet traffic is not protected by it.
An alternative method to DNSSEC is DNSCurve, in which the communication channel between the resolver and the name server is cryptographically protected instead of resource records. It employs a combination of asymmetric and symmetric cryptosystems. An adaptation of DNSCurve is DNSCrypt, which uses OpenDNS to secure communication between the end user and the resolver.
Similar to DNSCurve or DNSCrypt, TSIG secures communication between two DNS participants. To do this, it uses HMAC with symmetric keys that have to be configured manually. Another method is DNS over HTTPS, in which DNS queries are transmitted encrypted via the HTTPS protocol.
