why not A?

I'm no expert however, I believe the answer is (C). The question ask Which of the following commands should be issued from the workstation to verify the DDoS attack is no longer occuring? DDoS prevents traffic from reaching its intended location, hence denial, if the traffic/message reaches its location the DDoS attack is no longer occurring. Just my thoughts on this one.

It says "The administrator successfully pings the DNS server from the workstation" So he has to perform dig command on the workstation01 to get information about the DNS server. That makes the answer C correct.

Yes command is correct and by using this command it will show you if that hostname is associated with any servers and show other hosts IPs, and anything that is attached to that hostname. DDoS is used by perpetrator to create multiple open connections on multiple machines such as servers, hosts, and more.

LOL...not sure what monkey wrote this question, but when you issue a ipconfig command, you are implying windows...then you present the "dig" command which is primarily a linux networking tool similar to nslookup ( I know I know, there are ways to install dig on windows), but the question is idiotic.

C correct: When the supplied server argument is a hostname, dig resolves that name before querying that name server. If no server argument is provided, dig consults /etc/resolv.conf; if an address is found there, it queries the name server at that address.

What if the company in canada and its workstation01.ca :P or .org how they assume its .com the answer is A

Answer B, you do the query against the internal DNS server, if a DDOs in progress the DNS server will not respond since the service is being flooded with large numbers of packets to targeted network infrastructures and infrastructure management tools.

Dammit... the answer really is 'C'. I just tried in on my office domain. Not sure WHY it works with a .com extension (default alias perhaps???) -- but it does work. So the answer makes sense. First test connectivity with ping, then test internal DNS resolution, then move outwards with external DNS resolution, etc. (Ya learn something new everyday.)

The answer is correct I tried on my Linux vm . It will give you the same output as if you write the command without the end part".com". Try it yourself.

Maybe dig google.com is not the answer because it would most likely already be in the DNS cache?

Also the question did not mentioned any internet connection ,

Guys, please focus, C is correct , DNS server solve IP address into The match domain name , so If u can PING the resolved domain name which is Workstation01.com means the DNS server is working probarly . Also the hint in the question where it gave you the output og Ipconfig , Just think about it ,, Examiner try to trick u

with ipconfig he knows his host IP so he can resolve his host domain name to the IP. Bad part is .com is just assumed we can’t dig the IP because that answer is not available. To perform a reverse DNS lookup the command is dig -x 192.168..1.26. With that being said the google IP address might not be cached and it’s outside your LAN because if you notice the DNS and Gateway are the same. The DDoS attack against a DNS server would be a DNS flood where queries for entries do not exist fill up the cache and leads to resource exhaustion so that leaves just C as the most correct answer. Also if the Recursive DNS can’t find the IP address cached it goes to the authoritative DNS server. The workstation01.com should be cached First the recursive server would go to the root domain servers. Then, it goes to the authoritative server designated as .com. Hope this helps

The answer is correct. He pinged the DNS first and it works. Now, he sends a DNS query internally (C) and then he test it with an external query... IT makes sense

Assuming C isn’t some sort of typo, the only one that makes any sense would be A. That’s because when the ddos attack was carried out on the DNS server it was no longer able to respond or carry out any external recursive queries. By digging against google were proving that our dns server is able to make recursive queries against root, too level domains and google to get a result. None of the others can prove this. Obviously we could have a host file entry or cached results, but A is the best of a group of bad answers.

who says it is External DNS? it might be internal DNS and cannot dig google!?