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:

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?

Sadly, this description is a lot trickier for me than you might think.

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:
The first part makes sense. If I list ns1.mydomain.com as the name server for mydomain.com, I should probably tell the domain registrar about it. That last part about static ip and domain confuses me.

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 :)

The confusing part for me when I started with DNS was figuring out HOW the name servers were resolving at all!

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 - The registrar will simply map whatever IP you tell them to be the authoritative DNS for your domain. To do that, simply install BIND and get it running before you make your switch. It's not like you're confined by time. DNS works currently for you, and will work if you run it your self too. Just configure it first, and get it to answer correctly for you. Once that is done, use your registrar to change. You're making a mountain out of a molehill. When it works, you change, but until then, leave things as they are.

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:
the file named.caching-nameserver.conf is apparently the main .conf file for named. The other file, named.rfc1912.zones, is referred to by that file. here is named.caching-nameserver.conf:
named is definitely running:
And yet dig reports that my machine is looking elsewhere for DNS:
the 99.99.99.99 in there is my ISP's name server which could change. I'm concerned about what happens when my ISP might try to change the name server ips (like under DHCP). Will my caching nameserver break? Will it know to look for the new IP address?

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 - This server won't talk to 99.99.99.99, unless you configure it to in named.conf, or whatever craptacular name your distro gave the named.conf file. Your server will go down to the root, followed by the top level domain servers, then go out across the net to resolve names. The only time you'd speak to 99.99.99.99 would be if that address is authoritative for a domain name you are trying to look up.

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

This is a nightmare. I had BIND resolving locally after I edited /etc/resolv.conf but I couldn't figure out how to get it to respond to a 'dig' request from a remote IP. My suspicion was that this had something to do with me trying to install a cached nameserver. Sorry if I was unclear - I replaced my ISP's actual nameserver IP with 99.99.99.99 for the sake of privacy. I spoke with them today and apparently my upstream DNS servers are likely to change fairly frequently. As I understand it you can put a 'search ' directive in resolv.conf.

I would like to accomplish two things
1) Present a cached DNS server to all local services like SpamAssassin or DCC or Postfix or whatever.
2) Present authoritative DNS to any request originating outside my machine.

Is that possible? Any idea which bind I should install? CentOS 5 offers these options:

The problem was that you installed a caching server, when that is not what you want. A cacher only answers questions about other domains, not your own. Also, stop thinking about your ISP nameservers, you won't ask them, and they have nothing to do with you answering queries. Putting them in resolv.conf has no effect on BIND, BIND will go straight to the roots then back up to you, and your ISP DNS has no place in that chain.

Here is a config directly from my nameserver, which does exactly what you want, answer all queries from your LAN, and answer any query from anywhere for your authoritative domain -

So you define all the address groups that should have recursive queries answered by your machine (your whole house, your whole town, whatever works for you), and put them in the acl. The allow-query any line allows any machine in the world to ask about yourzone.com, which obviously should be changed to the correct name of your domain. The file will get defined in /var/cache/bind/yourzone.com. This config also allows a log of queries and bind.log files, so you can see what queries your server is answering, and if you screw up a zonefile, check the bind.log file. You'll have to create the /var/log/named directory, and make sure the user bind has permissions to write in this directory.

I would simply install the bind.i386 package, and dump my named.conf into their named.conf, making changes if you need to.

Peace,
JimBass

I would like my DNS server to cache results because I have SpamAssassin running locally to screen mail and it makes a BOATLOAD of queries to external servers which can be really slow. A caching nameserver is supposed to improve performance pretty dramatically.

I *really* appreciate that .conf file you sent. I've copied it and changed it a bit for my machine. And it seems to work...HOWEVER it seems to immediately come under attack or something...either that or I have something configured wrong. Here's the output log when i do 'service named start' :
As you can see it complains about me having no TTL in the mydomain zone but otherwise loads fine. But then some machine (IP of 67.91.71.171) IMMEDIATELY attempts to send me a notify. What's up with THAT?? Is that a machine on the botnet or something?

I was hoping you might clear a few things up pretty please?

0) I set both logs to the same log (/var/log/named.log) because I'm concerned about my logs getting huge without being rotated. Do you have any advice about making sure these logs don't get out of control and are periodically rotated or deleted? Also, Is it a problem that I specify different version numbers and maximum sizes for the same log? Also, do you *really* want to log queries? Seems to me there are going to be MILLIONS of them.

