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