This will force our local computer to check its %WinDir%\System32\Drivers\Etc\hosts file for static entries and then its local cache for an A record mapped to the youtube.com domain name.

We can take a look to see if there’s a mapping already with the following command:

type %windir%\system32\drivers\etc\hosts | findstr youtube.com

Alright nothing there.

So now we can check the local DNS cache

ipconfig /displaydns | findstr youtube.com

So we have no mappings right now.

Let’s ping youtube.com and then check the local DNS cache.

Basically what happened is the client said:

Yo, DNS server, I need you to give the IP address of youtube.com.

So our local DNS server, the Windows 2016 Server was like, “let me check my host file and my local cache… dang… I have no idea let me forward this request up the chain”

This is called a Forward Lookup request and the DNS server made a forward lookup request for the A record belonging to youtube.com. Since we configured 8.8.8.8 as the forwarder, 8.8.8.8 took care of it.

That Google DNS server, 8.8.8.8, looked up the name, replied to the Windows 2016 Server with the answer, the 2016 server cached the response and then forwarded the reply on to the client which can then cached the result as well.

So we need to view the DNS cache.

On our Windows 10 machine we can type:

ipconfig /displaydns

And on the server we can type:

show-dnsservercache

You can see the DNS cache record there.

And if you want to see what’s happening at the packet level just check this out:

I took this from the client. You can see the client (192.168.1.15) sending a DNS query to our Windows 2016 server (192.168.1.14) with the query of Type: A for youtube.com. This is in the middle pane.

So the Windows 2016 Server received the query, forwarded it along and then sent back the response it received from 8.8.8.8