<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Unfortunately, redesigning the internal zone is way beyond the scope
of what I can do, but thanks for the info.<br>
<br>
<div class="moz-cite-prefix">On 04/11/2023 13:40, Greg Choules
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANsEUy3XhCskgctxvi+y0Hna7BJUTxQySuaM8e9wX2mcsNc48g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Nick.
<div>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.</div>
<div><br>
</div>
<div>What would be better (IMHO) is for you to keep "<a
href="http://example.com" moz-do-not-send="true">example.com</a>"
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 - "<a
href="http://internal.example.com" moz-do-not-send="true">internal.example.com</a>"
(maybe also other "<a href="http://somethingX.example.com"
moz-do-not-send="true">somethingX.example.com</a>" too) as
your internal zone in an internal primary server for serving
internal clients with the addresses they need.</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>The internal primary server just sits there and provides
answers for internal names. It would probably not need to have
recursion enabled, </div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>If the resolver receives queries for non-internal names - <a
href="http://e.g.public.example.com" moz-do-not-send="true">e.g.public.example.com</a>,
<a href="http://www.facebook.com" moz-do-not-send="true">www.facebook.com</a>
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).</div>
<div><br>
</div>
<div>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 "<a
href="http://internal.example.com" moz-do-not-send="true">internal.example.com</a>"
the resolver deals with as if it were anything else in the
world. That includes anything in "<a href="http://example.com"
moz-do-not-send="true">example.com</a>", for which it
queries the external primary server, just like anyone else in
the world would.</div>
<div><br>
</div>
<div>The external primary server does not need recursion enabled
because queries it receives (from resolvers) will have the RD
bit set to 0.</div>
<div><br>
</div>
<div>One other thing you ought to do in the external primary
server, in the zone "<a href="http://example.com"
moz-do-not-send="true">example.com</a>", is to delegate "<a
href="http://internal.example.com" moz-do-not-send="true">internal.example.com</a>"
to your internal authoritative servers. This doesn't suddenly
mean that the world can make queries for "<a
href="http://name.internal.example.com"
moz-do-not-send="true">name.internal.example.com</a>"
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.</div>
<div><br>
</div>
<div>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 "<a href="http://example.com"
moz-do-not-send="true">example.com</a>" to tell it where "<a
href="http://internal.example.com" moz-do-not-send="true">internal.example.com</a>"
lives, then the chain is complete. This is a bit simplistic,
but that's the general idea.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 "<a href="http://example.com"
moz-do-not-send="true">example.com</a>" internally because
that will obscure the external version completely. Zones like
"<a href="http://internal-www.example.com"
moz-do-not-send="true">internal-www.example.com</a>", "<a
href="http://internal-mail.example.com"
moz-do-not-send="true">internal-mail.example.com</a>" and
what have you are fine because they are more specific than the
general "<a href="http://example.com" moz-do-not-send="true">example.com</a>",
queries for which will just fall through to the outide world
along with any other name.</div>
<div><br>
</div>
<div>That was a bit of an essay, but I hope at least some of it
made sense.</div>
<div><br>
</div>
<div>Cheers, Greg</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 3 Nov 2023 at 16:33,
Nick Howitt via bind-users <<a
href="mailto:bind-users@lists.isc.org"
moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hmm,
I'll admit to only skim reading it but is seems quite
complicated <br>
for what I was hoping for. It would be trivial if I could
change the <br>
bind-internal machine to using dnsmasq (ugh!). Then the
bind-internal <br>
machine would serve up anything it explicitly knew about to
the internal <br>
clients, and anything that it didn't know about, it would
automatically <br>
request from the internet, which would include the
bind-external <br>
machine. Then, if I configured external IP's on bind-external
only, they <br>
would still be returned by by bind-internal to the machines
using <br>
bind-internal as their resolver. I was hoping I could set
something like <br>
recursion=true in bind-internal and recursion=false on
bind-external, <br>
only in my configs for BIND 9.9.6-P1, it is not set at all so
I am not <br>
sure how it is configured as authoritative.<br>
<br>
Nick<br>
<br>
On 2023-11-03 16:01, Andrew Latham wrote:<br>
> * That sounds like a sadly normal implementation but yes
you can do<br>
> better* Views is a good place to look <a
href="https://kb.isc.org/docs/aa-00851" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://kb.isc.org/docs/aa-00851</a><br>
> * Make sure to investigate how the company VPN services
handle DNS as<br>
> it may surprise you<br>
> <br>
> On Fri, Nov 3, 2023 at 9:52 AM Nick Howitt via bind-users<br>
> <<a href="mailto:bind-users@lists.isc.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bind-users@lists.isc.org</a>>
wrote:<br>
> <br>
>> Hi,<br>
>> <br>
>> I am fairly new to bind but I am thinking my
company's use of it is<br>
>> sub-optimal. We have two bind masters (and a few
slaves), one for<br>
>> internal use so all our internal servers point to it
or its slaves<br>
>> as<br>
>> their DNS resolvers. I will call the internal one
bind-internal and<br>
>> the<br>
>> external one bind-external.<br>
>> <br>
>> Bind-internal is set up as authoritative for the
domain <a href="http://example.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">example.com</a><br>
>> [1].<br>
>> Bind-external is also set up as authoritative for <a
href="http://example.com" rel="noreferrer" target="_blank"
moz-do-not-send="true">example.com</a> [1].<br>
>> <br>
>> Bind-internal has all sorts of entries resolving in
the 10.30, 10.40<br>
>> and<br>
>> other private ranges, but it also has entries
resolving to our<br>
>> public<br>
>> IP's e.g. <a href="http://demo.example.com"
rel="noreferrer" target="_blank" moz-do-not-send="true">demo.example.com</a>
[2] resolves to 1.2.3.4 (terminated by an<br>
>> F5),<br>
>> which is one of our public ips (munged). As this site
is externally<br>
>> accessible as well, we also have to put an identical
entry in<br>
>> bind-external so we end up having many identical
entries in<br>
>> bind-internal and bind-external. We also have some
other domains<br>
>> covered<br>
>> by bind-internal with external IPs, but externally
they are covered<br>
>> by<br>
>> the domain host's DNS and they have the same issue
where in<br>
>> bind-internal we have some public IP's which are also
in the domain<br>
>> host's DNS for external access.<br>
>> <br>
>> I have a feeling this is a sub-optimal setup, having
to maintain<br>
>> external IPs in both bind-internal and bind-external.
Does it make<br>
>> sense<br>
>> to stop bind-internal from being authoritative and
make it a<br>
>> resolver/caching name server? This way, if it does
not find an entry<br>
>> in<br>
>> bind-internal it will then go out to either
bind-external or the<br>
>> domain<br>
>> host's DNS to get the answer from the authoritative
servers and then<br>
>> <br>
>> there is no need to maintain external IPs in bind
internal.<br>
>> <br>
>> TIA,<br>
>> <br>
>> Nick<br>
>> --<br>
>> Visit <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
to<br>
>> unsubscribe from this list<br>
>> <br>
>> ISC funds the development of this software with paid
support<br>
>> subscriptions. Contact us at <a
href="https://www.isc.org/contact/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.isc.org/contact/</a>
for more<br>
>> information.<br>
>> <br>
>> bind-users mailing list<br>
>> <a href="mailto:bind-users@lists.isc.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bind-users@lists.isc.org</a><br>
>> <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
> <br>
> --<br>
> <br>
> - Andrew "lathama" Latham -<br>
> <br>
> Links:<br>
> ------<br>
> [1] <a href="http://example.com" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://example.com</a><br>
> [2] <a href="http://demo.example.com" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://demo.example.com</a><br>
-- <br>
Visit <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support
subscriptions. Contact us at <a
href="https://www.isc.org/contact/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.isc.org/contact/</a>
for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>