Cisco – “dig +trace fqdn” and “dig fqdn” do not give the same result on a LAN with windows DNS server, why

ciscodigdomain-name-systemlocal-area-networkwindows-server-2008

in my company LAN I have a Ubuntu 14.04 server running in Virtualbox (as guest) on a Windows 7 (the host) with network interface bridged (so the Ubuntu server belongs to the LAN, with its ip: 192.168.1.85). I have a website on this server: mywebsite.com

The gateway for the LAN to the internet is 192.168.1.1 (Cisco 1841)–>188.188.188.254 as public IP.

There is a Windows 2008 server that acts as DNS server and DHCP server on the LAN. I added a Forward zone "mywebsite.com" with A record -> 192.168.1.85.

Outside the LAN, mywebsite.com has public Dns records that point on the Cisco 1841 public IP (188.188.188.254)

Now when I ping mywebsite.com from the lan, I quickly get 192.168.1.85.

But when I'm connecting through the browser on the clients, it's not always fast. So I'm wondering:

Are my requests really/directly resolved and forwarded to
192.168.1.85, OR are they sent out of the LAN, and then forwarded back to the CISCO public 188.188.188.254:80 and NAT to the Ubuntu server before being served ???

To try to answer this question, I looked for tracking the DNS request from my linux client on the LAN:

v@v-ss9:~$ dig mywebsite.com
; <<>> DiG 9.9.5-3-Ubuntu <<>> mywebsite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24850
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mywebsite.com.     IN  A

;; ANSWER SECTION:
mywebsite.com.  3600    IN  A   192.168.1.85

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Aug 22 09:50:16 CST 2014
;; MSG SIZE  rcvd: 66

This answer looks right: 192.168.1.85. But then look at this:

v@v-ss9:~$ dig +trace mywebsite.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace mywebsite.com
;; global options: +cmd
.           12955   IN  NS  h.gtld-servers.net.
.           12955   IN  NS  g.gtld-servers.net.
.           12955   IN  NS  m.gtld-servers.net.
.           12955   IN  NS  i.gtld-servers.net.
.           12955   IN  NS  l.gtld-servers.net.
.           12955   IN  NS  k.gtld-servers.net.
.           12955   IN  NS  j.gtld-servers.net.
.           12955   IN  NS  d.gtld-servers.net.
.           12955   IN  NS  b.gtld-servers.net.
.           12955   IN  NS  c.gtld-servers.net.
.           12955   IN  NS  a.gtld-servers.net.
.           12955   IN  NS  e.gtld-servers.net.
.           12955   IN  NS  f.gtld-servers.net.
;; Received 516 bytes from 127.0.1.1#53(127.0.1.1) in 18 ms

mywebsite.com.  172800  IN  NS  ns3.rmi.fr.
mywebsite.com.  172800  IN  NS  ns4.rmi.fr.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20140825045016 20140818034016 6122 com. Imq8K9xlvFXlB4IjUkdxOc5YHoTEhqSQUlRSJ9QCIhd9wzGpWJ54AfVf WJ0SUKThalpzqS0cXdLGtNmuYgqLfwUMjpUlT4c+zJyx7I4QMPLImQZh Ov0xy3mUr7dLlymAJYGs9dLI2IaheLvpKTBwaV1gAvo8QEkU8VRiJ7gW 9dk=
U0PIA23FHMVPTKSDHC9PJ1BEA9SIB65R.com. 86400 IN NSEC3 1 1 0 - U0PL33R61V6TCCPBS1171PROP57ASRD9 NS DS RRSIG
U0PIA23FHMVPTKSDHC9PJ1BEA9SIB65R.com. 86400 IN RRSIG NSEC3 8 2 86400 20140825043502 20140818032502 6122 com. qsC5sJbwklao+OedCHpcYo56aQaY0N+7peKmPu8szvjAQoJFRWyuDfAh Nw/gvHXEMzG7tYLriQGVfsiK8GZdPXyG4Ghe1MNN4jOZnSahkT5LjlqL 5QyGC0QiClRMPDAYjUOFGQDkjOJcJYvTNkEyXC2BEpfLI5SwCbYqwqg3 RkE=
;; Received 585 bytes from 192.41.162.30#53(l.gtld-servers.net) in 297 ms

mywebsite.com. 86400 IN A   188.188.188.254
mywebsite.com.  86400   IN  NS  ns3.rmi.fr.
mywebsite.com.  86400   IN  NS  ns4.rmi.fr.
;; Received 204 bytes from 212.51.161.18#53(ns3.rmi.fr) in 310 ms

Here I get my CISCO public IP 188.188.188.254!!!

  1. Is it normal?
  2. How to know if my browser (from the LAN) is really directly communicating with 192.168.1.85 when using mywebsite.com?

Thank you for your help.

Best Answer

Is this normal? YES!

dig +trace recursively resolves the domain. it starts by querying the root servers, and so on. The same way any resolver would by default,

Since the site is hosted within your LAN, you are able to skip the recursion and serve up the zone directly from your LAN's DNS server - which you are doing. Furthermore, you are able to specify a local IP address (which would not work on the public internet) - which you are doing. When you query the domain with just dig your LAN's DNS server is queried directly - hence the local IP address in the reply.

On the other hand, dig +trace ignores your default resolver. dig acts as its own resolver instead, and emulates what a resolver out there on the internet would do. Since the local IP address would not be reachable from the outside world, you need the public IP to be returned as the answer. And this is exactly what you are seeing...

Is your browser on the LAN reaching the website using the local IP? PROBABLY! dig returns the local IP. This indicates that your DNS server is in fact returning the local IP to LAN clients, and that your machine is actually configured to use the LAN DNS server. So, barring something weird happening, yes.

How can you be sure? The server's logs are your friend.

If the source IP in the web server's logs matches your router's external public IP, then no the local IP is NOT being used.

On the other hand, if the source IP matches your browser's local IP address, yes, the local IP IS being used.

How can you be really really sure?

Wireshark. Take a packet capture while you browse. See what traffic is going where.

Related Topic