We talk a lot about digital advertising, but sometimes it's worth taking a step back to think about what exactly is happening on the web. Today we're talking about DNS, or the Domain Name System. As you'll see, in isolation, DNS establishes some of the framework necessary for a fully-functioning internet, which we'll go into more in future Internet Basics Lift Letters™.
When you type adexchanger.com into your browser and hit enter, what happens? Just like your phone, when you dial "Mom" (which you should do more, she misses you) - you're actually calling a number. There's a translation that happens to go from the human-readable, text version of the domain to a computer-readable digital form. These computer versions are called internet protocol addresses (IP address). DNS is what makes that translation possible.
Behind the scenes, websites can have multiple IP addresses associated with them, and they can change at any given time. Also, if a website is theoretically mapped to the wrong IP address, perhaps by a malicious actor, they could do some bad things. Finally, you want a system that's resilient. If the system went down, for whatever reason, nobody would be able to access anything that they didn't already have the mapping for - so being stable and distributed are vital.
When you type in adexchanger.com, the browser needs the DNS translation, so it has to issue a request to a DNS server. But who exactly is the DNS server and how does it know the mappings? Basically at various levels - your ISP or cell company, or a company's network, there is a cache of "root" name servers. There are 13 groups of name servers, each of which consists of thousands of actual servers, and are managed by a variety of entities including Verisign, the US military, NASA, the University of Maryland, etc. These root servers contain a mapping for each suffix (e.g. .com, .org, etc) to a top level domain ("TLD") name server. So the initial request for adexchanger.com would be root server for the .com TLD, then a DNS lookup directed to the .com TLD server. It's worth noting that all but 3 "root" server groups, which at some level control the operation of the internet, are managed by American entities - and the control over who manages the root server groups belongs ultimately to the US Department of Commerce.
The actual requests are generally not done by the "browser" itself, but a "recursive resolver" which is either in the operating system or at the ISP, but that doesn't really matter. Each TLD server stores the information for all the next-level information. Meaning the .com servers store the mappings all the .com domains. The TLD server will respond with the name server (not the IP address) for the domain you requested. Finally, your recursive resolver would send a request to the domain's name server - in this case, the name server for adexchanger.com and get the IP address. If you had requested events.adexchanger.com, instead of requesting adexchanger.com, your recursive resolver would have gotten the name server for events.adexchenger.com from the adexchanger.com domain name server, then issued a followup request for the final IP. Only after getting the IP address does the browser issue the web actual request.
As you can imagine, there are a lot of DNS lookups. The root and TLD servers are particularly resilient, with sophisticated load balancing techniques. There is also a lot of upstream caching by various layers, including your computer, company networks, ISPs, etc. Each cache entry has a time-to-live (TTL), meaning you cannot instantaneously expect changes in DNS entries to be reflected in requests - and meaning that requests for the same information won't be done for the duration of that TTL period.
Finally, you may be curious whether malicious attackers ever try to take down the internet by taking down the root servers. It is, indeed, the case that if the root servers went down - after the various levels of caching expired in a few days - there would be some chaos. There have been several attempts to do just this, including one last year that featured 5 million requests per second aimed at a single server with the intent of breaking it and, possibly eventually the internet. It didn't work.