Re: How should I configure internal and external DNS servers

[Michael Richardson]

Greg Choules via bind-users  wrote:
> What would be better (IMHO) is for you to keep "example.com" 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 - "internal.example.com" (maybe also other
> "somethingX.example.com" too) as your internal zone in an internal
> primary server for serving internal clients with the addresses they
> need.

Would anyone be interested in formulating this into an IETF BCP RFC?
Or maybe a RIPE BCOP.
Your write up is excellent.  Worth keeping it somewhere.

> The reason for the delegation is DNSSEC. If you enable DNSSEC

Yes.

> That was a bit of an essay, but I hope at least some of it made sense.

:-)



signature.asc
Description: PGP signature
-- 
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

RE: How should I configure internal and external DNS servers

[Verne Britton]

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  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 

Re: How should I configure internal and external DNS servers

[Greg Choules via bind-users]

Hi Nick.
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.

What would be better (IMHO) is for you to keep "example.com" 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 - "internal.example.com" (maybe also other "somethingX.example.com"
too) as your internal zone in an internal primary server for serving
internal clients with the addresses they need.

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.
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.
The internal primary server just sits there and provides answers for
internal names. It would probably not need to have recursion enabled,

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

If the resolver receives queries for non-internal names -
e.g.public.example.com, www.facebook.com 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).

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 "internal.example.com" the resolver deals with as
if it were anything else in the world. That includes anything in "
example.com", for which it queries the external primary server, just like
anyone else in the world would.

The external primary server does not need recursion enabled because queries
it receives (from resolvers) will have the RD bit set to 0.

One other thing you ought to do in the external primary server, in the zone
"example.com", is to delegate "internal.example.com" to your internal
authoritative servers. This doesn't suddenly mean that the world can make
queries for "name.internal.example.com" 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.

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 "example.com" to tell it where "internal.example.com" lives,
then the chain is complete. This is a bit simplistic, but that's the
general idea.

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.

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.

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 "example.com" internally because
that will obscure the external version completely. Zones like "
internal-www.example.com", "internal-mail.example.com" and what have you
are fine because they are more specific than the general "example.com",
queries for which will just fall through to the outide world along with any
other name.

That was a bit of an essay, but I hope at least some of it made sense.

Cheers, Greg

On Fri, 3 Nov 2023 at 16:33, Nick Howitt via bind-users <
bind-users@lists.isc.org> wrote:

> Hmm, I'll admit to only skim reading it but is seems quite complicated
> for what I was hoping for. It would be trivial if I could change the
> bind-internal machine to using dnsmasq (ugh!). Then the bind-internal
> machine would 

Re: How should I configure internal and external DNS servers

[Andrew Latham]

* That sounds like a sadly normal implementation but yes you can do better
* Views is a good place to look https://kb.isc.org/docs/aa-00851
* Make sure to investigate how the company VPN services handle DNS as it
may surprise you

On Fri, Nov 3, 2023 at 9:52 AM Nick Howitt via bind-users <
bind-users@lists.isc.org> 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
>


-- 
- Andrew "lathama" Latham -
-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 04.11.2023 um 19:41:44 Uhr schrieb Nick Howitt via bind-users:

> 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.

Then you are in a stonehenge company. Tell them about the problem and
that relying on IPv4 creates additional work.
My recommendation: Let the people who refuse IPv6 do the DNS work if
possible. :-)

> 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).

Is it possible to use dnsmasq as the master (does it support zone
transfer?) and bind as a slave?
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

Unfortunately, redesigning the internal zone is way beyond the scope of 
what I can do, but thanks for the info.


On 04/11/2023 13:40, Greg Choules wrote:

Hi Nick.
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.


What would be better (IMHO) is for you to keep "example.com 
" 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 - 
"internal.example.com " (maybe also other 
"somethingX.example.com " too) as your 
internal zone in an internal primary server for serving internal 
clients with the addresses they need.


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.
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.
The internal primary server just sits there and provides answers for 
internal names. It would probably not need to have recursion enabled,


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


