The DNS Protocol purpose is to turn hostnames into IP addresses.
For example, consider the domain name 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 will know either that it is running a nameserver of its own, or that the network to
which it is attached provides name service.So, the first act of your DNS server will be to check its own cache of recently queried domain names to
see if www.python.org has already been checked by some other machine served by the DNS server in the
last few minutes or hours. If an entry is present and has not yet expired—and the owner of each domain
name gets to choose its expiration timeout, because some organizations like to change IP addresses
quickly if they need to, while others are happy to have old IP addresses linger for hours or days in the
world's DNS caches—then it can be returned immediately. But let us imagine that it is morning and that
you are the first person in your office or in the coffee shop to try talking to www.python.org today, and so
the DNS server has to go find the hostname from scratch.
Your DNS server will now begin a recursive process of asking about www.python.org at the very top of
the world's DNS server hierarchy: the “root-level” nameservers that know all of the top-level domains
(TLDs) like .com, .org, .net, and all of the country domains, and know the groups of servers that are
responsible for each. Nameserver software generally comes with the IP addresses of these top-level
servers built in, to solve the bootstrapping problem of how you find any domain nameservers before you
are actually connected to the domain name system.With this first UDP round-trip, your DNS server will
learn (if it did not know already from another recent query) which servers keep the full index of .org
Now a second DNS request will be made, this time to one of the .org servers, asking who on earth runs the python.org domain. You can find out what those top-level servers know about a domain by running the whois command-line program on a POSIX system, or use one of the many “whois” web pages online, typing:
Wherever you are in the world, your DNS request for any hostname within python.org must be passed on to one of the two DNS servers named in that entry.
There are some reasond to not use DNS, and use
getaddrinfo() or some other system-supported mechanism for resolving hostnames.
The DNS is often not the only way that a system gets name information.
There is, however, a solid and legitimate reason to make a DNS call from Python: because you are a mail server, or at the very least a client trying to send mail directly to your recipients without needing to run a local mail relay, and you want to look up the MX records associated with a domain so that you can find the correct mail server for your friends at @example.com.