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