Other Applications of SSL - Implementing SSL/TLS Using Cryptography and PKI - page 556

like they are in TCP. After you send a UDP request, you just wait for data — any
data at all — to be returned with the ports reversed. If a client has multiple out-
standing DNS queries, it is responsible for correlating the responses correctly.
DNS mandates that every request has a unique transaction ID for this purpose.
Herein lies the problem. Any malicious user on the network can easily spoof
a DNS reply; all he needs to know is the source port (the destination port is
always 53) and the transaction ID, both of which can be obtained with a packet
sniffer. TCP is harder to spoof this way (but not impossible); UDP's stateless
nature makes it simple. All the attacker has to do is to respond faster than the
name server. The name server's response is received and ignored at a later time.
This gets even worse when you consider that if a name server doesn't have
an IP address for a given domain name, it queries the next-higher name server,
up to the root servers. An attacker can respond to the name server with his own
bogus record. If he does so, then the name server dutifully caches the wrong
information and then hands it out to all of the clients that it services. This is
called DNS cache poisoning . In 2008, security researcher Dan Kaminsky showed
how to subvert this process completely and poison the authority record, thereby
taking over not just individual hosts, but entire domains.
Preventing DNS Cache Poisoning with DNSSEC
Although there are stopgaps to make DNS cache poisoning harder — better
randomization of the transaction ID, wider variance of the request source port,
and a check to see if multiple responses are received for the same query (a sure
sign that something's amiss) — there have been efforts to roll out DNS Security
(DNSSEC). This was specifi ed back in 1999 by RFC 2535 and in spite of the fl aws
in the DNS system still has not been widely deployed. The idea behind DNSSEC
is to deploy a public-key infrastructure around the domain-name system and
sign each DNS record. If the receiver has a copy of a public key, the signature
can be verifi ed.
You can explore the DNS system using the dig tool that comes standard on
all Unix systems. If you want to see the IP address for www.ietf.org , you can
do this:
debian:ssl$ dig www.ietf.org
; <<>> DiG 9.3.4 <<>> www.ietf.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24804
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.ietf.org. IN A