How to understand the ins and outs of how DNS really works.

We're working on a project that needs some teamwork across different teams, and we’ve got to connect to an API. Since the outside team can't just jump in and edit my API definitions, we thought we'd use Apidog's doc publishing feature. I looked through their help docs and found out that the API docs update in real-time and you can even debug right there on the page, and today I realized I can customize the domain name for the published docs, which is an awesome feature for me:

While we were working on it, one of my teammates asked, “What’s a CNAME?” I just gave a quick rundown based on what I know. It sparked a great discussion, and it made me want to dig deeper into the whole DNS thing and really get a better grasp on it.

The way DNS works is often taken for granted. Basically, DNS is used for converting website names into IP addresses, so you can think of it like this: you input a URL, and it spits out an IP.

DNS mainly uses this protocol, which is based on UDP. Because of this, DNS servers can handle an incredible number of queries per second—much higher than web servers, which rely on TCP. It’s important to know about different types of DNS records, including:

• A records: these link a domain name to an IPv4 address.
• AAAA records: these link a domain name to an IPv6 address.
• CNAME records: used for forwarding during the query process.

1. When you type www.apidog.com into your browser, the DNS protocol actually uses www.apidog.com. It ends with a dot ., but that’s usually not shown for looks.
2. The browser first checks its local cache (like the host file or browser history) to see if it already has a record for that domain. If it does, it uses that.
3. If not, the browser sends a DNS request to the ISP’s DNS server, often called local DNS.
4. The local DNS checks its own cache. It’s important that the caching time is just right—too long or too short can cause issues. Also, how local DNS queries work is up to the ISP, which can get pretty complicated.
5. If local DNS doesn’t have the information cached, it starts scanning the domain name from right to left, asking the proper servers along the way. For www.apidog.com, it first checks with the root name server (those rare servers that handle .). They will tell it who is in charge of .com, leading the local DNS to look for the server that manages .com (let’s call that S1) to find out who manages apidog.com. Usually, S1 returns a CNAME record, redirecting the query to the authoritative DNS server.
6. The authoritative server looks up its settings to find the server for www.apidog.com and sends back an IP address.
7. Local DNS caches that IP address and sends it back to the browser.
8. Finally, the browser establishes a TCP connection with that IP address's server and sends an HTTP request.

For anyone who’s bought a domain, you know that if you want to start an AI project and buy the domain xmanhugo.com from GoDaddy, and then you want to create a subdomain like ai.xmanhugo.com, you need to set up an A record in GoDaddy’s dashboard to point ai.xmanhugo.com to a specific IP. Each time you set up a subdomain, you follow this same process. Knowing how DNS resolution works lets you do a few things:

1. Set up a DNS server on D1, making it the authoritative DNS server for xmanhugo.com.
2. In Wanwang’s dashboard, add a new CNAME record to redirect xmanhugo.com queries to D1.
3. D1 can return any IP address it chooses.

With this setup, you gain total control since D1 is yours, and you won’t need to access Wanwang’s console anymore. This is what running your own DNS server gets you!