Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
When we start talking about troubleshooting DNS with tools, we're going to start here on the client system. We'll move over to the server and then we'll come back here to the client. We're going to move around a bit. So you'll see Apple Remote Desktop in the middle here. Once you've analyzed your DNS file on your server, you really should move on to checking hardware and network settings if things still aren't working correctly, both on the server and the client. Then to testing or altering aspects of DNS with several helpful tools. The first step in all of this after you've gone through all these steps looking at files that we did in the previous movie, is you should look at your hardware and your networking.
Now this is the "is it plugged in"? question really. You're going to look at your System Preferences here. We're going to go to networking. If your DNS Server isn't entered correctly here on the client, it's not going to work. Same thing is true on the server by the way. If it's not the correct number, then DNS resolution won't function because it's all based on what's in this little space right here. If we quit those and we go back over to say, for example, the Network Utility. We can know the Go menu and come to Utilities menu here. We open up Network Utility right there and come to Lookup and Ping.
These are two fantastic tools that we can use in order to see if our DNS is working properly. If we can't get name resolution, say we went into Lookup and we've tried to look for groundswellgear.com and it didn't work. We can set that up for ourselves right now. We can set up a failure situation right here just for you. Click on Network, come in here, and we'll just put 23 there in the DNS server address. Now what you will see is when we try to look up groundswellgear.com, it'll just spin and spin and spin and spin. And it's not going to find anything. There just won't be a response because we're not looking at a DNS server that has an answer.
But if we come over here and we ping the IP address of the server, we know that the IP address is that 192.168.12.2. If we ping it based on its number, we are getting a response. That tells us something. If the number works but the name doesn't, it means we're not looking to a DNS server that can resolve that name. The first place you want to come back and look if that's the case is right here, because simply by changing this back to the correct numbers so that we are looking for DNS resolution on our server, we can still do our ping based on the number.
But now if we type in the full name of the server, we ping again, we can get full resolution off of that as well. If we come over here and do a lookup on groundswellgear.com right away, we start getting responses. If we type in server.groundswellgear.com, we get our A record response just like we should. By checking your settings here in the Network System Preferences pane and by testing here using Lookup and Ping in the Network Utility application, you can get a better idea of what is and what is not working.
Now let's say all of this failed. I'm going to quit Network Utility here and I'm going to quit the System Preferences there. We're going to switch over here to Apple Remote Desktop. We're going to control the server itself. We did our lookup on the client in Network Utility and we found the A record, and we saw that we could ping the server and that was all working, but what if we tried that on the client and it didn't work? Well, the next step would be to come over here to the server to make sure that we can do it actually locally to make sure that the services are functioning the way that they should.
One sure-fire way to do that is to come in here into the Terminal on the server itself and type the following. If we use the dig command and we follow that with the name of the server, what we should get back is an answer from the DNS server that the server is looking at. If we want to look at the PTR record, I'll clear this so we get a fresh screen. We would use the same command dig with a -x flag and instead of using the name, we just use the IP address that we've just found.
That tells us right here with our Answer Section that we have a valid PTR. We can see the numbers in reverse, and they've resolved out to the correct name. So we've got that. That's all checked out. Another really good tool that you can use here is host. If you type host and the IP address, you'll see here that it's giving you the reverse with a domain name pointer to server.groundswellgear.com. Thanks to the copy and paste functionality and Terminal here in OS X, you can type host and then paste the name of the server in, and it'll give us the A record return.
So, there's dig and host. Those are two fantastic tools you can use at the command line to do pretty much what you saw us do on the client side there with the Network Utility. Of course, we also have Network Utility here on our server. But if we didn't have access to the GUI for some reason, if we had to SSH into the server or the client for that matter, we can run these tools and get the results that we need to troubleshoot DNS. Now sometimes the DNS server on Mac OS X Server might not be running at all, even the Server Admin might say it is. So, there are two ways to check if it's really running.
One, of course, is to open Activity Monitor. So I've just gone to the Utilities folder and I'm opening Activity Monitor. If I look at All Processes and look for named, I can see right here that named is running and it has a process ID of 44 and it's functioning. So that's great. So we know that that's running. But say we don't have access to Activity Monitor. What if we needed to do that in the Terminal, because we could only SSH into the system, for example? Well, to do that, first we're going to type sudo -s so that we are root. Now we're going to type ps ax | grep named.
What that will return is the same thing that we saw over there in Activity Monitor. The only difference is that here it's just expressed slightly differently, but here you can even see we've got our process IDof 44 and we know that it is functioning. So that's good. That means that DNS is actually running. If we didn't find that then even if we had a little green dot next to the DNS service in Server Admin, if it wasn't showing up as a running process, it wouldn't in fact be running. As we talked about in the files troubleshooting portion of this chapter, you would look at the log files to see why.
If your Lookups are not working from a client, it can be useful to check to see if you can perform a lookup locally from the server. You can be absolutely sure which DNS server you're querying by typing its IP address or its local loopback address after the dig command. That would look something like this. You would type dig, then a space, then an at symbol, and then you'd either type the local loopback address, which is always going to be 127.0.0.1. That's on any computer. That basically is the address that says, hey, look at my local ethernet connection there.
Look back at myself essentially. Then you would put in a space and the name of your server. Ours is server.groundswellgear.com. So what we're saying here is you're telling the dig application to query the DNS server at that address which is the local loopback address for this information. We hit Return, and it gives us our answer. There's our Answer Section right here. So it has responded correctly to that query. If our queries were not working anywhere else, but they did work here, you would know that your DNS service was in fact working, but then perhaps there was something in-between your client system and the server that was interrupting the requests from completing, maybe a network service error or maybe cable was unplugged in some room somewhere.
But this gives you an idea of where your troubleshooting should take you. This tells you, yes, DNS is working, and it can resolve my query. Since we're here on the server, if you find you DNS server doesn't respond to requests properly, it may be that the DNS root cache needs to be updated. Sometimes these numbers and names of the DNS root servers do change. It's very infrequent however. Still, it's good to know that there is a command you can type that will go out and look at the root servers and get a new list of names and addresses.
That command is once again dig, but with a different option. dig space dot, it's just the period, another space, ns, space, the greater than symbol, that's just Shift and the period on your keyboard, space slash var, slash named, slash named.ca. Hit Return. It won't give you any response. It won't tell you that things are going well. It won't tell you that things are going badly. But in the background what's happening is it's now updating the contents of the file named.ca which is location there in var/named.
And it is making sure that names and IP addresses of all the root servers are correct. And that's really important. Now if you suspect that your server or client system is responding to your DNS queries with stale information, you can force the refresh of that DNS cache by just restarting the service that handles all DNS queries now in OS 10.6. This is on the server or the client. So really you could do this on either place. You restart the mDNSResponder process, responsible for all DNS in X.6 by typing the following into the Terminal on whatever system you believe to have bad data.
If you haven't already typed sudo, you would type sudo. We have. So assume that. Killall -HUP mDNSResponder. Case sensitivity is important here. Hit Return. Again, no response, but in the background DNS has just restarted.
In the process of restarting, it's going to clean out that cache and start with a fresh one. So all this is done, and it still doesn't work. Well, maybe your problem isn't DNS at all. Maybe your problem is in routing from the Internet to your server. If your server like ours here is on a private network behind a net gateway, make sure that you've forwarded the ports necessary for your services to work properly. If you're looking for the ports you need to forward, you can either look at the well-known TCP and UDP ports knowledge base article at apple.com, or you can just open up ServerAadmin and look at the firewall interface.
Get unlimited access to all courses for just $25/month.Become a member
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.