I run an internal DNS server (BIND 9.1.3) at my office. Mostly, it just serves to give hostnames to our DHCP clients, so we can refer to them by name when Windows’ name resolution doesn’t work. Let’s call our domain “foo.com”; all the DHCP clients are automatically given addresses like lab1.int.foo.com and scanner.int.foo.com, and *.int.foo.com only exists on our local network. Our ISP manages the nameserver in charge of foo.com for the outside world, as well as our public web and mail servers.
The same machine is also our CVS server, and it can be accessed from the internet as inside.foo.com when someone needs to access the source code repository from home. But we’re behind a NAT, and we can’t use that hostname internally, because the NAT only forwards connections to that address from the outside - we have to use linux.int.foo.com, which resolves to the server’s private address (192.168.1.1). This is a problem for CVS and laptops, because when you check out a module, your CVS client stores the hostname of the repository where you got it. If I check files out at the office onto a laptop using that private hostname, I won’t be able to check them back in from home.
So, I think I’ve come up with a better use for this private DNS server. What I want to do is make it resolve inside.foo.com to 192.168.1.1, keep managing *.int.foo.com for DHCP the way it currently does, and forward all other *.foo.com requests to our ISP’s nameserver. That way, I can access the server as inside.foo.com whether I’m at work or at home, but I won’t have to update the server with any changes our ISP might make to www.foo.com, mail.foo.com, etc.
Is this possible?
How would I go about doing it? Or, where can I find it explained? I’ve read the basic DNS HOWTO, but this seems like a more advanced topic.
I’m no BIND expert but can’t you define in your configuration just what you said?
Can’t you tell your local BIND server that it is authoritative for inside.foo.com and *.int.foo.com, but that for any other foo.com addresses it will have to go to the next BIND server for information?
I can’t give you specific configuration examples, but that should be doable. It’s the nature of name resolution: if you can’t find it here, ask somebody else. If you find it here, don’t bother asking.
Possibly, but I’m not sure how to set that up. I can configure the zone as “master”, which makes it authoritative; “slave”, which makes it copy all information about the zone from a specified master server; and “forward”, which will redirect all queries to another server.
It looks like if I set this as a slave, it’ll use an exact copy of our ISP’s zone file, including the public address for inside.foo.com that I don’t want… but if I make it a master, I’ll have to copy and maintain the addresses for our web server, mail server, etc. in the new zone file.
OK, I think I’ve got it. Instead of creating a zone for foo.com and putting an entry for “inside” therein, I gave inside.foo.com its own zone. Now the server is authoritative for that host and for *.int.foo.com but not for any other *.foo.com.
IIRC, you can also define specific records as non-authoritative. It’s been over five years since I set up a BIND server, so take it for what it’s worth.
I recommend you set up a VPN and mandate that your remote users use it.
That will resolve your issue, since remote users will go to the same DNS as your internal users, and cvs.foo.com will always be 192.168.1.1. But it will also have the happy extra (and arguably more important) benefit that your companies source code will be secure.
I would set up a VPN if we had a lot of remote users, but honestly, I’m the only one here who ever uses CVS remotely, and it’s not worth calling the ISP to get them to tinker with the router. The only way to access CVS remotely is through SSH (only ports 80 and 22 are forwarded), so it’s already secure in the sense that it’s encrypted and access is controlled by passwords or private keys.
If it’s only you and you don’t access CVS remotely very often, then personally I would just modify your client’s host file every time you need remote access, adding an entry for cvs.foo.com.
I agree that ssh secures the connection just fine.