On Wed, Sep 7, 2016 at 12:49 PM, project722 <project...@gmail.com> wrote:
> 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?
>
The "internal" and "external" keys are so that I can test both views from
anywhere with:
dig something -k key.internal
dig something -k key.external
The keys are also used if you need to do notify's or zone transfers and get
them to the right view.
127.0.0.1 is used to talk from one view to the other, so it needs to match
the external view in this case
10.0.0.0/8 are the "internal" addresses in this example.
The external view could have included the external key, but 'any' covers
that. If your match is not "any', then you would want to include the
external key and 127.0.0.1.
> 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