1) What is the difference between allow-recursion and allow-query-cache? The docs are pretty vague on what it really means.

2) what the heck does that 'key rndc' section do? I understand that rndc is a control interface for BIND but am not clear if I would call this from the localhost, a remote host, etc. I'm also confused about where the rndc config might live and whether it needs to be updated to match this .conf file.
UPDATEI was having trouble stopping named until I made certain that the key value matched the contents of rndc.key.

3) controls...is that related to rndc key? What is it? The docs say something about this only being needed for backward compatibility to BIND 8.

4) Can you suggest any tests I should run before trying to use this as an authoritative DNS server? I installed dig by running this:
Anyways...thanks for your help so far! I really don't enjoy this at all and I'm really concerned about setting up something that's going to hurt my server's performance or expose me to a hack or something.

Your alleged "attack" is not an attack of any sort. It isn't sending any info towards you, you are asking about it. Maybe somebody at that address is trying to send you a message. I bet it is more likely that is your own address, or somebody that is spamming you. Also, any DNS server will cache info for as long as it is valid for, which is determined by the authoritative DNS.

Correct your TTL error, put one in the header of the zonefile. Check google for the 100,000 examples of zonefiles, and see that all of them have a TTL. There is nothing in what you posted about that address trying to send you a notify. All the notify statements I see is your machine complaining about your malformed zone, or you sending out notifies.

0) So you're concerned about logs getting to big, but did you bother at all to read and think about what I wrote for more than 2 seconds? What do you think this means:
Do you think there is an outside chance that it will keep 3 bind.log files, each one a max of 5Mb in size? Or that just maybe the queries log keeps 5 copies, each a max of 10 Mb? There will not be millions of queries. Even in an office with 50 people you'll take days to fill a 10 Mb query log.

1) The docs are explicit about what those mean, which suggests to me you either didn't read them, or didn't bother to understand them. First off, your garbage OS doesn't even have a new enough version of BIND to allow you to use allow-query-cache. That came into play in 9.4.0. Allow-query-cache allows anyone to ask your server for the info it already has in its cache, which all versions of BIND used to allow, regardless of who was asking. Now the ability to query the cache can be manipulated. Recursion is the ability to ask your DNS about zones it is not authoritative for.

2) rndc is a great tool, it should be a must have for BIND. Once you graduate to larger machines, you don't want to bring down BIND to restart 1000 zones because you made one change to one of them. Rndc allows BIND to keep running, while reloading just that individual zone. All versions use rndc to start or stop a BIND process, so the key must match the file, or you can't start or stop your BIND without a manual kill. Rndc can be called from localhost, or a remote host, depending on how you have set it up. Keeping it restricted to localhost is a good idea, but you don't have to do that.

3) There used to be an explicit control statement in named.conf, which has been done away with for years now. It still exists for backwards compatibility, but you won't need it, and shouldn't use it, as that functionality could be removed at any time.

4) Dig is all you need. The command is Then before you make it live, use dig from some other machine, to make sure you have done it right. And ask for everything, mail records, and any subdomains, to make sure everything is set.

Do some research next time. If you need this amount of hand holding to even get started, you will have issues once you go live.

Peace,
JimBass

3)

Someone steal your guitar Jim? You sound cranky in your post.

This line looks to me like i have *received* a notify for my own domain. I don't see any reason why I would receive a notify for my own domain from an IP in virginia that I don't recognize. Assume 11.11.11.11 is my server's IP:
If I turn query log to level=debug then I get lots of this:
I googled isc.org for 'createfetch' and no records were returned. Ditto for 'delete from rbt'. I googled internet-wide for these strings and just got weird log report type stuff.

As for the missing TTL in my zone file, I copied my zone file from this tutorial and it's also missing there. I just noticed the description in the docs today. I hope you'll forgive me, it's only a 650KB FILE. Hopefully I won't have to read those 100,000 valid zone files on google to answer the rest of my questions.

I appreciate your responses (except for the barbs)

0. I read your file thoroughly and also read the isc docs on this directive. If *you* had read my post more closely you'd see that I used the same log file twice with different directives and I was wondering if that would break anything? I left your original log sizes and was wondering if that would cause a problem? I ask because the original install had both a LogWatch and a logrotate script which pointed to /var/log/named.log and ALSO I have chosen to install a chrooted bind which looks elsewhere for the file. It's a bit of a mess and I worry they won't work together. Please don't get pissed, I'm just trying to understand this.

