DNS passthrough on no explicit result?

Steve Presser steve at pressers.name
Fri Jan 31 17:15:06 UTC 2014


Carl, Sten,
Thanks! That's exactly what I was looking for.
Steve
On Jan 31, 2014 12:10 PM, "Sten Carlsen" <stenc at s-carlsen.dk> wrote:

> I can add that this is what I do to solve the same problem.
>
> I have one difference that you may consider:
> I am a stealth master for my external zone, so all changes to IPs will
> be controlled from my side and slaved on the public facing servers.
>
> On 31/01/14 17:44, Rich Goodson wrote:
> > 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 <http://example.com>. IN NS  ns1.example.com
> > <http://ns1.example.com>.
> > example.com <http://example.com>. IN  NS  ns2.example.com
> > <http://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 <http://example.com>.  10 IN MX mail.example.com
> > <http://mail.example.com>.
> >
> > Internal:
> > SOA record
> > example.com <http://example.com>.  IN  NS  ns3.example.com
> > <http://ns3.example.com>.
> > example.com <http://example.com>.  IN  NS  ns4.example.com
> > <http://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 <http://example.com>.  10 IN MX mail.example.com
> > <http://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 <http://name.example.com>?  what resolver are you
> > using?), but it does have some advantages, like you can specify
> > jabber.example.com <http://jabber.example.com> in the external version
> > of the zone to resolve to 12.34.56.78, and have jabber.example.com
> > <http://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 <http://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
> > <mailto: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 <mailto:bind-users at lists.isc.org>
> >> https://lists.isc.org/mailman/listinfo/bind-users
> >
> >
> >
> > _______________________________________________
> > 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
> >
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>
>        "MALE BOVINE MANURE!!!"
> _______________________________________________
> 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/c6d49c51/attachment-0001.html>


More information about the bind-users mailing list