Steve, If you must use the same domain for internal names as external, here is one way to do that.
On the recursive resolving name server that you use inside your network, also make that server authoritative for the domain name in question. You’ll need to do double-entry for every externally accessible resource record that you also want to access from inside the network. So, for example: External: SOA record example.com. IN NS ns1.example.com. example.com. IN NS ns2.example.com. ns1 IN A external.ip.address ns2 IN A external.ip.address www IN A external.ip.address mail IN A external.ip.address example.com. 10 IN MX mail.example.com. Internal: SOA record example.com. IN NS ns3.example.com. example.com. IN NS ns4.example.com. ns3 IN A internal.ip.address ns4 IN A internal.ip.address www IN A external.ip.address mail IN A external.ip.address server1 IN A internal.ip.address example.com. 10 IN MX mail.example.com. Obviously, if you move your web site to a different server, you’ll need to change the IP on both the external and internal name servers. This configuration can cause confusion (you can’t resolve name.example.com? what resolver are you using?), but it does have some advantages, like you can specify jabber.example.com in the external version of the zone to resolve to 12.34.56.78, and have jabber.example.com in the internal version of the zone resolve to 10.11.12.13, but it depends on everyone inside the company using your supplied recursive resolvers. You can also keep recursive and authoritative separate by doing approximately this same thing but dedicating a server to your internal zone(s), then on your recursive resolvers using a forward statement or stub zones to short circuit recursion for that/those particular domain name(s). Is this the right way to manage your name space? I don’t know, but that’s a whole other argument. Some people will tell you that you should absolutely use a different name internally than you do out on the Internet. Some companies use example.com outside and example.corp inside (this is what my current company does), but when the .corp TLD gets approved sometime in the indefinite and unknowable future, all of a sudden there are big problems (or a big migration). Good luck, -Rich On Jan 31, 2014, at 10:10 AM, Steve Presser <st...@pressers.name> wrote: > Hey all, > Please forgive me if any of my terminology is off - I have not spent as much > time in the documentation as I'd like. > I have an odd situation that I would like to know if it is possible and would > much appreciate a pointer to any relevant documentation or write-ups. > I manage a domain name which, for reasons of reliability, uses an externally > managed DNS server (zoneedit). We're looking to add private network DNS for > internal machines. I've got BIND up and running on an internal machine. > However, we have public records that need to be accessible internally (SPF, > DKMS, jabber servers, MXs, etc). Additionally, using an internal-only > namespace is not an option, due to laptops which go in and out of the network > and need to be able to connect without settings modification. > I'm trying to figure out how to do some sort of pass through arrangement, > where the internal BIND server will first attempt to do the lookup with local > records. If it has no local record, it will then fall back to the answer > returned by the external (zoneedit) server. > I know that if there was only one server, this would simply be split horizon. > However, I don't know what to call this setup, and am having a hard time > searching for it because of that. (So I apologize if this is then a dumb > question). > > Any help you can offer is much appreciated. Thanks! > Steve > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
