12-15-2016 08:41 AM
Buit of a cheek for my first post, but I recently had to write an ionternal training document to explain basic DNS trouble shooting for our desktop support and help desk. Whilst I was creating that I discovered a distinct lack of end user guides to DNS trouble shooting, so I thought I'd publish a somewhat more generic version - but then hit the snag of not knowing many people who could actually review it and suggest improvements.
So if you've a need for such a thing or have a few moments to give such a document a quick glance the not subject to NDA, not in power point version is here:
Would really welcome any feed back to make it more useful, or even links to any better guides there are out there as my search skill smay have failed me when writing it.
Solved! Go to Solution.
12-15-2016 10:55 AM
My initial question is "Why is the audience?" It is unclear if this is designed for:
- end users diagnosing internet issues
- server admins diagnosing server issues
- network admins diagnosing packet forwarding issues
Secondly, 'nslookup' should NEVER NEVER be used for troubleshooting (esp on a windows server). nslookup works great, as long as DNS is not broken. If DNS is broken in anyway, nslookup tends to stop working well.
There is a collection of collective thoughts on this here:
And it's fairly easy to get a dig tool for a client system, e.g: http://www.eztk.com/products/ezdig.php
Your diagnostic process is still on the ability if you can or can't get an answer. It doesn't address looking at the forwarding or resolver path, if answers are authoritative or not, or if there is are other problems in the chain that could be the cause of the error (e.g a zone forwarding to a server that is unresponsive)
it also doesn't talk in much detail about the differences between namespaces you are in control of, and those you aren't. It walks around the problem but never really explains the the difference between resolving a query for 'myDC.mydivision.mycompany.org' and 'www.github.com'
12-16-2016 02:55 AM
The intended audience is end users, though when it comes to matters DNs related the line between service desk , some system admins and end users is a very very blurred one.
My aim was to provide a basic over view of simepl dns rtouble shootign to try and identify if the problem is actually likely to be a DNS issue rather than a web server not responding for instance. This based on the number of times peopel report getting the wrong page or a 4040 or 500 error as a DNS issue.
What would you recommend instead of nslookup that will be available on end users desktop machines, so in most cases the default desktop windows install? Other tools are available and most of them are better, but the user may not have the ability to install them and talking a user through downloading and installing a new tool is just going to increase the work load on the helpdesk. On a properly locked down server it may not even be possible. On the other hand nslookup is already there and available.
If DNS is broken then it's a DNS problem so the end user/helpdesk now know who to contact and likewise I wouldn't expect the end user or the helpdesk to be aware of what namespace the company might control and quite frankly I wouldn't expect the end user to care.
I mention those issues as complicating factors, my main aim of the article is to enable end users/helpedsk to do a simple triage to:
1) Establish that the issue is probably DNS related and not a server issue
2) Provide suiatble information to the next level of support/DNS admins to be able to know wher to start looking
e.g. what DNs server they're using what they're trying to look up etc.