<story><title>What happens when you update your DNS</title><url>https://jvns.ca/blog/how-updating-dns-works/</url></story><parent_chain><item><author>eat_veggies</author><text>One of my favorite revelations about the network tracing tools (things like `traceroute` and `dig +trace`) that might not be obvious for people like me who work higher up in the stack, is that the data they provide isn&amp;#x27;t usually made available during &amp;quot;normal&amp;quot; usage. Packets don&amp;#x27;t just phone home and tell you where they&amp;#x27;ve been. Something else is going on.&lt;p&gt;When you send a DNS query to a recursive server like your ISP&amp;#x27;s or something like 1.1.1.1, you make a single DNS query and get back a single response, because the recursive DNS server handles all the different queries that Julia outlines in the post. As the client, we have no idea what steps just happened in the background.&lt;p&gt;But when you run `dig +trace`, dig is actually &lt;i&gt;pretending to be a recursive name server&lt;/i&gt;, and making all those queries &lt;i&gt;itself&lt;/i&gt; instead of letting the real recursive name servers do their work. It&amp;#x27;s a fun hack but that means it&amp;#x27;s not always 100% accurate to what&amp;#x27;s going on in the real world [0]&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;serverfault.com&amp;#x2F;questions&amp;#x2F;482913&amp;#x2F;is-dig-trace-always-accurate&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;serverfault.com&amp;#x2F;questions&amp;#x2F;482913&amp;#x2F;is-dig-trace-always...&lt;/a&gt;</text></item></parent_chain><comment><author>closeparen</author><text>Traceroute’s trick is amusing. It abuses the TTL field, sending out packets with too-low TTLs and waiting to see who complains about them. When layers reveal themselves they are doing it voluntarily, and those wise to the game can choose not to participate, or to troll it.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.theregister.com&amp;#x2F;2013&amp;#x2F;02&amp;#x2F;15&amp;#x2F;star_wars_traceroute&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.theregister.com&amp;#x2F;2013&amp;#x2F;02&amp;#x2F;15&amp;#x2F;star_wars_traceroute&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>What happens when you update your DNS</title><url>https://jvns.ca/blog/how-updating-dns-works/</url></story><parent_chain><item><author>eat_veggies</author><text>One of my favorite revelations about the network tracing tools (things like `traceroute` and `dig +trace`) that might not be obvious for people like me who work higher up in the stack, is that the data they provide isn&amp;#x27;t usually made available during &amp;quot;normal&amp;quot; usage. Packets don&amp;#x27;t just phone home and tell you where they&amp;#x27;ve been. Something else is going on.&lt;p&gt;When you send a DNS query to a recursive server like your ISP&amp;#x27;s or something like 1.1.1.1, you make a single DNS query and get back a single response, because the recursive DNS server handles all the different queries that Julia outlines in the post. As the client, we have no idea what steps just happened in the background.&lt;p&gt;But when you run `dig +trace`, dig is actually &lt;i&gt;pretending to be a recursive name server&lt;/i&gt;, and making all those queries &lt;i&gt;itself&lt;/i&gt; instead of letting the real recursive name servers do their work. It&amp;#x27;s a fun hack but that means it&amp;#x27;s not always 100% accurate to what&amp;#x27;s going on in the real world [0]&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;serverfault.com&amp;#x2F;questions&amp;#x2F;482913&amp;#x2F;is-dig-trace-always-accurate&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;serverfault.com&amp;#x2F;questions&amp;#x2F;482913&amp;#x2F;is-dig-trace-always...&lt;/a&gt;</text></item></parent_chain><comment><author>LogicX</author><text>Just to add to the discussion -- &amp;#x27;whats happening in the background&amp;#x27; -- more specifically is your operating system&amp;#x27;s stub resolver.&lt;p&gt;So when you ask for www.amazon.com it ends up making multiple DNS lookups, as www.amazon.com is a CNAME record.&lt;p&gt;Nothing about this CNAME lookup gets passed back up the stack to your application; you just get that end-result: the IP address.&lt;p&gt;host www.amazon.com
www.amazon.com is an alias for tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com is an alias for www.amazon.com.edgekey.net.
www.amazon.com.edgekey.net is an alias for e15316.e22.akamaiedge.net.
e15316.e22.akamaiedge.net has address 23.204.68.114</text></comment>