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