If the resolver receives queries for non-internal names - 
e.g.public.example.com , 
www.facebook.com  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).


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 "internal.example.com 
" the resolver deals with as if it were 
anything else in the world. That includes anything in "example.com 
", for which it queries the external primary 
server, just like anyone else in the world would.


The external primary server does not need recursion enabled because 
queries it receives (from resolvers) will have the RD bit set to 0.


One other thing you ought to do in the external primary server, in the 
zone "example.com ", is to delegate 
"internal.example.com " to your internal 
authoritative servers. This doesn't suddenly mean that the world can 
make queries for "name.internal.example.com 
" 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.


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 "example.com 
" to tell it where "internal.example.com 
" lives, then the chain is complete. This 
is a bit simplistic, but that's the general idea.


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.


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.


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 
"example.com " internally because that will 
obscure the external version completely. Zones like 
"internal-www.example.com ", 

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

As on other replies, a different internal zone is a huge project for the 
company, not a quick win, unfortunately.


On 04/11/2023 08:55, Michael Richardson wrote:

Given VPNs, RemoteAccess and the like, I strongly recommend against split-DNS
configurations.  They were great ideas in 1993, when all sites were concave,
but that's just not the case anymore.

Instead, I recommend having a sub-zone, "internal.example.com", or some other
convenient name.  Put a zone split ("NS" and "DS" records) there, and then
limit who can do queries to this zone by IP address.  You'd acceptlist all of
your VPN sites, the v4 (RFC1918) and v6 (subnet) prefixes for your remote
access clusters.

Split-DNS finally has some actual IETF definition at:
   
https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/

I'm specifically arguing to do:
   
https://www.ietf.org/archive/id/draft-ietf-add-split-horizon-authority-06.html#name-internal-only-subdomains

It's just so much easier, particularly if you are starting from scratch.

-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

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.
  * 

Re: How should I configure internal and external DNS servers

[Michael Richardson]

Given VPNs, RemoteAccess and the like, I strongly recommend against split-DNS
configurations.  They were great ideas in 1993, when all sites were concave,
but that's just not the case anymore.

Instead, I recommend having a sub-zone, "internal.example.com", or some other
convenient name.  Put a zone split ("NS" and "DS" records) there, and then
limit who can do queries to this zone by IP address.  You'd acceptlist all of
your VPN sites, the v4 (RFC1918) and v6 (subnet) prefixes for your remote
access clusters.

Split-DNS finally has some actual IETF definition at:
  
https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/

I'm specifically arguing to do:
  
https://www.ietf.org/archive/id/draft-ietf-add-split-horizon-authority-06.html#name-internal-only-subdomains

It's just so much easier, particularly if you are starting from scratch.


signature.asc
Description: PGP signature
-- 
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

Re: How should I configure internal and external DNS servers

[Marco]

Am 04.11.2023 15:03 schrieb Nick Tait via bind-users:

> 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?

Firewalls exist to block incoming traffic.
It is also possible to create a internal.example.org domain and only
allow queries from your own network, if you really want to hide DNS.

Security by obscurity isn't a good security concept.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Tait via bind-users]

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 

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 20:12:59 Uhr schrieb Nick Howitt via bind-users:

> I have those lines, but if I remove them, then presumably I cannot
> have internal overrides anywhere, like a hosts file would or like
> dnsmasq would?

BIND doesn't care about /etc/hosts.
If you make it authoritative for a zone, it will look up what is
exactly in that zone file.
If it isn't authoritative, it will ask another DNS server (forwarders
or hierarchy from root servers) and won't check files on your system.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

On 03/11/2023 20:07, Marco M. wrote:

Am 03.11.2023 um 19:54:32 Uhr schrieb Nick Howitt:


How do you mean remove the zone information?

In your /etc/bind are configuration files.
Look for named.conf* and find those that include zones:

