Skip to main content

Timeline for Serverfault.com DNS issue

Current License: CC BY-SA 3.0

19 events
when toggle format what by license comment
Mar 20, 2013 at 11:28 vote accept vitalie
Mar 19, 2013 at 14:57 answer added Kyle Brandt timeline score: 2
Feb 27, 2013 at 8:00 comment added Andrew B After trying a few times to explain in 600 characters or less why vitalie is right about the behavior of +trace, I eventually gave up and did a self Q&A that covers the topic in-depth.
Feb 13, 2013 at 7:40 answer added Alex timeline score: 2
Feb 12, 2013 at 8:08 comment added vitalie Start a tcpdump before launching dig command to see what I mean (Ex: tcpdump -i eth0 -n src 8.8.8.8 \or dst 8.8.8.8).
Feb 12, 2013 at 8:05 comment added vitalie I'm trying to tell you that dig +trace is acting as recursive name server just partially. It will follow referrals (authority section) from root servers but it will resolve name servers names through your DNS caching server.
Feb 11, 2013 at 20:56 comment added Alex @vitalie again...that's wrong. Your DNS server in resolv.conf will give you the IPs of all the root servers. Those will give you the GTLD servers responsible for that domain and finally you will get the results from the SOA. By removing the name servers from /etc/resolv.conf you are just briking the first step. That's all. Just look at the results from dig Received 169 bytes from 198.252.206.80#53(ns1.serverfault.com) in 22 ms or Received 135 bytes from 192.31.80.30#53(d.gtld-servers.net) in 36 ms
Feb 11, 2013 at 20:25 comment added vitalie It will start from root name servers but it will resolve names using local resolver. Make a simple test, start a tcpdump while running query or just remove temporarily your name servers from /etc/resolv.conf.
Feb 11, 2013 at 17:44 comment added Alex @vitalie, actually no. The +trace will trace the delegation path starting from the root name servers in order to resolve. So starting from the root servers, then the gtld servers, then serverfault's name servers.
Feb 9, 2013 at 10:46 comment added vitalie dig +trace is using your local DNS resolver to resolve names.
Feb 8, 2013 at 20:23 comment added Alex I'm not sure it would cause any delays in resolving. If you do a dig +trace ns4.serverfault.com, you get the proper IP.
Feb 8, 2013 at 9:36 comment added vitalie Indeed, DNS is very complex and many have problems understanding it, this is why I developed this tool. I wanted to share with everyone what I've learned about DNS and to help people find their DNS problems. Thank you for your observation!
Feb 8, 2013 at 2:05 comment added John Gardeniers Understanding DNS goes way beyond anything that we could cover in comments but there are some really great articles and books on the subject. The concept of glue records in particular is something a great many people seem to have trouble with. In this instance the important part is what syneticon-dj said, the authorative name servers for the domain do not provide glue. Glue records exist so that we can find those authorative name servers. The distinction is really important.
Feb 7, 2013 at 11:47 comment added vitalie @JohnGardeniers I don't mind to learn new things, if you have comments or suggestions they are welcomed. :)
Feb 7, 2013 at 11:42 comment added vitalie @syneticon-dj I've updated the message. Thank you!
Feb 7, 2013 at 10:06 comment added John Gardeniers If you're developing a DNS checking tool you should first ensure you have a proper understanding of the topic.
Feb 7, 2013 at 8:29 review Close votes
Feb 13, 2013 at 3:01
Feb 6, 2013 at 21:25 comment added the-wabbit I think the wording has to be "the glue provided by the parent name servers has to match the data provided by the authoritative name servers" as the latter would not provide "glue".
Feb 6, 2013 at 21:11 history asked vitalie CC BY-SA 3.0