Thanks Bob, I will look into this. Do you know if the forwarders feature is
supported in Bind 9.8.2?
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