zone "f.8.1.1.0.7.1.0.1.0.a.2.ip6.arpa" {
type master;
file "/etc/bind/db.f.8.1.1.0.7.1.0.1.0.a.2.ip6.arpa";
};

Those lines make it authoritative for that zone. If it isn't
authoritative for that zone, it will ask the forwarder (if
configured) or looks it up from the root servers and goes down the
hierarchy to the authoritative server (your external).


Which bits do I change and does this then leave me able to serve out
internal IPs for the FQDN's that require them?

No, if you need to server different information than your "external"
server, you need a source for that information.

That is why I advocate against using split DNS and migration to IPv6 to
only have one address for that server.
I have those lines, but if I remove them, then presumably I cannot have 
internal overrides anywhere, like a hosts file would or like dnsmasq would?-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 19:54:32 Uhr schrieb Nick Howitt:

> How do you mean remove the zone information?

In your /etc/bind are configuration files.
Look for named.conf* and find those that include zones:

zone "f.8.1.1.0.7.1.0.1.0.a.2.ip6.arpa" {
type master;
file "/etc/bind/db.f.8.1.1.0.7.1.0.1.0.a.2.ip6.arpa";
};

Those lines make it authoritative for that zone. If it isn't
authoritative for that zone, it will ask the forwarder (if
configured) or looks it up from the root servers and goes down the
hierarchy to the authoritative server (your external).

> Which bits do I change and does this then leave me able to serve out
> internal IPs for the FQDN's that require them?

No, if you need to server different information than your "external"
server, you need a source for that information.

That is why I advocate against using split DNS and migration to IPv6 to
only have one address for that server.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

On 03/11/2023 19:30, Marco M. wrote:

Am 03.11.2023 um 19:18:49 Uhr schrieb Nick Howitt via bind-users:


Can the bind-internal not be made to caching only and not
authoritative? If so, how?

Of course it can, simply remove the zone configuration, but it will
then cache the records from the authoritative server (your
"external-bind").
How do you mean remove the zone information? Which bits do I change and 
does this then leave me able to serve out internal IPs for the FQDN's 
that require them?-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 19:18:49 Uhr schrieb Nick Howitt via bind-users:

> Can the bind-internal not be made to caching only and not 
> authoritative? If so, how?

Of course it can, simply remove the zone configuration, but it will
then cache the records from the authoritative server (your
"external-bind").
-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 19:15:45 Uhr schrieb Nick Howitt via bind-users:

> You are preaching to the converted, but we have a huge mix of SLES
> 11, Ubuntu 16, 18, 20 and 22 machines + Windows Server 2016. Getting
> them all current is a long term project and it has to go through all
> sorts of customer authorisations. I am after a quick win with the
> Bind configs

Be aware that running EoL systems without security updates is a huge
security risk. Do you or your customers REALLY want that?

Second: Those operating systems support IPv6, so you can deploy it to
remove the necessity of internal and extern IPv4 split addressing.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

Unfortunately they are not separate subdomains. They are all part of the 
same domain. Can the bind-internal not be made to caching only and not 
authoritative? If so, how?


On 03/11/2023 19:01, Andrew Pavlin wrote:
Have you considered making your internal DNS servers unpublished 
secondaries for the external domain data? Just because the external 
primary DNS server is configured to allow an internal server to do 
domain transfers does not mean that internal server's identity has to be 
published in external domain NS records.


That way, only the external primary server authoritatively defines the 
external records, but the internal servers can authoritatively deliver 
those records as secondaries.


Of course, this only works if the internal and external data records are 
clearly separated in different subdomains or zones.


Andrew Pavlin

Powered by Cricket Wireless
Get Outlook for Android <https://aka.ms/AAb9ysg>

*From:* bind-users  on behalf of Nick 
Howitt via bind-users 

*Sent:* Friday, November 3, 2023 1:58:51 PM
*To:* bind-users@lists.isc.org 
*Subject:* Re: How should I configure internal and external DNS servers
On 03/11/2023 17:54, Marco M. wrote:

