How should I configure internal and external DNS servers

[Nick Howitt]

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