How should I configure internal and external DNS servers
Nick Howitt
nick at howitts.co.uk
Sat Nov 4 19:48:56 UTC 2023
Unfortunately, redesigning the internal zone is way beyond the scope of
what I can do, but thanks for the info.
On 04/11/2023 13:40, Greg Choules wrote:
> Hi Nick.
> First question, does the internal zone *have* to keep the same name?
> As has been said already, this is a fairly common setup done by people
> a long time ago who usually didn't think through the consequences of
> their actions. What follows assumes you could change the name of the
> internal zone.
>
> What would be better (IMHO) is for you to keep "example.com
> <http://example.com>" as your external zone in an external (hopefully
> in a DMZ) primary server, serving the world with public addresses they
> need to reach, and internally create a new zone -
> "internal.example.com <http://internal.example.com>" (maybe also other
> "somethingX.example.com <http://somethingX.example.com>" too) as your
> internal zone in an internal primary server for serving internal
> clients with the addresses they need.
>
> Internal clients send recursive queries (RD bit set to 1, hence why
> recursion needs to be enabled) to an internal server, if you can
> separate the functions physically: this server is a resolver (aka
> cache) because of that.
> That resolver *could* get its internal data from a separate, internal
> primary server in a number of ways - stub, static-stub, secondary or
> forward zones. I won't go into the differences right now.
> The internal primary server just sits there and provides answers for
> internal names. It would probably not need to have recursion enabled,
>
> If you only have a single box internally (though I'd recommend at
> least two, for resilience) they can be both resolver *and*
> authoritative in the same box. You don't need views. In this case the
> primary zone is defined on this box rather than on a different box. If
> you have another one and want it to behave identically it could be a
> secondary server to this primary
>
> If the resolver receives queries for non-internal names -
> e.g.public.example.com <http://e.g.public.example.com>,
> www.facebook.com <http://www.facebook.com> or anything else, they
> won't match the internal zone and thus they are candidates for
> external resolution. It could contact the outside world in a number of
> ways, such as by direct recursion, forwarding to your own forwarder in
> a DMZ (which then does the recursion) or forwarding to a public
> service such as Google (others exist).
>
> The principle is that the internal zone(s) is a subdomain of the
> external zone and hence more specific: a bit like adding host routes
> in a router. Anything that is not in "internal.example.com
> <http://internal.example.com>" the resolver deals with as if it were
> anything else in the world. That includes anything in "example.com
> <http://example.com>", for which it queries the external primary
> server, just like anyone else in the world would.
>
> The external primary server does not need recursion enabled because
> queries it receives (from resolvers) will have the RD bit set to 0.
>
> One other thing you ought to do in the external primary server, in the
> zone "example.com <http://example.com>", is to delegate
> "internal.example.com <http://internal.example.com>" to your internal
> authoritative servers. This doesn't suddenly mean that the world can
> make queries for "name.internal.example.com
> <http://name.internal.example.com>" because they won't be able to
> reach your internal servers to get queries to them. Even if they
> could, an answer like 10.10.10.10 would be meaningless.
>
> The reason for the delegation is DNSSEC. If you enable DNSSEC
> validation on your resolver, which is a good idea, it would work fine
> for the rest of the world. But to validate internal names it needs to
> be able to follow the path to the internal authoritative servers, all
> the way down from the root. So it needs "example.com
> <http://example.com>" to tell it where "internal.example.com
> <http://internal.example.com>" lives, then the chain is complete. This
> is a bit simplistic, but that's the general idea.
>
> If you cannot change the internal zone name and it *must* stay the
> same as the external zone name, life gets a little more complicated
> but it's still workable.
>
> Internally you would have to split DNS functions into two sets of
> servers - recursive and authoritative. These could be different views
> on the same boxes, but that starts getting tricky and I would
> recommend separate IP addresses for each function if that's the path
> you have to take.
>
> The general principle is still the same: internal names are more
> specific subdomains of the external zone. But in this case each
> internal name would need to be its own zone (stub, static-stub etc.)
> and the resolver would need to be told how to obtain answers for these
> zones. The vital point is that you *must not* configure the zone
> "example.com <http://example.com>" internally because that will
> obscure the external version completely. Zones like
> "internal-www.example.com <http://internal-www.example.com>",
> "internal-mail.example.com <http://internal-mail.example.com>" and
> what have you are fine because they are more specific than the general
> "example.com <http://example.com>", queries for which will just fall
> through to the outide world along with any other name.
>
> That was a bit of an essay, but I hope at least some of it made sense.
>
> Cheers, Greg
>
> On Fri, 3 Nov 2023 at 16:33, Nick Howitt via bind-users
> <bind-users at lists.isc.org> wrote:
>
> Hmm, I'll admit to only skim reading it but is seems quite
> complicated
> for what I was hoping for. It would be trivial if I could change the
> bind-internal machine to using dnsmasq (ugh!). Then the bind-internal
> machine would serve up anything it explicitly knew about to the
> internal
> clients, and anything that it didn't know about, it would
> automatically
> request from the internet, which would include the bind-external
> machine. Then, if I configured external IP's on bind-external
> only, they
> would still be returned by by bind-internal to the machines using
> bind-internal as their resolver. I was hoping I could set
> something like
> recursion=true in bind-internal and recursion=false on bind-external,
> only in my configs for BIND 9.9.6-P1, it is not set at all so I am
> not
> sure how it is configured as authoritative.
>
> Nick
>
> On 2023-11-03 16:01, Andrew Latham wrote:
> > * That sounds like a sadly normal implementation but yes you can do
> > better* Views is a good place to look
> https://kb.isc.org/docs/aa-00851
> > * Make sure to investigate how the company VPN services handle
> DNS as
> > it may surprise you
> >
> > On Fri, Nov 3, 2023 at 9:52 AM Nick Howitt via bind-users
> > <bind-users at lists.isc.org> wrote:
> >
> >> Hi,
> >>
> >> I am fairly new to bind but I am thinking my company's use of it is
> >> sub-optimal. We have two bind masters (and a few slaves), one for
> >> internal use so all our internal servers point to it or its slaves
> >> as
> >> their DNS resolvers. I will call the internal one bind-internal and
> >> the
> >> external one bind-external.
> >>
> >> Bind-internal is set up as authoritative for the domain
> example.com <http://example.com>
> >> [1].
> >> Bind-external is also set up as authoritative for example.com
> <http://example.com> [1].
> >>
> >> Bind-internal has all sorts of entries resolving in the 10.30,
> 10.40
> >> and
> >> other private ranges, but it also has entries resolving to our
> >> public
> >> IP's e.g. demo.example.com <http://demo.example.com> [2]
> resolves to 1.2.3.4 (terminated by an
> >> F5),
> >> which is one of our public ips (munged). As this site is externally
> >> accessible as well, we also have to put an identical entry in
> >> bind-external so we end up having many identical entries in
> >> bind-internal and bind-external. We also have some other domains
> >> covered
> >> by bind-internal with external IPs, but externally they are covered
> >> by
> >> the domain host's DNS and they have the same issue where in
> >> bind-internal we have some public IP's which are also in the domain
> >> host's DNS for external access.
> >>
> >> I have a feeling this is a sub-optimal setup, having to maintain
> >> external IPs in both bind-internal and bind-external. Does it make
> >> sense
> >> to stop bind-internal from being authoritative and make it a
> >> resolver/caching name server? This way, if it does not find an
> entry
> >> in
> >> bind-internal it will then go out to either bind-external or the
> >> domain
> >> host's DNS to get the answer from the authoritative servers and
> then
> >>
> >> there is no need to maintain external IPs in bind internal.
> >>
> >> TIA,
> >>
> >> Nick
> >> --
> >> Visit https://lists.isc.org/mailman/listinfo/bind-users to
> >> unsubscribe from this list
> >>
> >> ISC funds the development of this software with paid support
> >> subscriptions. Contact us at https://www.isc.org/contact/ for more
> >> information.
> >>
> >> bind-users mailing list
> >> bind-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> >
> > --
> >
> > - Andrew "lathama" Latham -
> >
> > Links:
> > ------
> > [1] http://example.com
> > [2] http://demo.example.com
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> 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/20231104/c1279bfa/attachment-0001.htm>
More information about the bind-users
mailing list