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

record to the next, the initialization vectors for CBC ciphers (prior to TLS 1.0)
must be carried forward, and so on.
This is perfectly acceptable in the context of TCP, which keeps track of its own
sequence numbers and internally handles reordering of out-of-sequence packets
and retransmission of lost packets. However, TCP provides these services at a
cost in terms of per-packet overhead and per-socket handshake time. Although
on modern networks this overhead is practically negligible, a lighter-weight
alternative, called User Datagram Protocol (UDP), has been part of TCP/IP almost
from the beginning. With UDP, a packet is built and sent across the network
with almost no header or routing information — just enough to identify a source
and a target machine and a port.
This section examines the application of TLS concepts to datagram traffi c.
Securing the Domain Name System
Chapter 1 presented, but didn't examine in-depth, the mapping between user-
friendly hostnames and IP addresses. Ordinarily, a user doesn't connect to
http://64.170.98.32/index.html but instead connects to http://www.ietf
.org/index.html . This mapping of (arguably) human-readable domain names
to machine-readable IP addresses is maintained by the Domain Name System
(DNS). There's no automatic transformation that's applied here; the IP address
isn't derived from the host name using some complex algorithm such as Base64;
you can associate any host name with any IP address, as long as you can add
an entry into the global DNS database.
This database is huge and must be widely distributed. DNS describes a hier-
archical management system where the top-level keeps track of the registrars
for the ending parts of a DNS name such as .org, .com, .gov, and so on. These
registrars, in turn, keep track of the registrars for the next-level — the part that
comes before the .com . You can nest these names as deeply as you can imagine
until an authoritative name server , which maps a completed domain name back
to an actual IP address, is found. This hierarchy is illustrated in Figure 10-2.
There are thirteen master copies of the important top-level database, named
A-M, distributed throughout the world and continuously synchronized. The
website http://root-servers.org/ documents where these servers are physi-
cally located, what their IP addresses are, and who administers them. These
copies are referred to as the Root DNS servers, and are considered authoritative.
VeriSign, for example, operates the “J” root DNS servers, which have IP address
192.58.128.30. If VeriSign's root server states that .org is owned by a registrar at
IP address XX.XX.XX.XX, then the Internet Corporation for Assigned Names
and Numbers (ICANN)'s copy at 199.7.83.42 will say the same thing.
However, you probably don't (and probably shouldn't) request domain-name
information from these root servers or the next-level registrars. Although each