DNS passthrough on no explicit result?

Rich Goodson rgoodson at gronkulator.com
Fri Jan 31 16:44:03 UTC 2014


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 <steve at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140131/39b17547/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4154 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140131/39b17547/attachment-0001.bin>


More information about the bind-users mailing list