Am 03.11.2023 um 17:48:32 Uhr schrieb Nick Howitt via bind-users:


My problem is the use of external IP's duplicated between the
internal and external masters for some IPs/FQDNs which I want to get
rid of.

Implement IPv6 and get rid of the old IPv4 technology for internal
communication.

It is a big task, but after it is being done, many nasty stuff is gone
like NAT hairpinning or split-DNS.
Not remotely on the cards with 200+ servers and so on, I'm afraid. Some 
of the servers are too old, I think for IPv6 - SLES 11.


Really I am looking to see if it is possible to turn the internal DNS 
server, bind-internal, into a caching server and help with how to do it. 
Or not to do it if it is a bad idea.

--
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

On 03/11/2023 18:06, Marco M. wrote:

Am 03.11.2023 um 17:58:51 Uhr schrieb Nick Howitt via bind-users:


On 03/11/2023 17:54, Marco M. wrote:

Am 03.11.2023 um 17:48:32 Uhr schrieb Nick Howitt via bind-users:
  

My problem is the use of external IP's duplicated between the
internal and external masters for some IPs/FQDNs which I want to
get rid of.

Implement IPv6 and get rid of the old IPv4 technology for internal
communication.

It is a big task, but after it is being done, many nasty stuff is
gone like NAT hairpinning or split-DNS.

Not remotely on the cards with 200+ servers and so on, I'm afraid.

You have to start at some time, rest is a matter of time.


Some of the servers are too old, I think for IPv6 - SLES 11.

Already out of support. Such machines must not be connected to the
internet anymore because they are a security risk. Replace them with a
current operating system.
You are preaching to the converted, but we have a huge mix of SLES 11, 
Ubuntu 16, 18, 20 and 22 machines + Windows Server 2016. Getting them 
all current is a long term project and it has to go through all sorts of 
customer authorisations. I am after a quick win with the Bind configs

--
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

Re: How should I configure internal and external DNS servers

[Andrew Pavlin]

Have you considered making your internal DNS servers unpublished secondaries 
for the external domain data? Just because the external primary DNS server is 
configured to allow an internal server to do domain transfers does not mean 
that internal server's identity has to be published in external domain NS 
records.

That way, only the external primary server authoritatively defines the external 
records, but the internal servers can authoritatively deliver those records as 
secondaries.

Of course, this only works if the internal and external data records are 
clearly separated in different subdomains or zones.

Andrew Pavlin

Powered by Cricket Wireless
Get Outlook for Android<https://aka.ms/AAb9ysg>

From: bind-users  on behalf of Nick Howitt 
via bind-users 
Sent: Friday, November 3, 2023 1:58:51 PM
To: bind-users@lists.isc.org 
Subject: Re: How should I configure internal and external DNS servers

On 03/11/2023 17:54, Marco M. wrote:


Am 03.11.2023 um 17:48:32 Uhr schrieb Nick Howitt via bind-users:



My problem is the use of external IP's duplicated between the
internal and external masters for some IPs/FQDNs which I want to get
rid of.



Implement IPv6 and get rid of the old IPv4 technology for internal
communication.

It is a big task, but after it is being done, many nasty stuff is gone
like NAT hairpinning or split-DNS.


Not remotely on the cards with 200+ servers and so on, I'm afraid. Some of the 
servers are too old, I think for IPv6 - SLES 11.

Really I am looking to see if it is possible to turn the internal DNS server, 
bind-internal, into a caching server and help with how to do it. Or not to do 
it if it is a bad idea.
-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 17:58:51 Uhr schrieb Nick Howitt via bind-users:

> On 03/11/2023 17:54, Marco M. wrote:
> > Am 03.11.2023 um 17:48:32 Uhr schrieb Nick Howitt via bind-users:
> >  
> >> My problem is the use of external IP's duplicated between the
> >> internal and external masters for some IPs/FQDNs which I want to
> >> get rid of.  
> > Implement IPv6 and get rid of the old IPv4 technology for internal
> > communication.
> >
> > It is a big task, but after it is being done, many nasty stuff is
> > gone like NAT hairpinning or split-DNS.  
> Not remotely on the cards with 200+ servers and so on, I'm afraid.

