DNS Issues
DNS can be a pain in the ass. One of the most necessary components of the internet, and yet, one of the most widely misunderstood.
I like to think of DNS as a phone book. Instead of looking up someones name and finding out the number to dial to talk to them, your computer looks up a domain name and finds the IP address of the computer housing the website in order to view it.
Pretty simple really.
However, just as you can remember your friends ph numbers, your browser can remember your favourite websites’ IP addresses. Your friends ph number is cached in your head, just like the IP address is cached in the memory of your computer.
Okay, with that out of the way - onward to the problems.
I was inundated with calls yesterday as a major telco’s DNS failed. How did it fail? I don’t know, all I know is that once I got to the bottom of why Joe Smith angry customer could not pop messages off our server it ended up that they were connected to the internet by this major telco and had:
Obtain DNS server address automatically
Checked in their TCP/IP properties. Once I instructed them how to change to using specified DNS servers (from a different ISP) the problems seemed to work themselves out.
*NOTE: you can override DNS servers using the local computers HOSTS file.
Why is DNS such a pain in the ass?
Well, because I am using different DNS servers quite often I am not experiencing the same problems as the customer. They might not be able to see this page or that page, or get their email - but I expressly know that the server is up and running in both cases.
This is in fact the perfect time to check their DNS, which I quite simply do by getting the customer to open up a command prompt and start pinging.
There are a couple of reasons why its a pain in the ass dealing with this issue.
A: We do not provide DNS services so essentially I am debugging someone else’s problem when I could be doing actual income generating work.
B: When you debug a problem like this for a customer they think it was something to do with you or your service. Something like ‘The website/email was down’ will go through their head, which is why you need to go through the whole ph book analogy and explain why it is not an error with your service (see point A).
C: (this is mostly my problem not the fault of DNS) For some Murphey’s Law type reason DNS is the last thing I check, when in fact, it should be one of the first - especially with really odd problems when you can verify that the respective servers are up and running.
Using DNS to your advantage:
Your computer’s HOSTS file is a reasonably powerful resource and allows you to effectively overwrite DNS entries. This can be useful if you want to block ads on websites or even Google adwords itself.
What to look out for:
I had a customer once who could see their site but none of the images were being displayed. Unbelievably this came down to DNS issues also.
They were viewing the site from a computer on their work network, which had been set up with in house DNS servers. There were two different paths used on the site (not my doing), so although the site resided at www.domain.co.nz, the images were using just domain.co.nz.
Although www.domain.co.nz would resolve correctly, domain.co.nz could not due to the in house DNS server - I don’t fully remember/understand why but the IT guy was adamant it could not be changed. ALthough changing the paths in this case was straight forward I can offer another solution which is to use custom HOSTS files - a bit of a hack, but hey.
DNS is a beautifully simple system which takes care of the enormous task of cataloging the address of every website and the corresponding IP. But little nuances in the system can really leave you flailing in the water if you don’t completely understand the underlying concepts.
Resolving these issues should not really come down to web developers such as myself and I guess therein my frustration lies, but for some reason…
Update:
Murpheys law strikes again. After ranting about the state of the DNS of this particular telco it transpires that their servers actually had it right and it was our own configuration that was to blame. Sigh. Someone I work with was instructed by support staff at our hosting company to change the records for: ns1.ourdomain.co.nz to CNAME records instead of A records.
This was because our records for mail: mail.ourdomain.co.nz were A records pointing at IP addresses for the mail servers of our hosting company. Essentially, our records for DNS domains were set up the same way. But when the hosting company changed the IP addresses of their mail servers WITHOUT NOTIFYING ANYBODY the system crashed. So pointing mail.ourdomain.co.nz -> mail.hostingco.co.nz in a CNAME record would guard against this happening again.
So she suggested we do the same with ns1.ourdomain.co.nz, which incidentially points to the same IP as ns1.hostingco.co.nz using an A record. We then changed it to point using a CNAME record and ns1.hostingco.co.nz as the target.
Seems like a good idea. However, it is not a good idea. All our clients use ns1.ourdomain.co.nz and ns2.ourdomain.co.nz as their dns servers, having these resolve as CNAME records breaks the whole system down. I still don’t know why, but it does/did.
So, if you are going to obfusicate your DNS servers, make sure you use A records and not CNAME records. If you are going to obfusicate your mail servers use CNAME records and not A records. Something new, every day huh. Thank god I was reasonably patient and polite when trying to solve this issue. Fact remains it has probably wasted about 4 days chargeable work for my boss.
Occasionally I’m glad I don’t run a business in this industry, because sometimes there is just no one to bill.
Related posts:
- Terminal Server Licensing.
- Setting up Outlook to use an LDAP server for contacts
- How to install a disk controller driver when Windows won’t boot following an upgrade of drive type.
- Setting up a wireless network with Windows Server 2003 and PEAP/EAP.
Leave a Reply