<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thanks for the reply. Interesting.<br>
Option A - It works but I would like to stop maintaining two
different servers with the same data.<br>
Option B - I have no chance of getting the company to agree to IPv6.<br>
Option C - From your summary, does not appear to remove the
requirement to maintain the data twice<br>
Option D - No chance of re-zoning internally. It would be a long
term project like IPv6.<br>
Option E - Agreed. Does not appear to simplify anything<br>
Option F - Looks really interesting. I'll investigate further<br>
Option G - Yes it would be trivial with DNSMasq internally. I don't
think I have any chance of pushing this through. Also DNSMasq does
not support replication (but it could be scripted). I could look for
other solutions but I doubt I would get anywhere in the company.<br>
<br>
I'll spend some time investigating option F, thanks.<br>
<br>
Nick<br>
<br>
<div class="moz-cite-prefix">On 04/11/2023 02:03, Nick Tait via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:034e48c9-3c7f-439a-9d6d-8901da19e915@tait.net.nz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Nick.</p>
<p>Your current set-up sounds like a fairly common configuration.
And depending on your requirements there are a number of options
that you might consider.</p>
<p>But let's start with requirements: I've made some assumptions -
please advise if I've got any of this wrong?:<br>
</p>
<ul>
<li>You have two distinct sets of authoritative servers, which
don't overlap in any way currently. E.g. Servers A
(primary/master), B & C (secondaries/slaves) are
authoritative for internal zone ("Bind-internal"); Servers C
(primary), D & E (secondaries) are authoritative for
external zone ("Bind-external").</li>
<li>The records in Bind-external are a subset of those in
Bind-internal. In other words, for every resource record (not
including SOA & NS records) in Bind-external, there is an
identical record in Bind-internal.<br>
</li>
<li>Do you have another set of servers that act as recursive
resolvers in your network currently, or do A, B and/or C
fulfil that role currently? (I'm going to assume that A, B
& C are used as recursive resolvers on your internal
network for now. It probably doesn't make a huge difference
either way but it is just an extra factor that needs to be
taken into account.)<br>
</li>
<li>You are not using DNSSEC to sign your zones.<br>
</li>
<li>Your zone structure is more-or-less flat currently. i.e. You
don't have any delegations to sub-zones.</li>
<li>Your primary reason for having separate authoritative
servers is for privacy, rather than simply being a workaround
for IPv4 Network Address Translation.<br>
</li>
</ul>
<p>There are a few options worth considering, and I should point
out that some of these won't fit your requirements, in which
case you can immediately rule them out. But I believe it is
important that the decision to rule them out is a conscious one,
so you are fully aware of the scope/limitations of the solution
you end up choosing.<br>
</p>
<p><b>Option A: Keep using separate sets of authoritative servers</b></p>
<p>What you have currently is not a bad configuration. Sure, there
is additional overhead of having to maintain two separate
versions of the zone, but it is easy to understand and
troubleshoot. If your zones are small and are updated
infrequently, then this is probably the best solution. However
the fact you are looking for a better solution suggests this
isn't the case...<br>
</p>
<p><b>Option B: Merge the authoritative zones and use IPv6
exclusively for internal hosts<br>
</b></p>
<p>I only included this because the idea had been put forward
already. But even if the logistics of assigning public IPv6
addresses to your internal hosts was palatable to you, you'd
also want to think about whether you are comfortable making that
information (i.e. the IPv6 addresses used for internal servers)
publicly available? I think most organisations wouldn't want to
do that?<br>
</p>
<p><b>Option C: Merge servers but use views to serve separate
(existing) zone files</b><br>
</p>
<p>If your goal was consolidation of servers while keeping the
existing internal and external zones separate, then this might
be worth looking at. But you haven't mentioned consolidation as
a requirement so I'm going to skip over this one. Also it
doesn't solve the problem of having multiple zones to maintain.<br>
</p>
<p><b>Option D: Simple delegation</b></p>
<p>Depending on whether there is opportunity to do some zone
refactoring, you might consider something like this...</p>
<ul>
<li>In Bind-external, create a new zone: internal.example.com<br>
</li>
<li>Use permissions (e.g. allow-query) to limit access to
internal.example.com to only internal clients</li>
<li>For each zone record in Bind-internal that doesn't exist in
Bind-external, create a CNAME record in Bind-external that
points to the same name in internal.example.com zone.<br>
</li>
<li>You can then get rid of Bind-internal zone. (The servers
could still be used as recursive resolvers though.)<br>
</li>
</ul>
<p>Then, if x.example.com was a name that was previously defined
only in Bind-internal:</p>
<ul>
<li>Internally if you attempt to resolve x.example.com, the
result will be a CNAME that points to x.internal.example.com,
which resolves to the 10.x.x.x IP address.</li>
<li>Externally if you attempt to resolve x.example.com, the
result will be a CNAME that points to x.internal.example.com,
which will result in some sort of access denied error.</li>
</ul>
One possible concern with this idea is that even though an
external client can't retrieve the IP address of an internal
server, the CNAME + access denied error tells them that the name
does still exist.<br>
<p><b>Option E: Split views and delegation </b><br>
</p>
<p>If you liked the general idea of option D, but didn't like the
bit where externally attempting to resolve internal host names
resulted in an access denied error, then you could look at doing
something with views. However this pretty much has the same
problem that you started with, where you end up maintaining two
versions of the example.com zone, so I'm not going to bother
going deeper into this one.<br>
</p>
<p><b>Option F: Response Policy Zones</b><br>
</p>
<p>I saved this one until last because I think this is the most
interesting. If you haven't heard of Response Policy Zones (aka
RPZs) before, they basically allow you to override the response
to a DNS query. You could make use of this feature as follows:</p>
<ul>
<li>No changes to Bind-external.</li>
<li>Change Bind-internal so that it isn't authoritative for
example.com, but has a Response Policy Zone that contains
entries for each of the names that previously only existed in
Bind-internal, that returns the internal IP address.</li>
<li>The Bind-internal servers would be used as recursive
resolvers on the internal network.<br>
</li>
</ul>
<p>Then, if x.example.com was a name that was previously defined
only in Bind-internal:</p>
<ul>
<li>Internally if you attempt to resolve x.example.com, the
query will be received by the Bind-internal servers, which
will ask the Bind-external servers (because they are
authoritative for the zone). The answer from the Bind-external
server will be NXDOMAIN, but the Bind-internal server will
override the result and return the 10.x.x.x IP address
instead.<br>
</li>
<li>Externally if you attempt to resolve x.example.com, the
query will be received by the Bind-external servers, which
will return NXDOMAIN.</li>
</ul>
<p>By default RPZs are only used for recursive queries, and only
if it won't break DNSSEC. But there are configuration options
you can look at to change this behaviour.</p>
<p>The main draw-back I see with this option is the complexity it
creates.<br>
</p>
<p><b>Option G: Use something other than BIND (e.g. DNSMasq)</b><br>
</p>
<p>...Actually, if we're considering all the options this needs to
be included. It may turn out that there is an easier way to
achieve your goal that doesn't use BIND.<br>
</p>
<p><br>
</p>
<p>I'm sure there are other options that I haven't thought of, but
hopefully you might find these ideas useful?<br>
</p>
<p>Nick.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/11/23 04:51, Nick Howitt via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:96d5196551a51b645c2b80b4aaaded2f@howitts.co.uk">Hi, <br>
<br>
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. <br>
<br>
Bind-internal is set up as authoritative for the domain
example.com. <br>
Bind-external is also set up as authoritative for example.com. <br>
<br>
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 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. <br>
<br>
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. <br>
<br>
TIA, <br>
<br>
Nick <br>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
</body>
</html>