Foundations of Python Network Programming

Chapter 4 ■ SoCket NameS aNd dNS

67

•    You have not given the socket() constructor a list of three separate items. Instead, the

parameter list is introduced by an asterisk, which means that the three elements of

the socket_args list are passed as three separate parameters to the constructor. This is the

opposite of what you need to do with the actual address returned, which is instead passed as a

single unit into all of the socket routines that need it.

The DNS Protocol

The Domain Name System (DNS) is the scheme by which millions of Internet hosts cooperate to answer the question
of what hostnames resolve to which IP addresses. The DNS is behind the fact that you can type python.org into your
web browser instead of always having to remember 82.94.164.162 for those of you on IPv4, or 2001:888:2000:d::a2
if you are already enjoying IPv6.

the DNS prOtOCOL

purpose: resolve hostnames by returning Ip addresses

Standard: rFC 1034 and rFC 1035 (from 1987)

runs atop: Udp/Ip and tCp/Ip

port number: 53

Libraries: third-party, including dnspython3

The messages that computers send to perform this resolution traverse a hierarchy of servers. If your local
computer and name server cannot resolve a hostname because it neither is local to your organization nor has it been
seen recently enough to still be in the name server’s cache, then the next step is to query one of the world’s top-level
name servers to find out which machines are responsible for the domain about which you need to inquire. Once the
DNS server IP addresses have been returned, they in turn can be queried for the domain name itself.
Before examining the details, we should first step back for a moment and see how this operation is usually set
in motion.
Consider the domain name http://www.python.org. If your web browser needs to know this address, then the browser
runs a call like getaddrinfo() to ask the operating system to resolve that name. Your system itself will know either
that it is running a name server of its own or that the network to which it is attached provides name service. Your
machine typically configures name server information automatically through DHCP these days when it connects to
the network—whether to a LAN in a corporate office or an educational institution, on a wireless network, or over a
home cable or DSL connection. In other cases, the DNS server IP addresses will have been configured by hand when
a system administrator set up your machine. Either way, the DNS servers must be specified by their raw IP addresses
since you obviously cannot perform any DNS queries until you know some other way to reach the servers.
Sometimes people are unhappy with their ISP’s DNS behavior or performance and they choose to configure
a third-party DNS server of their own choosing, like the servers at 8.8.8.8 and 8.8.4.4 run by Google. In some
rare cases, the local DNS domain name servers are known through some other set of names in use by the computer
like the WINS Windows naming service. One way or another, however, a DNS server must be identified for name
resolution to be possible.
Your computer knows some hostnames without even consulting the domain name service. Querying DNS
for a hostname is not actually the first thing that an operating system usually does when you make a call like
getaddrinfo(). In fact, because making a DNS query can be time-consuming, it is often the last choice! Depending
on the hosts entry in your /etc/nsswitch.conf file if you are on a POSIX box, or else depending on your Windows
Control Panel settings, there might be one or several other places that the operating system looks first before turning