How should I configure internal and external DNS servers

[Nick Tait]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231104/591e794e/attachment.htm>