Posts tagged DNS

Infrastructure and Other Games, Part 4

Part 4: The Other Stuff

Thanks for reading my series on moving from my single all-in-one server and my small ESXi server to ipHouse’s vmForge VDC product. I previously discussed moving my websites to a virtual webcluster, and moving email to a virtual mailcluster. Now I just had to move three small servers, and install a third.

The first server I moved was a small experimental VM used for testing various network, web and other items. I like to have dedicated testing environment for every operating system that I professionally run. This server was responsible for my personal Teredo tunneling, and was the one I put my CGI testing on from awhile a go. I could have easily moved it, but I wanted see how the export/import from ESXi to vmForge worked. I stopped the machine on my ESXi server, downloaded it as a OVF and uploaded it, via my Windows machine, to my catalog. It imported it as a template. I then deployed the template and deleted the server. It worked flawlessly! All I had to do renumber the machine and I was done. More >

Infrastructure and Other Games, Part 2

Part 2: The Webcluster

Last week I discussed moving my personal infrastructure into an vmForge Virtual Data Center. I discussed setting up a pfSense firewall, and getting things ready for my various projects. The first one that I wanted to tackle was setting up a load balanced webcluster.

More >

Infrastructure and Other Games, Part 1

Part 1: VDC, Layout and Firewall.

I had a problem. All of my personal infrastructure was on an aging server, cobbled together from various parts that were laying around. I had already replaced the motherboard once, and I was not looking forward to doing more maintenance. The system had 5 320gb SATA disks in a RAID 5 setup. Not very fast, and it could only survive one disk failure.

Software-wise the machine had long exceeded what it was designed to do. It was originally designed as a game server, with some web and email. I had added several other services to it as I learned and played. Data was spilling out of its assigned slices. Symlinks were used strategically but it was still a mess. More >

IPv6 Worldmark

ipHouse and World IPv6 day!

World IPv6 day is June 8th, 2011 and ipHouse is ready!

What is IPv6 you ask? Well, that topic won’t be discussed in this posting as it has been discussed all over the Internet already. You can test your readiness by going to http://test-ipv6.com/ and checking your results.

This post is about what services are running IPv6 dual-stack on the ipHouse network today.

Many of our services have been operating in a dual-stack IPv4/IPv6 configuration since the middle of last year but since most connectivity is still only IPv4, most people would never see nor notice the IPv6 network capabilities we have already built into our network. Our network itself has been IPv4/IPv6 dual stack for what seems like forever with quite a few customers connected with native IPv6 connectivity via DSL, T1, metro-ethernet, and colocation.

More >

So who hosts what in the where now?

One of the most common points of confusion for our customers domain registration and DNS hosting. DNS isn’t exactly the easiest thing to understand, nor is domain registration, so it’s natural that a lot of people would find the whole thing baffling.

The first thing to understand is the Registrar. A registrar is a company that is accredited, and allowed to work with ICANN ( The Internet Corporation for Names and Numbers). ICANN actually maintains domain names and their information. You pay a registrar for your domain registration, and they, in turn, pay ICANN and provide them with the domain’s information. There are other parties and services involved, but in the interest of keeping it simple, that’s how it works.

Once the registrar has the domain name registered and reserved, actual Domain Name Servers need to be assigned to it. DNS is the service that turns the domain name, say, example.com, into its associated IP address. Humans can remember words far better than numbers. And computers deal with numbers.  This is why we have DNS.

It also tells servers where to send email and what IP addresses various services may use. Each service normally has an A (or address) record. For example, an ftp server, ftp.example.com, may be on one IP address while the website, let’s say www.example.com, may be on another. Mail routing is controlled through the MX (mail exchange) record, which must point to a host name, like mail.example.com instead of an IP address. Canonical Name records and TXT record are used for more specialized purposes.

Usually, a registrar defaults to using their in-house nameservers. You can use these servers, putting in the information from your hosting company, usually by using a web based interface. However, we feel it is a better idea to switch the nameserver to your hosting company’s. That way, if your hosting company makes a change then they can update your DNS automatically alleviating your need to worry about these technical details.

DNS can be tricky and it is absolutely critical that your information is correct. One small mistake can cause you to not receive email, or not be able to view your own website. Many outages are associated with DNS problems and can easily be avoided by making sure the right information is in the right place.

Now, there are PTR (or rDNS) records that often are confusing. Most DNS queries are like looking up a name in a phone book directory, but you look up a server name to get the IP address (instead of a phone number). There are a few instances where you want to check the IP address and see who it belongs to, kind of like a reverse directory search of a phone number to see who’s calling. This is called a reverse DNS check.

This most often come into play when mail servers want to check the legitimacy of the SMTP servers that are sending them messages. If they query the IP address and get mail.example.com (or some other, similar Fully Qualified Domain Name) they let it pass. If they get something like 192-168-123-45-adsl-dynamic-customer.isp.net, they may reject or quarantine messages. These records are maintained by the ISP who provides the IP address, so if you run a server out of colocation space or off your Internet connection, you’ll want to contact the ISP to update that information.

Well, this was a very basic summary, hopefully it helps!