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 |