you haven’t mentioned your firewall or router config between the private
corporate network and the public internet (or I missed it).
Cisco firewalls and I bet others too, have a very interesting and powerful
capability – to examine and edit/change packet data (payload data) on the fly
in real-time --- that is, when the firewall sees a dns lookup/resolver response
coming in from the outside, and notices the internal dns ‘answer’ is for an IP
address that is mapped/translated in the firewall to a 10. address (just an
example), the firewall will edit that payload and replace the public IP with
the 10. address so the internal PC (or helper/resolver internal server) that
asked for the dns lookup will receive the correct 10. answer – to avoid NAT
hairpinning (?) -- or so I’m told by my co-workers 😊
what this means, if your equipment has this feature, is internal lookups can go
to your public dns server and will receive the appropriate internal answer
while outside lookups for the same entry will receive a public IP answer – thus
you don’t need a duplicate zone internally just to hand out 10. addresses for
internal servers/equipment for use by internal PCs. Did you mention you have
internal entries for internal use that don’t exist in the public zone --- if so
then decide if exposing just the internal name and its matching 10. address to
the public is an issue – note that external users, assuming they can guess that
secret internal name, will only learn the 10. address but hopefully your
routers and firewalls, as well as the outside user’s equipment, will never
allow an outside user to connect into your internal network using a 10. address
for that connection. That is, its possible there is no harm in having your
public zone containing the secret name and its 10. address.
Also bind supports ACLs on many items (I forget which one for resolution
exactly) so if you want, you can have your public dns servers be used as
resolvers by all your internal 10. PCs while not allowing resolution by any
outside aka public connections (that is, only serving its authoritative zones
to public queries). Not sure if your optional goal was to eliminate any
internal dns server of any type. And as others have said I believe, if you do
wish to use bind internally as just a resolver, that’s very easy to set up –
plus it lets you not have to learn and manage two different dns packages.
Verne Britton
From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of Nick Howitt
via bind-users [*]
Sent: Saturday, November 4, 2023 3:42 PM
To: bind-users@lists.isc.org
Subject: Re: How should I configure internal and external DNS servers
Thanks for the reply. Interesting.
Option A - It works but I would like to stop maintaining two different servers
with the same data.
Option B - I have no chance of getting the company to agree to IPv6.
Option C - From your summary, does not appear to remove the requirement to
maintain the data twice
Option D - No chance of re-zoning internally. It would be a long term project
like IPv6.
Option E - Agreed. Does not appear to simplify anything
Option F - Looks really interesting. I'll investigate further
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.
I'll spend some time investigating option F, thanks.
Nick
On 04/11/2023 02:03, Nick Tait via bind-users wrote:
Hi Nick.
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.
But let's start with requirements: I've made some assumptions - please advise
if I've got any of this wrong?:
* 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").
* 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.
* 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.)
* You are not using DNSSEC to sign your zones.
* Your zone structure is more-or-less flat currently. i.e. You don't have
any delegations to sub-zones.
* Your primary reason for having separate authoritative servers is for
privacy, rather than simply being a workaround for IPv4 Network Address
Translation.
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.
Option A: Keep using separate sets of authoritative servers
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...
Option B: Merge the authoritative zones and use IPv6 exclusively for internal
hosts
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?
Option C: Merge servers but use views to serve separate (existing) zone files
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.
Option D: Simple delegation
Depending on whether there is opportunity to do some zone refactoring, you
might consider something like this...
* In Bind-external, create a new zone: internal.example.com
* Use permissions (e.g. allow-query) to limit access to
internal.example.com to only internal clients
* 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.
* You can then get rid of Bind-internal zone. (The servers could still be
used as recursive resolvers though.)
Then, if x.example.com was a name that was previously defined only in
Bind-internal:
* 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.
* 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.
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.
Option E: Split views and delegation
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.
Option F: Response Policy Zones
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:
* No changes to Bind-external.
* 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.
* The Bind-internal servers would be used as recursive resolvers on the
internal network.
Then, if x.example.com was a name that was previously defined only in
Bind-internal:
* 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.
* Externally if you attempt to resolve x.example.com, the query will be
received by the Bind-external servers, which will return NXDOMAIN.
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.
The main draw-back I see with this option is the complexity it creates.
Option G: Use something other than BIND (e.g. DNSMasq)
...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.
I'm sure there are other options that I haven't thought of, but hopefully you
might find these ideas useful?
Nick.
On 4/11/23 04:51, Nick Howitt via bind-users 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.
Bind-external is also set up as authoritative for example.com.
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.
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
