These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for BIND and Nameservers. on the new forum.
I just got a box. And i was given the IP address to it. Now they offer upto 5 ips when you get a box from them. My questoin is this.
When i set up Nameservers i know i need two ns1.XXX.XX and ns2.XXX.XXX .... Can i get two IP addresses to point to the same box ? So that i can add those as Nameservers ? Or do i need another machine to do this for me ?
Secondly, how do you only setup nameservers in BIND ? Using Webmin ofcourse.
Thirdly, do i need reverse zones ? If yes why and how and for everything ? If no .. why not ?
Bind is totally confusing for me at the moment.
Yes, both of your nameservers can be on the same system, and a single system can have effectively unlimited IP addresses. Actually there is a limit, but I believe it is 65k on modern Linux kernels...but I've never needed for than a couple thousand on a single host. ;-)
To add another IP address, you can use the Webmin Networking:Network Configuration:Network Interfaces module. Click on eth0 in Network Interfaces Activated on Boot. And then click on the "Add virtual interface". (You may find you already have virtual interfaces--the two hosting providers I use pre-configure them on new servers. If so, you don't need to do anything.) Then you just configure the virtual interfaces just like a regular interface.
For name servers, check out the BIND chapter of my book:
Particularly the tutorials at the end of the chapter. Virtualmin will actuall perform all of the configuration you need however--so you don't really need to do anything specific in BIND. But it's good to understand what's going on, because at least 50% of the time when I hear about weird network problems as soon as I dig into the problem it is DNS misconfiguration.
Reverse zones: You probably don't need to handle them, but someone does (probably your ISP/hosting provider). Your addresses must reverse resolve to something if you want to send any mail from your server (because many servers block mail from hosts IPs that don't resolve...and most at least consider it a "spammy" characteristic in their SpamAssassin configuration). You can check on whether reverse is configured at your host:
Where 192.168.1.1 should be replaced by one of your five IP addresses. If it comes back with a name (any name), then you'll be fine. If it comes back NXDOMAIN, then you'll need to talk to your host--they will either need to set up reverse correctly, or delegate those 5 IPs to you, so you can setup reverse. I'd be surprised if it doesn't already work, though. (But I've been surprised before. I had a client that had business T1 service through a carrier that will remain nameless, and reverse lookups didn't work about half the time, so we ended up requesting they delegate it down to us so we could take responbility for it and our mail could get through. Took several weeks for me to realize it was intermittently failing.)
If you won't be sending mail, reverse lookups don't matter (much).
BTW-One tricky thing that always catches people:
Your registrar is the one that maps an ns*.yourdomain.com name to an address (which is then queried by outside clients for hosts within your domain). They have gotten a bit tricky in the past few years though and have "improved" things so that you only have to enter a hostname...but this makes it very hard to "bootstrap" a domain into existence if you don't already have a domain with working DNS, because many have removed the ability to enter a domain to IP mapping directly. Life is complicated sometimes. ;-)
Check out the forum guidelines!
Thankyou for this detailed reply. Really helped me a lot.
LOL! I wish I had read this before I bought that second machine.
You really don't want to run both nameservers on the same machine. The primary function of the secondary nameserver is to function when and if the primary goes down. If the box dies both nameservers die and all your hosting and mail is kaput. Best to spend the extra $$$ for a bit more piece of mind.
A generic question I have is this: *****how can you test your secondary nameserver's operation without shutting down the whole operation and waiting half a day for network proagation?******
I know it sounds like a newbie question but I've been basically learning all this on the fly this last year.
<i>You really don't want to run both nameservers on the same machine. The primary function of the secondary nameserver is to function when and if the primary goes down. If the box dies both nameservers die and all your hosting and mail is kaput. Best to spend the extra $$$ for a bit more piece of mind.</i>
This is absolutely true...but if you're running everything on a single server and it goes down, you're hosed anyway, and having backup DNS won't save you. If there's nothing to point to, then no reason to raise a finger at all. ;-)
Anyway, our focus for redundancy has been on mail and DNS, so there is an easy to use mechanism for having a backup mail and DNS server. Most people will tolerate a temporary website outage, but nobody tolerates a mail outage (as I found out when yesterdays Dovecot update, despite quite a bit of testing, broke IMAP/POP service for folks).
There are a lot of great tools for testing DNS. The obvious ones are dig and host, both of which can be used to query specific servers (like querying your secondary server).
So, you'd use host like:
host domain.tld ns2.domain.tld
To look something up on ns2.domain.tld. If ns2 doesn't actually resolve (and you're trying to figure out why), you can use the IP of name servers:
host domain.tld 192.168.1.1
Then the nameserver itself:
host ns2.domain.tld 192.168.1.1
Then find out what the nameserver records point to:
host -t ns domain.tld 192.168.1.1
And, while we're at it, the mail exchange records:
host -t mx domain.tld 192.168.1.1
dig will do a lot of this stuff for you without being asked, but it's output is hard to read. But, for completeness:
This will spit out the ns records and the domain itself, along with the IP addresses. For example:
[[root@www i386]]# dig virtualmin.com
; <<>> DiG 9.2.4 <<>> virtualmin.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58989
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;virtualmin.com. IN A
;; ANSWER SECTION:
virtualmin.com. 38400 IN A 22.214.171.124
;; AUTHORITY SECTION:
virtualmin.com. 38400 IN NS ns0.virtualmin.com.
virtualmin.com. 38400 IN NS ns1.virtualmin.com.
;; ADDITIONAL SECTION:
ns0.virtualmin.com. 38400 IN A 126.96.36.199
ns1.virtualmin.com. 38400 IN A 188.8.131.52
;; Query time: 11 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 24 13:53:44 2007
;; MSG SIZE rcvd: 116
Of course, there's also some easier, and perhaps more comprehensive tests out their on the internet. DNSReport.com is the best known, and very cool:
Check out the forum guidelines!
You've been a newbie at this stuff for approximately 10 months longer than I have.
I was not necessarily testing the Name Server so much as testing the name resolution. When I try to do my https to webmin on the other server, I am able to do it as long as I use the IP address. If I try using the hostname.domain, it will not resolve.
Additionally, when I try adding a new zone on my primary name server, it attempts to update the slave via the name I had set up, and it could not resolve. It works alright if I use the IP address instead.
And ... my pings doesn't work. I can ping srv1, but I cannot ping srv2.
I did make a different type of mistake along the way. I'm new enough at servers that I think I'm allowed to do that yet. :) I had somehow gotten the notion that DNS uses port 42. It doesn't ... it uses 53. I changed that, and half a day later, my virtual domains resolve. I'm betting that they only resolve against srv1, though, because I still have difficulty in resolving to srv2.
I think I'll go back to my registrar and check the configuration there.
I am taking a lot of notes! It helps to have Acrobat installed.
I don't mind the extra machine. It's amazing, but by getting that extra machine, I cleared some junk off my desk. I went out and got a switch. Now, I can run 3 machines through one keyboard/mouse/monitor.
When I'm done messing around, I hope to use the second server as backup on mail as well. It would be terrific if I could find a way to copy a disk image of my first machine to the second one periodically as well. Small steps ....
I started with the dnsreport. I've seen the other tools and I'm new enough to be dangerous with them.
Here are a some of the tidbits that came out of dnsreport:
WARNING: At least one of your nameservers did not return your NS records (it reported 0 answers). This could be because of a referral, if you have a lame nameserver (which would need to be fixed).
ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame:
[[my slave's IP address]]
I had noticed in the past that when I use the Bind:Cluster Slave Servers option, it will create two zones on my slave server. However, neither of those zones has any records in them on that slave. I have no A, NS, MX or SPF records on the slave after I connect.
That's a bad thing, right?
I know what my issue is with this - it's now simply a matter of figuring out how best to handle it. My slave dns server doesn't know it's a slave. It still thinks it is a master.
I know I'm probably putting all kinds of garbage into your forums while I figure this out. I probably wouldn't, but I know how nice it is for other newbies to have something to look back on and say "aaaaaaaaaaah."
Of course, that's only one of several possible responses. ;)
In Server:BIND:Module Config:Zone file options, I set the field called Default master server IP for remote slave zones to the IP of my master DNS server. Then I pushed things through again.
I seem to have all my records on the slave now.
It really cleaned up my DNSReport.
Awesome. Thanks for the update.
I'll mention something that trips up a lot of people, when dealing with BIND.
There are a lot of terms that are confusingly similar, but they mean something quite different:
Secondary and Slave. They sound like they might be the same...and sometimes they are. But the meaning of the two is different. Secondary is simply the second nameserver listed at your registrar (or in a delegation if it's a sub-zone)...it could be a master, or it could be a slave. A slave periodically or automatically on update gets it's information from the master via a zone transfer. Despite this fact, a slave <i>is</i> considered authoritative for a zone and is identical to the master server to outsiders.
Likewise for Primary and Master. One just means it's the first nameserver in the list. The other means that the server actually stores the information permanently and isn't receiving the information for the zone via a transfer from another server. And to repeat the above another way, both the master, and all of its slaves are authoritative for the zones they contain...even though only the master is getting that information directly from you (or Virtualmin), and the slaves are basically being told what to say by the master.
Zone and Domain. This one always trips people up. Zone is a delegation term--it's used to refer to some address and it's sub-domains. So, virtualmin.com is a zone...but I could further delegate sub1.virtualmin.com to another server and that would be another zone. Registrars deal only with zones (specifically a second-level domain name zone: domain.tld), while your nameserver could deal with both. Virtualmin will delegate to other zones, if you create new virtual servers that are sub-domains of existing domains.
Hope this helps anyone who might be reading this thread in the future. We've got a lot more documentation in the pipeline, as well as a conversion of all of it to wiki format in the very near future...so things like this thread can be merged into the docs by me or anyone who thinks it's worth being in the docs on an as-written basis.
Check out the forum guidelines!