1. Maybe I'm an idiot but I don't really understand what this means:
allow-query-cache - Specifies which hosts are allowed to get answers from the cache. If allow-query-cache is not set then allow-recursion is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used.
allow-recursion - Specifies which hosts are allowed to make recursive queries through this server. If allow-recursion is not set then allow-query-cache is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used.
The if/then conditionals are a bit of a mind bender for someone new to this. Thanks for the clarification. That's disappointing about the directive not being available in Bind 9.3. There are no links to Bind 9.3 documentation on the ISC site. I don't see any need to bash my 'garbage' OS. It's CentOS 5 (based on RHEL 5), released only 6 mos ago, and the best my hosting provider has to offer. I'm not personally attached to it. Also, you're using Debian - the current stable package for Etch is Bind 9.3.4 so there! :P For what it's worth, the ISC site offers links to more recent RPM's but I'm not sure how to take advantage of them just yet (or whether it's worth it).

Do some research? Are you serious? I've been reading about BIND for two days now and the 650KB of documentation is written like a math proof. I'm fully aware you know more about it than I do. That's why I'm here looking for help.

I'm still wondering if my install of BIND is caching any of the DNS requests it gets from SpamAssassin. Is there some kind of test I can do to find out?

Your server will cache everything it receives an answer about, for as long as the authoritative server says to. For example, look at google.com. Google keeps their available servers on a super short leash. The answer they give is only good for 5 minutes (300 seconds). If nobody has asked your DNS server the address of google.com in 300 seconds, it gets a fresh answer. See here ->
Google in essence has told my server, here's your answer, now shut up for 300 seconds. My server won't ask anyplace again for the 300 seconds. You can see my server will keep answering from its cache until that 300 seconds goes down to 0, then it will ask again ->

Some time later, after the original 300 seconds has expired, the next query will again go to google's nameservers (which understandably have a MUCH larger timeout) ->
By the way, did you see what version of BIND my Debian laptop used to ask about google? Looks like 9.4.1-P1. How about my home server? Seems to be the latest and greatest. The only way to get great software doing what you want is to roll your own. Get your tarball, extract it to /usr/local, then ./configure, make, and make install. If you want to wait and hope what your package manager has chosen to do with a package works for you, that's fine. I'd be lying out my teeth if I said I compiled all my own software, but I can be certain that I compile anything that I actually use often. If you're close enough to a project to be on its mailing list, then you'll want the new and improved version the minute it comes out, and a package manager doesn't give you that. Etch might be 9.3.4, but all my Etch machines happily run 9.4.1.

You're either receiving a notify because you have configured yourself to be 2 machines (both a master and slave on one, are using 2 IP addresses, or the most likely, you are hearing from what is the authoritative server for your domain, although for you to hear it is odd. I am not willing to troubleshoot that, as you are obscuring your domain name and the servers involved. That is a common mistake among newbies. When you're looking for help with DNS, you can't hide those things. DNS is not an attack vector. The worst that can be done with DNS is that they ask you your IP address.

This is a proper header for a zone file ->
0) The total size of my logs will never exceed 65 Mb. If you don't have 65 Mb of space, you don't have enough room to do anything. Use my config, or modify it to suit your needs, but keep the BIND log separate from the queries. Queries are only useful to see what is being asked, or should law enforcement come calling. The bind.log is the important one, and it should be kept separate. I see no reason to run a chroot, but if you want to thats fine. Just modify the log location to be within the chroot.

1) All RHEL is garbage. Sorry, but its true. Becoming dependent on the "right" rpm just prevents you from being able to make your own RPM. If you run a public server, I strongly suggest Slackware, Debian, or any of the open/free BSD family.

You can dump your cache to a log file, but it is easiest to do with the command -> You need to define a dump location in named.conf.

You don't need to do that though. You'd have to tweak the hell out of BIND to make it not cache its answers. Add a line like this to named.conf - dump-file "/var/log/named/dump.db";

Your help session is over. You've got all the pieces done, just assemble to toy and play with it!

Peace,
JimBass

Cheers Jim! Thanks for all your help. Feeling much better about this now and there's no way I could have done it as quickly without your tips. Hope I haven't discouraged you from helping us noobs.