traceroute - Determine actual DNS server consulted?
2014-04
Dallas
I know the authoritative DNS servers for records of a domain. What I haven`t determined is where queries internal to our network are consulted for records. I do know there are other servers used, serving different values internally, and would like to determine their IP addresses or servernames. Even just the first one consulted would be a good start.
Assuming I flush my local DNS cache resolver first (ipconfig /flushdns and possibly nbtstat -R), is there a way to determine which hop in a tracert is the DNS (DHCP?) server that serves dns records within the network zone?
As a side note: I'm not sure if this is the same thing as a "serving a zone file", but gather the latter is related to more than just DNS. Comments welcome to clarify this.
hroptatyr
Bind's dig tool will give you an answer:
$ dig
...
;; Query time: 9 msec
;; SERVER: fdcc:216f:1d2c::110#53(fdcc:216f:1d2c::110)
;; WHEN: Wed Jan 22 06:49:54 UTC 2014
;; MSG SIZE rcvd: 239
The SERVER line has the address of the server that actually replied.
Dallas
Turns out that there was a "DNS conditional forwarder" in place that would send anyone internally to a specific DNS server.
Iszi
When I ran into some intermittent Internet connectivity issues the other day at home, I decided to do something I rarely bother with - I plugged my laptop directly into the cable modem to see what was up. Once the connection came back up, I decided to do some diagnostics while I was still directly connected to be sure everything was properly functioning.
During this test:
- My laptop was plugged directly into the cable modem.
- As far as I know, this is a "dummy" modem - it's not an all-in-one cable modem/router/wifi device.
- I had no other devices on the network being tested.
- My laptop received an IP address and gateway via DHCP, both of which were publicly-routable "Class A" addresses.
If I ran a pathping or tracert to the gateway, everything came back normal - nothing appeared to be in between my laptop and the gateway.
However, when I ran the same utilities against other targets (Google, Yahoo, etc.) on the Internet, the first hop came back in the "Class A" range of RFC 1918 addresses. Also, the publicly-routable Default Gateway address did not show up at all in the traces.
Again, the only devices connected in my house at this point were my laptop and the cable modem. So, presumably the first hop to any address not in my DHCP-assigned subnet should always be whichever address shows up in ipconfig as the "Default Gateway".
Could someone explain how this can happen, and why there might be legitimate reason for it?
Thomas Pornin
tracert works by sending packets which have a short TTL ("time to live") and gather the obituaries which are sent back. Namely, when a packet is sent, is has a numerical TTL, which is decremented by each host through which the packet goes. If the TTL reaches zero, the packet dies. The host in which the packet dies normally sends back a control message (ICMP) to state "the packet died here"; that message contains the address that the said host considers to be his own true address. This is not necessarily the address which you so: a router, by construction, has several addresses.
For instance, if your gateway as public address 66.131.127.1 but also has, within the ISP network, the address 10.35.184.1, then the ICMP message may perfectly come back tagged with 10.35.184.1 (this address is not "public" but that's mostly a convention, of which the router needs not be aware).
Hendrik Brummermann
Sometimes providers use the private address space for internal routing. Germany's largest internet provider T-Online even put servers into that address space until the end of 2005.
While using private address space for internal routing does not have a negative impact on reachability, it is generally considered bad practice: It makes tracing down issues using traceroute harder and causes support calls.