My scenario and quandry was this:
Right now, our company is having our website (and inherently our domain) maintained and hosted with an outside provider. This is fairly simple to set up, and all the back-end stuff is kept nice and tidy on some remote server that isn't likely to have any serious power outages, so our public content is pretty much guaranteed to always be live.
However, our domain and its DNS records were being handled by this service as well (company.com, www.company.com, ftp.company.com, etc). This wasn't too much of a problem, because before we didn't care.
Then I decided, hey it would be really nice to have a server where we could host internal company things such as an internal website, network storage area, svn/git, etc. This was easy. Just get the boss to buy us a fancy new server computer from Dell, install a good, solid Linux server OS on it and get going. And it worked no problem.
And it turns out our public (internet) IP was static as well, which meant that I could get up on that public webhost DNS record and add a nice little subdomain for our public IP to let us serve up internal.company.com with a few port forwarding configurations through our NAT router and cable gateway. Awesome!
However, there was one big issue. For because we are set up with a two-step configuration to connect to the internet (router signs into cable modem as a client, and cable modem signs into Comcast), we were not able to pull up internal.company.com from INSIDE the company. Of course, what sort of issue is that, when you can just dial in the reserved IP 192.168.10.2 from inside? Well...that's confusing. Not that confusing to someone who knows what they're doing, but definitely confusing to someone who is just trying to make it work.
But how should I set it up so that if someone from outside the LAN is trying to access internal.company.com they get routed to our Comcast public IP, but if they're inside the LAN, they get routed to 192.168.10.2?
I had toyed with the idea of an in-house DNS for quite a while. Yet, everywhere I read, there was a ton of legaleze mixed into the documentation: "You shouldn't have records to a name that you don't own, you shouldn't create records for a domain that already has a master record somewhere else, etc." This was annoying. How would I ever be able to even play with the idea of a DNS server if everyone kept telling me I shouldn't do it the only way I saw it could be done?
But then I had this thought: "The entire internet is not going to be able to access my DNS server as long as I don't forward the port it uses through the router. Nobody in the Internet Policing Agency is going to even KNOW that I have a DNS server that is routing domains that I don't own. And after reading all the "this is what DNS actually does" documentation with its levels of looking up names all the way from the website-level DNS servers to the root DNS servers, no actual computer out there will ever use my public IP address to look up DNS records, because I simply won't let the world know it's even possible! I'm not qualified as a valid DNS host, nor do I ever intend to be.
I found a pretty good tutorial at http://doxfer.com/Webmin/BINDDNSServer that was super descriptive in telling me just exactly what DNS did. And then I found the entire article was based around a cool browser-based interface called Webmin. Turns out I can pretty well administrate the entire server over that service. I'm definitely using it for other stuff!
But anyway, after a bit of reading, I decided to give using it a shot.
- I couldn't very well test out a DNS server without configuring a client to route through it for lookups, so I changed my LAN adapter settings in Windows to look at 192.168.10.2 for a primary DNS server. Since I don't care about standards with the system, I decided to leave the secondary field blank, which it took.
- I installed BIND9 via aptitude: sudo apt-get install bind9 bind9-host bind9-doc
- Next I grabbed Webmin from Sourceforge to prepare for its installation: wget http://prdownloads.sourceforge.net/webadmin/webmin_1.660_all.deb though if this article is outdated (which in a few months it probably will be) the actual page to download will be more likely at http://webmin.com/download.html.
- Tried installing it once and it failed due to a few missing libraries, so I grabbed those as well after reading the actual installation instructions from the Webmin wiki: sudo apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl apt-show-versions python
- Now, since I had attempted to install Webmin from the .deb file before, it automatically asked in no simple terms if I wanted to retry after aptitude finished installing those libraries. I apparently said yes to this (sudo apt-get -f install) and webmin was installed from some cache somewhere. However, if I had done it right, I would have next tried: sudo dpkg --install webmin_1.660_all.deb
- Once Webmin was installed and autoconfigured, I was then prompted to navigate to http://server:10000 in my browser:
- Once logged in via Webmin, I navigated to Servers > BIND DNS Server:
However, this only let me access the internet as the internet, the internal network by their hostnames and the local computer as itself. - Now all the tutorials I found said that you should only create a master zone if you own it, and if this was the primary location for its record (to avoid clashing with the actual one or something). However, again, this was all for experimentation, and I had to put rules and standards aside. So I clicked Create master zone in the zone section of the BIND DNS Server configuration window. After all, creating a slave zone only lets you ask an already-existing master for its records. You can't create DNS records in a slave zone.
- From here, I specified the Zone type as Forward, the Domain as company.com, left Records file set as automatic, set, as was recommended on the above-mentioned tutorial, to put the server hostname (server) in the Master server field, and for the heck of it put my email in the email field. The rest I left as default.
- With no problems whatsoever, I was brought to the Edit Master Zone screen.
- Clicking the Address icon, I was brought to an A-NAME record entry screen, where I entered the Name internal and the address 192.168.10.2. I left Update reverse? as Yes which is its default.
- To test it out, I clicked the Apply Zone link at the top right of the screen. However, since I left Time-To-Live as default, I had to wait a few minutes before it actually worked. In time, I was able to open another browser window and successfully load the internal webpage at internal.company.com!!
Sweet! So it works the way I want it. The internal subdomain successfully loads my internal webpages. But what about the external site that was hosted elsewhere, along with its domain name record which is also hosted elsewhere? Well, I've told my own internal domain name server that I'm controlling the root company.com now as the master record, when in all actuality the official root and www subdomains are being controlled offsite by some other company. I guess this is what they meant by making sure there was only one master zone. Well, thankfully BIND can take care of this issue as well! - Backing out to the Master Zone Config screen by clicking the Return to record types link at the bottom the page, I was able to click the Name Server icon. This record type allows me to enter a subdomain and pass all the DNS lookup work off on some other server...which is exactly what I needed to do.
- In the Zone Name field, I first entered @ which is the default root prefix for any domain name. In the Name Server field, I then entered our website hosting DNS server ns1.external.net. Of course, since public, qualified DNS servers have two to three (and in the case of root domain servers, 13) actual machines doing all the work, I created a new Name Server record for the root subdomain with our host's second dns server name ns2.external.net. I also repeated this process for the www and ftp subdomain. In all reality, this seems a lot like the experience one might have with connecting through several devices to get onto the Internet, or port forwarding a port through multiple levels of network firewalls. The cable modem thinks the entire network consists of one client: the router, with an IP address of 10.1.10.48. But the ROUTER sees the rest of the computers on the LAN and serves them up with 192.168.10.xxx IP's. In the same way, the router sees 192.168.10.2 as the actual machine with the webserver that we tell it to forward through to the outside world. But to the router, the outside world is only its single wire from it to the modem on the 10.1.10.xxx network that the modem is serving. And the modem thinks that the router at 10.1.10.48 is the machine with the webserver that it needs to forward through. A lot of information passing just to get information to the outside world, and by then, who knows where it goes with all the routing and hopping?
- In any case, I'd gotten all of my public website subdomain requests passed to our hosting provider's name servers at ns1.external.net and ns2.external.net, applied the zone settings (and just to be safe, applied the configuration as well) in Webmin. After a few minutes, I was able to confirm that yes in fact company.com got me to our external website, as did www.company.com. And still internal.company.com routed me via the LAN to the server's webpage.
- I was basically done.. Except for one thing. How in the world was I going to get all the computers in the shop to look at my DNS server before they went outside to look at the real, public ones? I had set it up on my own computer to look at 192.168.10.2 as its primary DNS server via the IPv4 settings in the Ethernet driver settings, but I had no way of telling the other computers around the shop to do the same. Or did I?
Opening up the main LAN router settings (an Apple Airport Extreme), I was pleased to find in its Internet > TCP/IP settings a little field there titled DNS Server(s):. Entering the LAN IP of my server (again 192.168.10.2), and saving it, I was able to login over the Wi-Fi with my laptop, visit internal.company.com and www.company.com and re-verify that everything STILL worked. Now with every request the router received to pull information from the internet or elsewhere, it would first look at my internal server to pick apart domain names before going outside to the public servers.
So in short, if its for internal use, you can use any domain name you want on in your DNS records. Nobody or computer will know any different unless you explicitly tell it to search your own DNS server first. This method could even be used as a website filtering service. No more proxies through external services. Just create a blacklist and route all traffic via DNS records back in to a page that says, "Sorry. That website is blocked."
And because many people complain that the BIND configuration is super hard to figure out, I would highly recommend running Webmin on your server. It brings a GUI interface to so many of your tools...and eliminates a lot of the headache of typing everything in a console, or figuring out where everything is kept.
No comments:
Post a Comment
Comment loud, comment often. But comment on the content!
All comments are filtered through to my email, so your spam will never make it. Unless, of course, you wanted to try injection attacks into my email, which would probably not happen since Blogger just tells me that a comment is awaiting moderation and doesn't bother to tell me what it says. I trust Blogger like that..