Re: Question About Internal Recursive Resolvers
On 18.10.22 09:23, Bob McDonald wrote: There are no outside clients. In this example, I'm only discussing inside clients on inside DNS. The recursive resolvers that ALL inside clients connect to will seek responses from the DNS root servers AFTER determining that the response can not be determined from the internal DNS zones. There is no access provided to outside (internet centric) clients to inside DNS. The determination of known/unknown clients is via a NAC layer and further, the classification of unknown gets automatically assigned to those clients combining in through GUEST WiFi (e.g. cell phones, ipads, etc.). Most organizations with a NAC layer in place have procedures to allow unknown clients temporary access at some level (e.g. vendors, etc.). this way the situation is even easier. you can use two distinct serves for internal and wi-fi clients, where only internal server will contain internal zones. you can achieve the same effect with views, no other DNS servers are necessary -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller -- 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: Question About Internal Recursive Resolvers
Let's not overthink this. I fear that I've activated a lot of creative circuitry in individuals and provided flimsy details around my example. There are no outside clients. In this example, I'm only discussing inside clients on inside DNS. The recursive resolvers that ALL inside clients connect to will seek responses from the DNS root servers AFTER determining that the response can not be determined from the internal DNS zones. There is no access provided to outside (internet centric) clients to inside DNS. The determination of known/unknown clients is via a NAC layer and further, the classification of unknown gets automatically assigned to those clients combining in through GUEST WiFi (e.g. cell phones, ipads, etc.). Most organizations with a NAC layer in place have procedures to allow unknown clients temporary access at some level (e.g. vendors, etc.). HTH, Bob -- 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: Question About Internal Recursive Resolvers
On 14. 10. 22 18:08, Bob McDonald wrote: I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. That said, all clients would connect to recursive resolvers. The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? Access to the internal DNS zones would be controlled by location. (e.g. guest WiFi devices would NOT have access to internal DNS zones...) Recursive resolvers would allow implementation of features such as RPZ, etc. I have a better proposition for you: Use a properly delegated name like internal.example.com, where example.com is a domain you own. This way you don't need to mess with manual configuration for stub zones or hints and keep them updated. ACLs can be applied on auths as needed to limit access to the "internal" zone from outside, but there is no technical reason why it cannot be delegated from public tree - and it will save you lots of headache. HTH. -- Petr Špaček -- 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: Question About Internal Recursive Resolvers
On 15.10.22 16:03, Bob McDonald wrote: OK, if a known client accesses DNS on the internal network, that client is pointed at a recursive resolver (e.g by DHCP). That resolver either provides access to the internal DNS zones (e.g. via stub zones) or sends the client query to the root servers on the internet. An unknown client (e.g. guest WiFi) will be given the same resolver address for its DNS server. At this point it would require ACLs to prevent that unknown client from accessing the internal DNS zones. All DNS traffic from that client would be sent to the internet. Another way to achieve that would be to have a separate set of DNS resolvers for unknown clients (resolver addresses handed out via DHCP). That's my current view of how to get things done in this case. What I'm discerning from the discussion so far is that this isn't strictly necessary. The internal DNS zones can/should reside on the recursive resolvers. The question of unknown client access to internal DNS zones is resolved (no pun intended...). bind supports views, which work like virtual DNS servers, you can define some zones only in internal views. you can even support multiple views for internal, wi-fi and external clients, where the internal clients will get recursion and see internal zones, wi-fi clients get recursion w/o seeing internal zones, and external zones only see public zones. You can separate these clients by their source IPs, without any need to configure separate servers with separate iP addresses. you may want to share dns cache between internal and wi-fi zones using attach-cache directive, and share public zones to the internal and wi-fi directives by configuring thoze zones using "in-view". RPZ COULD be implemented on ANY of the recursive DNS resolvers. note that RPZ is designed to prevent/redirect access to destinations, not to clients - it's not designed to separate clients and access to zones this way. The tsig key discussion is around its use as a method of allowing updates to internal DNS zones. Strictly hypothetical. Don't get hung up on it. Tsig is good security measure to only allow specific clients to submit updates. You can configure tsig key to belong to particular view even without having proper client IP address. Thank you all for the information. You've provided answers to my questions and have renewed my faith in geekdom. If anyone is still confused, I'd be glad to discuss this offline until we have a final solution. Then we can publish if necessary. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm -- 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: Question About Internal Recursive Resolvers
On 10/15/22 1:51 PM, Greg Choules via bind-users wrote: Hi Grant. Hi Gred, I'm quickly replying to your message. I'll reply to Matus & Fred later when I have more time for a proper reply. My understanding is this, which is almost identical to what I did in a former life: client ---recursive_query---> recursive_DNS_server ---non_recursive_query---> internal_auth/Internet where: client == laptop/phone/server running stub resolver code recursive_DNS_server == what Bob is asking about, a recursive-only DNS server internal_auth == the other component, an authoritative-only DNS server ACK I that's the topology I had in my mental map. Separation of internal and external clients - preventing external ones from accessing internal names - is easily achieved with a couple of views, such as this: I /absolutely/ agree with you. However "views" is /non-default/. -- To reflect Bob's original message. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Question About Internal Recursive Resolvers
OK, if a known client accesses DNS on the internal network, that client is pointed at a recursive resolver (e.g by DHCP). That resolver either provides access to the internal DNS zones (e.g. via stub zones) or sends the client query to the root servers on the internet. An unknown client (e.g. guest WiFi) will be given the same resolver address for its DNS server. At this point it would require ACLs to prevent that unknown client from accessing the internal DNS zones. All DNS traffic from that client would be sent to the internet. Another way to achieve that would be to have a separate set of DNS resolvers for unknown clients (resolver addresses handed out via DHCP). That's my current view of how to get things done in this case. What I'm discerning from the discussion so far is that this isn't strictly necessary. The internal DNS zones can/should reside on the recursive resolvers. The question of unknown client access to internal DNS zones is resolved (no pun intended...). RPZ COULD be implemented on ANY of the recursive DNS resolvers. The tsig key discussion is around its use as a method of allowing updates to internal DNS zones. Strictly hypothetical. Don't get hung up on it. Thank you all for the information. You've provided answers to my questions and have renewed my faith in geekdom. If anyone is still confused, I'd be glad to discuss this offline until we have a final solution. Then we can publish if necessary. Bob -- 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: Question About Internal Recursive Resolvers
Hi Grant.
My understanding is this, which is almost identical to what I did in a
former life:
client ---recursive_query---> recursive_DNS_server
---non_recursive_query---> internal_auth/Internet
where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is asking about, a recursive-only DNS
server
internal_auth == the other component, an authoritative-only DNS server
Separation of internal and external clients - preventing external ones from
accessing internal names - is easily achieved with a couple of views, such
as this:
view "external" {
match-clients { address_match_list }; # the set of all possible
addresses that external clients may be given.
match-destinations { address_match_list }; # the address(es) given to
external clients for their DNS service.
...
};
view "internal" {
# there is no `match clients`. Any client not already match by the
"external" view potentially has access to this view, if they target the
correct service address(es).
match-destinations { address_match_list }; # the address(es) given to
internal clients for their DNS service. Different from the one(s) given to
external clients.
attach-cache "external"; # internal clients have access to records that
have already been cached due to queries made by external clients.
...
};
Greg
On Sat, 15 Oct 2022 at 18:52, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
> > If you are an ISP/registry/DNS provider, it makes sense to separate
> > authoritative zones for your clients' domains, for all those cases your
> > client move their domains somewhere else without notifying you (hell,
> > they do that too often), or to be able to prepare moving domains to your
> > servers.
>
> #truth
>
> > forward zones - named sends recursive query to the primary servers
> > stub zones- named fetches NS records from primary servers and
> > uses them for resolution
> > static-stub zones - named forwards iterative (non-recursive) requests to
> > primary servers
> >
> > clients accessing any of these zones must have recursion allowed and
> > recursion must be enabled in BIND.
>
> Please clarify where recursion needs to be allowed; the BIND server
> clients are talking to and / or the back end server that BIND is talking
> to on the client's behalf.
>
> I'm not completely clear and I think it's better to ask than to assume
> incorrectly.
>
> > On 10/15/22 10:03 AM, Bob McDonald wrote:
> >> If a non-secure client (read the next sentence...) accesses the same
> >> recursive server as a regular client, it will have access to the
> >> internal zones by default.. Therefore we need to have some sort of
> >> access controls in place.
> > and THIS is exactly the reason you SHOULD put your internal zones on
> > your internal server.
>
> Sorry if I'm being particularly dense this morning, but I'm not
> following ~> understanding Bob's and Matus's statements like I want to.
>
> How does hosting the zone on an internal server provide any additional
> security? Or are you simply relying on other security mechanisms to
> prevent non-secure clients -- as Bob described them -- from accessing
> the server ~> zone?
>
> I feel like, by default -- as Bob described, any hosted zone is going to
> be accessible by any client that can query the server.
>
> With this in mind, I feel like the type of zone; primary / secondary /
> mirror / stub / static-stub / forward, makes little difference in and of
> itself. Rather, it would be dependent on global and / or per-zone
> allow-* statements to protect the server / zone(s) at the BIND
> application level.
>
> Does that make sense?
>
> What am I missing / misunderstanding?
>
> > that's why we are here.
>
> :-)
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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
Re: Question About Internal Recursive Resolvers
People do the funniest things with DNS. It's a pretty good key-value store, especially for read-heavy workloads. Maybe you update counters for "what clients in this OT environment are posting telemetry to this web server"? DNS wouldn't be a good choice for that, but Redis is. But maybe you want to query for the info with the DNS; as a bonus, DNS can offload / cache reads. On Sat, 15 Oct 2022, Grant Taylor via bind-users wrote: [...] How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. DNS is federated, meaning that a server can be both a service and a client, which means in the use case given above that the Redis instances can be distributed close to where the counters are updated; the DNS will go out and collect those counters when you query them, no need to send a constant stream of telemetry to a central location. You probably don't want those counters accessible to every dog on the internet. Some thought is necessary in deploying DNS servers so that intended clients get access. (We don't usually expect DNS clients to issue hundreds of requests per second either, but it works; you just need to give it some thought.) I assume that people have been doing variations on this sort of thing since PDPs were as common as LSD in Berkely. The usual suspects arrive: TSIG, allowed addresses, firewall rules; site-to-site VPNs; that sort of thing. Turns out RPZ is useful as a WAF equivalent, limiting the Redis keys which can be queried as well as the types of allowed queries. Here is my contribution to ensuring employment for DNS subject matter experts: * https://github.com/m3047/rkvdns -- DNS proxy for Redis * https://github.com/m3047/rkvdns_examples -- examples -- Fred Morris, internet plumber -- 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: Question About Internal Recursive Resolvers
If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. #truth On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote: forward zones - named sends recursive query to the primary servers stub zones- named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. On 15.10.22 11:50, Grant Taylor via bind-users wrote: Please clarify where recursion needs to be allowed; the BIND server clients are talking to and / or the back end server that BIND is talking to on the client's behalf. I'm not completely clear and I think it's better to ask than to assume incorrectly. recursion must be allowed on the BIND server that is supposed to forward queries from clients, and those clients need to have recursion enabled on that BIND server. the Bob mentions copnfiguring recursive server so I assume everything is already allowed, I just noted that recursion is needed for zone types above. On 10/15/22 10:03 AM, Bob McDonald wrote: If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Sorry if I'm being particularly dense this morning, but I'm not following ~> understanding Bob's and Matus's statements like I want to. How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? Company has internal/recursive servers only accessible by internal clients. If you configure internal zones on these servers, all internal clients will immediately have access to these zones, no measures needed (though possible) If you configure internal zones on separate servers, you must: - configure recursive servers to direct lookups to authoritative servers - control access to those zones on authoritative servers. so, you must take two more measures. I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. Bob describes moving internal zones to non-recursive servers. https://lists.isc.org/pipermail/bind-users/2022-October/106756.html Which requires those measures above, without obvious need, except the misunderstood principle "separate recursive and authoritative servers". With this in mind, I feel like the type of zone; primary / secondary / mirror / stub / static-stub / forward, makes little difference in and of itself. Rather, it would be dependent on global and / or per-zone allow-* statements to protect the server / zone(s) at the BIND application level. Does that make sense? What am I missing / misunderstanding? the point is to make the system simple and robust. separating DNS servers may make DNS more robust and it may make DNS less robust. Bob describes access to different zones from different clients (internal, wi-fi, ...) configured on recursive server. There's no visible gain if Bob moves internal zones to another server. However there are still some questions to this https://lists.isc.org/pipermail/bind-users/2022-October/106764.html - where/how/why is TSIG used - how is the DNS configured now, don't internal recursive servers have access to the internet now? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity... -- 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: Question About Internal Recursive Resolvers
On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote: If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. #truth forward zones - named sends recursive query to the primary servers stub zones- named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. Please clarify where recursion needs to be allowed; the BIND server clients are talking to and / or the back end server that BIND is talking to on the client's behalf. I'm not completely clear and I think it's better to ask than to assume incorrectly. On 10/15/22 10:03 AM, Bob McDonald wrote: If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Sorry if I'm being particularly dense this morning, but I'm not following ~> understanding Bob's and Matus's statements like I want to. How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. With this in mind, I feel like the type of zone; primary / secondary / mirror / stub / static-stub / forward, makes little difference in and of itself. Rather, it would be dependent on global and / or per-zone allow-* statements to protect the server / zone(s) at the BIND application level. Does that make sense? What am I missing / misunderstanding? that's why we are here. :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Question About Internal Recursive Resolvers
On 10/15/22 10:03 AM, Bob McDonald wrote: My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. I too (had) long shared -- what I'm going to retroactively call -- that over simplification. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. I don't know if the rules have become more lax so much as been clarified to indicate internal / private vs external / (semi)public servers. Semi-public in things like an ISP allows it's IP space to perform recursive queries. If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. I think the emphasis is on "by default". I also believe there are many ways to alter this default behavior. Please forgive me if my post was confusing, arrogant, or naive. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. I've found that almost everyone, myself included, tends to get invested and energetic in discussions. Sometimes even animated. But as long as we don't make anything personal and keep things at arms length, we can almost always see through the fog and help / learn from each other. By all means, feel free to dislike / disagree with things I say / do. Please ask why I do things. Please share why you think / do what you do as I'd like to learn from you. But please, for the love of $DEITY please do not perpetuate ad hominem attacks. -- Not that anyone has in this thread. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Question About Internal Recursive Resolvers
I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. why? On 15.10.22 12:03, Bob McDonald wrote: My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. This is a common misconception. Yes, it's a good idea to separate recursive servers accessed/used by your clients from authoritative servers accessed/used by whole internet. But this does NOT mean that internal/recursive servers must not, nor should not containt your internal zones, nor it means you should put your internal zones to your publicly accessible authoritative servers. If you have own zones for your own usage, exactly the same way you have recursive servers, it makes rarely sense to put them to other servers than your internal/recursive servers, just put internal zones to internal servers. If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers)> Again, my understanding is that forwarding would require recursion. Thanks for the info about stub zones etc. forward zones - named sends recursive query to the primary servers stub zones - named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. Access to the internal DNS zones would be controlled by location. if you have recursive servers in internal network, you don't need control access on auth-only servers If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Please forgive me if my post was confusing, arrogant, or naive. neither one. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. that's why we are here. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 -- 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: Question About Internal Recursive Resolvers
>>I'm thinking about redesigning an internal DNS environment. To begin >>with, all internal DNS zones would reside on non-recursive servers >>only. >why? My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. >> That said, all clients would connect to recursive resolvers. >don't they now? They do. I'm talking about a situation where an edge layer can be eliminated. Each recursive server would have access out to the internet. No forwarding would be required. >>The question is this; do I use an internal root with pointers to the >>internal zones (as well as the outside DNS world) or do I include stub >>zones to point at the non-recursive internal servers? >stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers)> Again, my understanding is that forwarding would require recursion. Thanks for the info about stub zones etc. >>Access to the internal DNS zones would be controlled by location. >if you have recursive servers in internal network, you don't need control >access on auth-only servers If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. >>(e.g. guest WiFi devices would NOT have access to internal DNS >>zones...) >> >>Recursive resolvers would allow implementation of features such as RPZ, etc. >do you need RPZ for internal zones? Since ALL recursive servers have access out to the internet, yes. Please forgive me if my post was confusing, arrogant, or naive. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. Bob -- 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: Question About Internal Recursive Resolvers
On 14.10.22 12:08, Bob McDonald wrote: I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. why? That said, all clients would connect to recursive resolvers. don't they now? The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers) Access to the internal DNS zones would be controlled by location. if you have recursive servers in internal network, you don't need control access on auth-only servers. (e.g. guest WiFi devices would NOT have access to internal DNS zones...) Recursive resolvers would allow implementation of features such as RPZ, etc. do you need RPZ for internal zones? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. LSD will make your ECS screen display 16.7 million colors -- 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: Question About Internal Recursive Resolvers
Hi Greg,Great points! I must have forgotten how messy this got :) ./John Original message From: Greg Choules Hi John.Yes, you *could* forward and that was a setup I inherited a good few years ago. The appeal is obvious: it's easy to do; just chuck queries over there and get answers.But forwarding keeps the RD bit set, meaning that the server being forwarded to should a) have recursion enabled (though it will still answer if it is authoritative anyway) and b) is now obliged to try and find an answer, so if the people who run that server happen to configure forwarding somewhere else you can potentially end up with long, ugly chains of forwarding, even loops. None of stub, static-stub or mirror do this.Just my 2p.GregOn Fri, 14 Oct 2022 at 17:38, JW λ John Woodworth wrote:Hi Bob,I've been able to do this with 'forward' zones. The config would go in the resolver but the files would not./John Original message From: Bob McDonald I'm thinking about redesigning an internal DNS environment. To beginwith, all internal DNS zones would reside on non-recursive serversonly. That said, all clients would connect to recursive resolvers.The question is this; do I use an internal root with pointers to theinternal zones (as well as the outside DNS world) or do I include stubzones to point at the non-recursive internal servers?Access to the internal DNS zones would be controlled by location.(e.g. guest WiFi devices would NOT have access to internal DNSzones...)Recursive resolvers would allow implementation of features such as RPZ, etc.Regards,Bob-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-us...@lists.isc.orghttps://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 -- 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: Question About Internal Recursive Resolvers
Hi John. Yes, you *could* forward and that was a setup I inherited a good few years ago. The appeal is obvious: it's easy to do; just chuck queries over there and get answers. But forwarding keeps the RD bit set, meaning that the server being forwarded to should a) have recursion enabled (though it will still answer if it is authoritative anyway) and b) is now obliged to try and find an answer, so if the people who run that server happen to configure forwarding somewhere else you can potentially end up with long, ugly chains of forwarding, even loops. None of stub, static-stub or mirror do this. Just my 2p. Greg On Fri, 14 Oct 2022 at 17:38, JW λ John Woodworth wrote: > Hi Bob, > > I've been able to do this with 'forward' zones. The config would go in > the resolver but the files would not. > > > /John > > Original message > From: Bob McDonald > > I'm thinking about redesigning an internal DNS environment. To begin > with, all internal DNS zones would reside on non-recursive servers > only. That said, all clients would connect to recursive resolvers. > > The question is this; do I use an internal root with pointers to the > internal zones (as well as the outside DNS world) or do I include stub > zones to point at the non-recursive internal servers? > > Access to the internal DNS zones would be controlled by location. > (e.g. guest WiFi devices would NOT have access to internal DNS > zones...) > > Recursive resolvers would allow implementation of features such as RPZ, > etc. > > Regards, > > Bob > -- > 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 > -- 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: Question About Internal Recursive Resolvers
Hi Bob,I've been able to do this with 'forward' zones. The config would go in the resolver but the files would not./John Original message From: Bob McDonald I'm thinking about redesigning an internal DNS environment. To beginwith, all internal DNS zones would reside on non-recursive serversonly. That said, all clients would connect to recursive resolvers.The question is this; do I use an internal root with pointers to theinternal zones (as well as the outside DNS world) or do I include stubzones to point at the non-recursive internal servers?Access to the internal DNS zones would be controlled by location.(e.g. guest WiFi devices would NOT have access to internal DNSzones...)Recursive resolvers would allow implementation of features such as RPZ, etc.Regards,Bob-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-us...@lists.isc.orghttps://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
Re: Question About Internal Recursive Resolvers
Hi Bob. In a previous life I did just this. Large resolvers for customers and internal users, defaulting to the Internet but with specific configuration to internal auth-only servers for private zones (I used stub but static-stub and mirror are alternatives - they each behave slightly differently). In my case these resolvers forwarded (only) to Internet-edge resolvers, which then did recursion. There were no internal roots anywhere. Essentially the idea was, treat internal resolution as specific exceptions to the general rule of "everything lives in the Internet". One note of caution is, beware DNSSEC validation. These days it is on by default, which is not necessarily a problem, even if your internal zones aren't signed. But what it does mean is that internal zones *must* be properly delegated from parent zones in the Internet, otherwise the chain of trust will be broken and validation will fail. e.g. if your registered domain in the outside world is "example.com" then a valid internal zone could be "internal.example.com". You can configure BIND to *not* validate certain zones, which is a way around it. But I'd recommend doing it right from the start, if you have the option. I hope that helps. Greg On Fri, 14 Oct 2022 at 17:08, Bob McDonald wrote: > I'm thinking about redesigning an internal DNS environment. To begin > with, all internal DNS zones would reside on non-recursive servers > only. That said, all clients would connect to recursive resolvers. > > The question is this; do I use an internal root with pointers to the > internal zones (as well as the outside DNS world) or do I include stub > zones to point at the non-recursive internal servers? > > Access to the internal DNS zones would be controlled by location. > (e.g. guest WiFi devices would NOT have access to internal DNS > zones...) > > Recursive resolvers would allow implementation of features such as RPZ, > etc. > > Regards, > > Bob > -- > 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
Question About Internal Recursive Resolvers
I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. That said, all clients would connect to recursive resolvers. The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? Access to the internal DNS zones would be controlled by location. (e.g. guest WiFi devices would NOT have access to internal DNS zones...) Recursive resolvers would allow implementation of features such as RPZ, etc. Regards, Bob -- 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
