Bob, I have few questions regarding your sample config. First off it is slightly different than mine, which does work BTW at least in a lab environment. In your internal view what is the purpose of having this line:
// this list must not match 127.0.0.1 !key "external"; // use this key to test the external view 10.0.0.0/8; Why use 127.0.0.1 and what is the 10.0.0.0/8 block for? I also noticed you did not include the external key indie the external view. Why is that? On Wed, Sep 7, 2016 at 10:48 AM, Bob Harold <rharo...@umich.edu> wrote: > > On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote: > >> Thanks Bob, I will look into this. Do you know if the forwarders feature >> is supported in Bind 9.8.2? >> >> > Yes, forwarders is an old and stable feature. > > ("in-view" is new and experimental) > > -- > Bob Harold > > >> On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote: >> >>> >>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote: >>> >>>> I'm interested in the "view forwarding" method. I'm only setting up >>>> views to resolve a split DNS issue with one domain. I'd like to have that >>>> one zone/domain in my internal view and then if the source IP requests info >>>> for any other zone forward that to my external view. To me this sounds like >>>> a whole lot less work. Do you have any specifics on how I would go about >>>> setting that up or can you point me in the direction where I can get info >>>> on setting that up? Ideally, I'd want my "internal" clients to still find >>>> example.com even if the internal view only had example.org in it. >>>> Something like this but how do I incorporate the forwarding? >>>> >>>> view internal { >>>> >>>> match clients - internal; >>>> >>>> zone - example.org >>>> >>>> }; >>>> >>>> view external { >>>> >>>> match clients - external { >>>> >>>> zone example.org { >>>> }; >>>> >>>> zone example.com { >>>> }; >>>> >>>> }; >>>> >>>> >>>> >>>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote: >>>> >>>>> >>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com> >>>>> wrote: >>>>> >>>>>> I have successfully setup TSIG keys for "views" using a DNS >>>>>> master/server pair. Zone transfers are working as expected between the 2 >>>>>> servers for each view. Before we go live into production with this I need >>>>>> some clarification on a couple things. Our prod servers are also allowing >>>>>> zone transfers to a few other servers besides the slave server. We have >>>>>> an >>>>>> acl setup that looks similar to this: >>>>>> >>>>>> other_xfer_allowed_ns { >>>>>> x.x.x.x; // This is our Secondary DNS server >>>>>> 127.0.0.1; // localhost can make zone transfers >>>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers >>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers >>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers >>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers >>>>>> }; // end of "other_xfer_allowed" ACL >>>>>> >>>>>> And in the "allow transfer" statement we have included that ACL. My >>>>>> question is: >>>>>> >>>>>> Now that we are using TSIG, will I need to get with the admins of all >>>>>> these other servers and provide them my TSIG key so they can request zone >>>>>> transfers? I would think somehting like that needs to be done since it >>>>>> was >>>>>> required to be configured on slave server, but I am not sure. >>>>>> >>>>> >>>>> No, if you allowed the IP range in your ACL, they don't need the TSIG >>>>> key. >>>>> It might be more secure to hand out TSIG keys and remove the IP ranges >>>>> from the ACL, so only the TSIG key will allow transfers, since IP >>>>> addresses >>>>> are easier to spoof, but since a zone transfer requires TCP, spoofing is >>>>> not likely. >>>>> >>>>> The TSIG key was required on the slave in order to get the right view, >>>>> if I remember correctly. >>>>> >>>>> >>>>>> >>>>>> Next, >>>>>> >>>>>> I setup views so that clients on the "internal" network when >>>>>> requesting a record would be presented with different records than >>>>>> clients >>>>>> on the outside. And at the moment there is only one zone that is required >>>>>> to have different records. However, It is my understanding that since >>>>>> views >>>>>> are based off source IP's, if I was to ONLY include that one zone in my >>>>>> "internal" view, if a record was requested for another zone from that >>>>>> same >>>>>> IP, they would probably get an nxdomain answer since that IP is limited >>>>>> to >>>>>> that one view. >>>>>> >>>>>> So, my question is, will I need to include all zones in both views so >>>>>> that all clients can get results, even though I would only have (at the >>>>>> moment) one zone that points to two different zone files? All others in >>>>>> both views would point to the same zone file, unless of course there is >>>>>> another zone we need to present a different view to for internal clients. >>>>>> >>>>> >>>>> You have a few choices: >>>>> - Copies of zones in both views. More memory used, more zone >>>>> transfers, but probably safest and best performance. This is what I do. >>>>> The zones in the two views will need to be in separate files, if they are >>>>> "slave" zones, otherwise Bind will get confused and complain, because it >>>>> does not realize that two different views are trying to write the same >>>>> file. >>>>> - One view could 'forward' to the other view for zones it does not >>>>> have. (Doubles the query logging, if you have that turned on.) >>>>> - Views could do normal recursion for some zones if they can reach the >>>>> servers listed in the NS records and get the info from there. >>>>> >>>>> >>>>>> >>>>>> Now, last question. >>>>>> >>>>>> I have a concern about the allow-query statement. On our production >>>>>> server we have an ACL list we'll call it "trusted". >>>>>> We have an allow query statement in the global options to only allow >>>>>> queries from IP's in the trusted ACL. However every one of our zone >>>>>> entries >>>>>> in the conf file also has an "allow-query { any; }; statement. Doesn't >>>>>> that >>>>>> defeat the purpose of have a "trusted" ACL for queries? Is this bad >>>>>> design? >>>>>> >>>>> >>>>> Seems like the 'any' would override the 'trusted'. Probably not what >>>>> you wanted. >>>>> >>>>> -- >>>>> Bob Harold >>>>> >>>>> >>>> >>> Here is the basic structure: >>> >>> view "internal" { >>> match-clients { >>> // this list must not match 127.0.0.1 >>> !key "external"; // use this key to test the external >>> view >>> 10.0.0.0/8; >>> key "internal"; // use this key to test the internal >>> view >>> }; >>> zone "itd.umich.edu" { // this zone is different in the two >>> views >>> type master; >>> file "internal/itd.umich.edu"; >>> }; >>> forwarders { >>> // forward to external view >>> 127.0.0.1; >>> }; >>> forward only; // optional >>> }; >>> view "external" { >>> match-clients { >>> // this list must match 127.0.0.1 >>> any; >>> }; >>> zone "itd.umich.edu" { // this zone is different in the two >>> views >>> type master; >>> file "external/itd.umich.edu"; >>> }; >>> zone "10.in-addr.arpa" { // all other zones will be seen by >>> everyone >>> type master; >>> file "external/arpa.in-addr.10"; >>> }; >>> zone "umich.edu" { >>> type master; >>> file "external/com.umich"; >>> }; >>> }; >>> >>> -- >>> Bob Harold >>> >>> >>> >>> >> >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users