DNS views and zone transfers

[Bob Harold]

On Wed, Sep 7, 2016 at 11:37 AM, project722 <project722 at 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 <rharolde at umich.edu> wrote:
>
>>
>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project722 at 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 <rharolde at umich.edu> wrote:
>>>
>>>>
>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project722 at 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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160907/f61a265f/attachment.html>