I have a TLD with a series of subdomains that are public, say *.example.com. I also have a private server which is used as a SVN repository, which I would like to have available at svn.example.com, but only on the private network. Currently I've achieved that by creating the zone file svn.example.com.zone and using this declaration:

All other domains are forwarded to the public nameserver. This works, but it's not ideal because it requires creating a whole new zone if I want to add a new private subdomain. If I make this zone the master record for the whole example.com TLD, then I assume requests to the currently public *.example.com will no longer work for clients using the private DNS (unless they are duplicated in the private DNS's zone file).

Is there a way for me provide a zone file that specifies one or more private subdomains, but still forwards requests it can't resolve to the public name server? I tried using the forward zone type, but then I can't specify my own zone file, it only forwards.

Update

DNS for Rocket Scientists Chapter 6 gives an example DNS configuration of a stealth DNS server on an internal network. This seems to match up with what I want to achieve reasonably well, and specifically suggests duplicating the public DNS records in the private DNS zone. Obviously though the problem I want to solve is the duplication of records, so this is more a workaround.

4 Answers
4

split DNS - having different DNS records on an internal DNS server...but the internal DNS server has to have all the records, and requires syncing between the internal and external servers

delegation - which is creating the svn.example.com zone, and having your example.com DNS servers look to svn.example.com for anything relating to *.svn.example.com (including svn.example.com itself)

One way is to delegate a subdomain like "internal.example.com" to your LAN's DNS servers. On these DNS servers you can configure a zone for internal.example.com (or i.example.com if you want it shorter), and add any records you want.

You may be able to automate the syncing of your internal and public DNS servers to use split DNS, depending on what software you are using on each of them.

A third option would be to just put the internal IP addresses in your public DNS. This may have security implications (someone could use it to trick you to connect to their server if you aren't on your LAN), but should work and is dead simple to setup.

The easiest way around this is to have all internal addresses under an internal subdomain, e.g., *.internal.example.com. This also removes any ambiguity that the hostname you're accessing is internal only, and will not resolve from the outside.

I don't think a view is solving the same problem: "presenting one view of a zone to one community of hosts and another view to others". I'm only dealing with a single subnet / "community of hosts", so don't think it applies.
–
Adam SharpMay 22 '12 at 23:21

@Adam Sharp: Make zone "svn.example.com" available to only on IP subnet using views. And you can also put shared records in another file and include it in main files using '$INCLUDE "/path/to/file/with/shared/records"'. "
–
0xFFMay 24 '12 at 5:16

Maybe I'm missing something, but I'm not sure how that's different from having the public and private DNS records in the same zone? The public DNS zone (example.com) is maintained by our registrar, not controlled directly by us. When users are on the VPN using the stealth DNS, the internal DNS becomes authoritative for the example.com zone, thus the DNS records maintained by our registrar have to be duplicated so that those names still resolve when on the VPN.
–
Adam SharpMay 24 '12 at 7:16