DNS views and zone transfers
project722
project722 at gmail.com
Wed Sep 7 16:49:46 UTC 2016
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 <rharolde at umich.edu> wrote:
>
> 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/fc61385d/attachment-0001.html>
More information about the bind-users
mailing list