You have to start at some time, rest is a matter of time.

> Some of the servers are too old, I think for IPv6 - SLES 11.

Already out of support. Such machines must not be connected to the
internet anymore because they are a security risk. Replace them with a
current operating system.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

On 03/11/2023 17:54, Marco M. wrote:

Am 03.11.2023 um 17:48:32 Uhr schrieb Nick Howitt via bind-users:


My problem is the use of external IP's duplicated between the
internal and external masters for some IPs/FQDNs which I want to get
rid of.

Implement IPv6 and get rid of the old IPv4 technology for internal
communication.

It is a big task, but after it is being done, many nasty stuff is gone
like NAT hairpinning or split-DNS.
Not remotely on the cards with 200+ servers and so on, I'm afraid. Some 
of the servers are too old, I think for IPv6 - SLES 11.


Really I am looking to see if it is possible to turn the internal DNS 
server, bind-internal, into a caching server and help with how to do it. 
Or not to do it if it is a bad idea.-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 17:48:32 Uhr schrieb Nick Howitt via bind-users:

> My problem is the use of external IP's duplicated between the
> internal and external masters for some IPs/FQDNs which I want to get
> rid of.

Implement IPv6 and get rid of the old IPv4 technology for internal
communication.

It is a big task, but after it is being done, many nasty stuff is gone
like NAT hairpinning or split-DNS.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

On 03/11/2023 17:17, Marco M. wrote:

Am 03.11.2023 um 15:51:32 Uhr schrieb Nick Howitt via bind-users:


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.

It seems they people who set that up didn't understand the idea of a
master and slave server.
You have one master where changes are being made and optionally many
slaves that get their zone information from that one master.
Err, no. We have two masters, one for the internal machines to use and 
one for external machines to use. The internal master has at least three 
slaves and the external master has at least 2 slaves. They are all 
authoritative.


My problem is the use of external IP's duplicated between the internal 
and external masters for some IPs/FQDNs which I want to get rid of.-- 
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

Re: How should I configure internal and external DNS servers

[Marco M.]

Am 03.11.2023 um 15:51:32 Uhr schrieb Nick Howitt via bind-users:

> 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.

It seems they people who set that up didn't understand the idea of a
master and slave server.
You have one master where changes are being made and optionally many
slaves that get their zone information from that one master.
-- 
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

Re: How should I configure internal and external DNS servers

[Nick Howitt via bind-users]

Hmm, I'll admit to only skim reading it but is seems quite complicated 
for what I was hoping for. It would be trivial if I could change the 
bind-internal machine to using dnsmasq (ugh!). Then the bind-internal 
machine would serve up anything it explicitly knew about to the internal 
clients, and anything that it didn't know about, it would automatically 
request from the internet, which would include the bind-external 
machine. Then, if I configured external IP's on bind-external only, they 
would still be returned by by bind-internal to the machines using 
bind-internal as their resolver. I was hoping I could set something like 
recursion=true in bind-internal and recursion=false on bind-external, 
only in my configs for BIND 9.9.6-P1, it is not set at all so I am not 
sure how it is configured as authoritative.


Nick

On 2023-11-03 16:01, Andrew Latham wrote:

* That sounds like a sadly normal implementation but yes you can do
better* Views is a good place to look https://kb.isc.org/docs/aa-00851
* Make sure to investigate how the company VPN services handle DNS as
it may surprise you

On Fri, Nov 3, 2023 at 9:52 AM 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
[1].
Bind-external is also set up as authoritative for example.com [1].

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 [2] 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


--

- Andrew "lathama" Latham -

Links:
--
[1] http://example.com
[2] http://demo.example.com

--
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