Getting my DNS under control to migrate servers
OK please forgive my noobness but I really haven't dealt much with DNS and domain name migration.
I am moving a site to a new server. Old server has ENSIM running on Fedora Core 1 (ew!). New machine is CentOS 5 with Apache 2.2.3, PHP 5.1.6, and MySQL 5.0.22. I copied the site files and databases from the old machine to the new and I have it running -- i can see it by visiting the ip of the new server. I mydomain.com which points to my old server (let's call it IP 1.1.1.1) to point to the new machine (call it ip 2.2.2.2) and this is where I'm a bit confused about how to proceed. My friend registered the domain and the name servers point to NS1.FASTDNS.NET and NS2.FASTDNS.NET. Through the magic of DNS (which I don't fully understand) mydomain.com resolves to its current ip of 1.1.1.1 at my hosting company (OLM). The new server is at this same hosting company and has a different ip (let's call it 2.2.2.2). I have issues with the current OLM setup. If I want to add web server subdomains like http://foobar.mydomain.com, then I add them in ENSIM but I think this only really affects the apache config on my machine and sadly I can't locate where these changes get made due to ENSIM file system virtualization madness. If I want a browser to actually find my new subdomain i have to ask OLM to alter my DNS records. I'd like to be able to control these records myself so I can add subdomains on my own without having to wait on hold for their people to answer. Ideally, I would also like to be able to throw the switch so to move mydomain.com from 1.1.1.1 to 2.2.2.2 on my own. I realize that letting them handle DNS might have advantages, however. I need to know more. I guess the bottom line is that I want more control over my DNS situation and I'm not sure exactly where DNS is getting resolved. My guess is that OLM has a DNS server that takes care of it. Can't I run DNS/BIND on my server itself. Are there pros/cons to this? At any rate, I tried a DNS record look up at nwtools.com and it looks something like this: Code:
DNS servers |
Login to your account at the registrar (or have your friend do it) and update the 2 name servers to point to your new server's IP(s). You can do the standard ns1.yourdomain.com and ns2.yourdomain.com if you want. It doesn't really matter. If you only have a single IP, both name servers can point to the same IP.
Install a DNS daemon on your server and set up your zones. Wait a few hours (or flush your DNS cache manually), and your requests will start to go to the new server. It may take up to 48 hours for the changes to propagate worldwide, though. You seem to be on the right track. DNS can be a tricky beast until you've had to do things like this a few times. :) |
Thanks for the advice. I think it's important to point out that I'm moving the site due to high traffic. I need to be sure the new machine is going to work before changing anything on my DNS at the registrar. The last thing I want is to have my site unavailable.
Can you recommend a DNS daemon? I believe I already installed BIND on the new server but don't know if that would serve as daemon. Also, I'm a bit concerned about taxing my server with the additional burden of handling DNS for its domain. And finally, my new server must contact a few other domains as part of its daily functioning for RSS feeds and monetary transactions. This is a delicate business! I'm also curious about who is currently handling the DNS record. I found where all the subdomain files are stored and I believe I found the apache config that adds them as virtual hosts or whatever, but I added a new one 'foo' and can't ping it from the internet. It seems odd to me that my ISP wouldn't just put up a wildcard DNS record for *.mydomain.com. Might there be some important reason for not doing so? |
Quote:
Question 1: If I point my registrar to ns1.mydomain.com, what happens when someone goes searching for mydomain.com only to be told it's found at ns1.mydomain.com? Seems like a circular situation to me. Do I need to register my name server with anyone? Will my site be invisible to the internet at large? Question 2: Which daemon? I hear BIND is really complex. TinyDNS has been recommended to me. What do you mean by 'set up your zones' ? |
You're missing a key part of the registration process. You obtain glue from your registrar by identifying a specific IP with a specific name for the authoritative name server. Some registrars ask only for the IP, some ask both. In any case, the lookup from any remote computer goes from the root DNS servers to the top level domain servers, and they answer with the IP or name you gave them. That is what prevents a cyclical problem from occurring. The top level domain servers (the guys who answer all .net or .com or .org queries) know your authoritative DNS server both by name and IP, and they reply with both.
To help understand, I'll give an example from my past. I own a domain, jimmcnamara.net. I registered it, and when I did, I used 2 DNS servers from work as the authoritative DNS for that domain. When we added a 3rd DNS server, I figured just by adding a 3rd NS record in my zone file, that I would then have 3 nameservers. It didn't work. The only people who can add or remove DNS servers for your site is whomever it is registered by. I had to go to my registrar, and tell them I was adding a 3rd nameserver, I identified it by name, and then it was added. The whole thing took about 5 minutes. BIND is not at all complex. Like apache or any other open source software, it can be incredibly complex, but it can also be super easy. At work I might be authoritative for hundreds of domains and need to reload them on the fly without interrupting any other domains registration, and give different DNS answers based on if the client asking is part of the LAN, DMZ, or WAN, and 100 other things. BIND can handle that easily, but it can also just give answers to one domain without problems. BIND is one of the oldest programs out, it has been developed continuously by people of tremendous talent, and just plain works. It was also my first open source program. I started using BIND 9.0 on a windows 2000 server back around 2002. I don't know tinyDNS at all. It may be nice, but I doubt it has the flexibility or tremendous support that BIND does. You can literally find 100,000+ examples of how to setup your named.conf and zone files through google. "Set up your zones" is DNS speak for "write the files that resolve your names to IP addresses." A zonefile generally describes a zone, and has several requirements, like a start of authority (SOA), and serial number, an MX record, and the linkage of the name to an IP. All of that can be found on any BIND tutorial. Peace, JimBass |
Thanks for trying to talk me through this. I think you're overestimating my skills a bit.
As I mentioned before, my friend who registered the domain listed NS1.FASTDNS.NET and NS2.FASTDNS.NET as the name servers for this domain. There is no specific IP address mentioned. As it turns out, these domains belong to OLM -- our hosting provider. This makes sense. We point registration via registrar to our hosting provider's DNS servers. Sadly I still have to rely on them every now and then -- to add subdomains, for instance. Right now, foobar@mydomain.com cannot be found. I'd like to be able to add any subdomain I choose at any old time. So I'm considering pointing the domain registration directly at my machine and running my own nameserver. According to this article, that might involve a few extra steps: Quote:
As for BIND vs. tinydns, I'm aware of BIND's reputation, I've just heard that the manual is some tough reading and I've seen tinydns in action and it seems to work pretty well for small scale operations like mine. I'll search for some BIND tutorials. I guess the question now is how do I test my DNS setup on the new server without actually pointing my domain at it? I'd hate to move my domain to my own DNS name server only to find out that it doesn't work right. |
Of course, doing your own DNS is as fast as you can type!
When you attempt to register your new DNS server, your registrar will ask both the name and the IP. That will move the name lookups from the hosting provider's DNS to yours. The 2nd paragraph in your quote is what will happen. You tell your registrar the name and address, and they register it to the top level domain servers. Of course, you should completely have whatever DNS you're going to use set up and fully functional before you make it live. Use the tool "dig" and point it at itself while it is still in testing mode. When it answers correctly for all your names/IP addresses, then it is ready to take over the DNS. Just like a webserver or mailserver, test the hell out of them before you put them live and into production. Peace, JimBass |
What version of Ensim are you running? Pro or Basic? Pro 4.x to v10.x has DNS built in, you don't need to add anything else.
With Pro (Any version)you can configure the server to run primary and secondary name servers. You will need 2 IP's from your ISP, you will use those IP's to register/create 2 name servers at your domain registrar, (Make sure that your ISP provides them with reverese pointers) then install them on your server, the secondary will be a Virtual Name server. Info on how to configure DNS in Ensim Pro ( All versions): http://www.ensim.com/support/pro/lin...ame_server.htm Good luck :) |
Quote:
I thought to myself, "How can these name servers exist when I'm not even using the domain and it's not pointing anywhere yet?!" You have to realize that your registrar is responsible for name server -> IP resolving, not you or your server. That's why you can have ns1.yourdomain.com and ns2.yourdomain.com even though yourdomain.com doesn't point anywhere! So, again, login to your registrar, change the entries on THEIR servers to make your name servers point to your server's IP. Then you can install and configure BIND or whatever you choose. :) When someone sends an HTTP request, it basically goes like this: User enters "yourdomain.com" into their browser. DNS query is sent out for yourdomain.com. The address(es) of your name server(s) is returned. The query is sent to the name servers. The name servers return the IP associated with the requested domain name. |
thanks, bpalmer for the fairly clear explanation. I'm aware that my registrar is critical in helping people locate my machine. Unfortunately, I have to know *all* the steps involved in the DNS chain in pretty much detail because I'm trying to migrate a live site that gets lots of traffic. It wouldn't do at all to change my domain registration to point to my domain if people suddenly couldn't find it. Apparently this could happen if I didn't perform the additional step of informing my registrar that my domain is a legit name server.
oneavenue: I loathe ENSIM. I know that it can be really useful if you have a dedicated server running a hundred sites but I'm just running one on this machine and ENSIM requires python and chews up memory and *totally* pollutes the file system with all kinds of virtualization. It's really hard to find out where things actually live due to all the symbolic links and redirection. I'm not going to use that or ISPconfig or anything like that. I like Jim's suggestion but am wondering if I can get away with asking my ISP to set up a wildcard DNS record where *all* subdomains at mydomain.com point to my one machine while at the same time mapping a couple of others (e.g., mail.mydomain.com or server2.mydomain.com) to a different machine. Is it possible to have a wildcard map all subdomains to one machine and then map a couple of other subdomains to a different machine? |
It is totally possible to do wildcard DNS entries. The order of them is very important though. First, you need to define any "real" subdomains, like www, mail and anything else that exists. Then after you have the "real" ones, you can put the wildcard *, with an A record pointing to one of your real world IP addresses. You'd also have to configure apache to answer all requests, regardless of what is asked for by the client.
Your current ISP may or may not be willing to do that. They should, but if they have somebody who isn't very knowledgeable about DNS, they may not realize that you can do this. Also, you're wrong about this point - Quote:
Peace, JimBass |
Cheers Jim. Thanks. You are the man. I'll see if I can get BIND working.
|
OK...turns out my BIND install is CHROOTED which makes things a bit difficult from a tutorial perspective. I searched the forums here for suggestions and seem to get a bunch of tutorials that tell me to edit a bunch of files that don't exist. This tutorial at howtoforge.com looks pretty promising but the one file on my computer named 'named.conf' is totally empty and it's located at var/named/chroot/etc/named.conf due to the chrooting. kind of makes things confusing.
Can anyone recommend a good tutorial on chrooted BIND configuration? |
I have located some bind config files:
Code:
lrwxrwxrwx 1 root named 52 Oct 22 01:41 /etc/named.caching-nameserver.conf -> /var/named/chroot//etc/named.caching-nameserver.conf Code:
options { Code:
[root@server2 /]# ps -aux | grep 'named' Code:
[root@server2 /]# dig redhat.com I could really use some help here. I was supposed to have this running last monday. |
You don't automatically query yourself just because you've installed BIND. The file /etc/resolv.conf contains the IP addresses of the nameservers that you will ask for named resolution. It can (but doesn't have to) be yourself, but other than special odd circumstances, I can't imagine why you wouldn't make your nameserver the primary namerserver for itself. Just change the IP in /etc/resolv.conf to 127.0.0.1.
You'd have no way of knowing when your ISP changed server IP addresses, but odds are good they won't, especially with a great address like 99.99.99.99. They have full records setup for that as well - Code:
jim@jimsworktop:~$ dig -x 99.99.99.99 I would define your zone in /etc/named.rfc1912.zones, and you'll probably have to place the zone within the chroot as well. Hopefully the /etc/named.rfc1912.zones file will have some clue as to where in the chroot the zone should go. You'll also want to change some configs. You can't only answer queries from yourself (localhost), you'll have to answer all queries for your domain name. I suggest you check if there is another BIND package that your distro provides, one for authoritative domains. You can work with what you have now, but you have to rewrite half of it to get it to answer queries correctly. See if CentOS has another version of BIND, and if so remove this one and install the other. Peace, JimBass |
All times are GMT -5. The time now is 08:28 PM. |