Re: DNS views and zone transfers, cont

[Bob Harold]

On Tue, Sep 13, 2016 at 10:58 AM, project722  wrote:

> I have moved the new views into production, and all seems to be working
> fine. I have an "internal" view and an "external" view. I have noticed a
> few re-occuring messages in the logs of the master server that I'd like to
> suppress. Here is what I am seeing:
>
> 1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not
> set: disabling RFC 1918 empty zones: 37 Time(s)
>
> 2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)
>
> 3) zone 
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
> (master) removed: 1 Time(s)
>  zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
>  zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)
>
> For # 3 I basically see an entry for each of our reverse mapping zones,
> which are valid and I don't want them "removed" as the message states And I
> think these are related to #1. I believe I can fix #1 with the 
> "empty-zones-enable
> no;" in my external view, but I am not sure what effect it would have on
> the message generation or how it would affect zone behavior in that view.
>
> I have "empty-zones-enable yes;" in my options, and then
"empty-zones-enable no;" in the view that is forwarding.  So either define
it in every view, or define a default in the options.


> For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
> my named.conf. However it is above the options statement and I am now
> wondering if I need this defined in each view now. Also this 
> fe80::216:3eff:fe37:b866
> is not even my actual link local IP so I am not sure where/how that is
> being generated. My actual link local is
> fe80::f21f:afff:fedd:6a26/64
>
>
I have the "server ... bogus ..." statement in each view, so try it there.


> Any help is greatly appreciated.
>
> On Thu, Sep 8, 2016 at 11:33 AM, project722  wrote:
>
>> I am not seeing that but thanks for the heads up. I will keep an eye on
>> it.
>>
>> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold  wrote:
>>
>>> I changed the subject slightly, because I had to cut out a lot of the
>>> forwarded message - the list server was complaining about the size of the
>>> messages.
>>>
>>> I just found that my setup was not working completely as I expected.
>>> The view with only a few zones and forwarding to another view automatically
>>> got the "empty zones" created, so any queries in those zones did not get
>>> forwarded.  I am fixing it by adding to that view the line:
>>>empty-zones-enable no;
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:
>>>

 On Thu, Sep 8, 2016 at 9:13 AM, project722 
 wrote:

> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
> transfers. First off, what is the reasoning or benefit of allowing
> localhost to make zone transfers? Secondly, In my new view config since I
> will be using 127.0.0.1 as a forwarder, would this in any way cause a
> problem or a conflict if I was to leave the localhost IP in the ACL for
> zone transfers?
>

 I would allow 127.0.0.1 to do zone transfers for troubleshooting
 purposes, if I am on the server and want to look at a whole zone.  But it
 is not required, if you don't use it for transfers.
 Allowing zone transfers should not affect its use for forwarding, as
 far as I can see.

 --
 Bob Harold



> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:
>
>> You should change:
>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>> To:
>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>
>> The 'not' (!) won't work if it is last, they are checked in order, so
>> it needs to be first.
>>
>> --
>> Bob Harold
>>
>>
>> On Wed, Sep 7, 2016 at 3:21 PM, project722 
>> wrote:
>>
>>> I think I have found the problem. I did not need dnssec enabled
>>> after all. All this time I thought it was needed for TSIG to work. But
>>> apparently, the forwarding is working, and zone transfers are going to 
>>> the
>>> right view without it enabled.
>>>
>>> On Wed, Sep 7, 2016 at 1:15 PM, project722 
>>> wrote:
>>>
 Ok I'm with you now. I have reconfigured my servers and I cant get
 the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
 sure
 in the options stanza to set it to a listen IP. I have tried several
 different variations of this method and all end up with SERVFAIL's 
 using
 dig from a client that gets the "internal" view. Here is my config.

 acl internal {
 192.168.254.0/23; // corpnet
 };

Re: DNS views and zone transfers, cont

[project722]

I have moved the new views into production, and all seems to be working
fine. I have an "internal" view and an "external" view. I have noticed a
few re-occuring messages in the logs of the master server that I'd like to
suppress. Here is what I am seeing:

1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not set:
disabling RFC 1918 empty zones: 37 Time(s)

2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)

3) zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
(master) removed: 1 Time(s)
 zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
 zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)

For # 3 I basically see an entry for each of our reverse mapping zones,
which are valid and I don't want them "removed" as the message states And I
think these are related to #1. I believe I can fix #1 with the
"empty-zones-enable
no;" in my external view, but I am not sure what effect it would have on
the message generation or how it would affect zone behavior in that view.

For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
my named.conf. However it is above the options statement and I am now
wondering if I need this defined in each view now. Also this
fe80::216:3eff:fe37:b866
is not even my actual link local IP so I am not sure where/how that is
being generated. My actual link local is
fe80::f21f:afff:fedd:6a26/64

Any help is greatly appreciated.

On Thu, Sep 8, 2016 at 11:33 AM, project722  wrote:

> I am not seeing that but thanks for the heads up. I will keep an eye on
> it.
>
> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold  wrote:
>
>> I changed the subject slightly, because I had to cut out a lot of the
>> forwarded message - the list server was complaining about the size of the
>> messages.
>>
>> I just found that my setup was not working completely as I expected.  The
>> view with only a few zones and forwarding to another view automatically got
>> the "empty zones" created, so any queries in those zones did not get
>> forwarded.  I am fixing it by adding to that view the line:
>>empty-zones-enable no;
>>
>> --
>> Bob Harold
>>
>>
>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:
>>
>>>
>>> On Thu, Sep 8, 2016 at 9:13 AM, project722  wrote:
>>>
 Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
 transfers. First off, what is the reasoning or benefit of allowing
 localhost to make zone transfers? Secondly, In my new view config since I
 will be using 127.0.0.1 as a forwarder, would this in any way cause a
 problem or a conflict if I was to leave the localhost IP in the ACL for
 zone transfers?

>>>
>>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>>> purposes, if I am on the server and want to look at a whole zone.  But it
>>> is not required, if you don't use it for transfers.
>>> Allowing zone transfers should not affect its use for forwarding, as far
>>> as I can see.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>>
 On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:

> You should change:
>   match-clients { internal; key tsigkey; !key tsigkeyext;
> To:
>   match-clients { !key tsigkeyext; internal; key tsigkey;
>
> The 'not' (!) won't work if it is last, they are checked in order, so
> it needs to be first.
>
> --
> Bob Harold
>
>
> On Wed, Sep 7, 2016 at 3:21 PM, project722 
> wrote:
>
>> I think I have found the problem. I did not need dnssec enabled after
>> all. All this time I thought it was needed for TSIG to work. But
>> apparently, the forwarding is working, and zone transfers are going to 
>> the
>> right view without it enabled.
>>
>> On Wed, Sep 7, 2016 at 1:15 PM, project722 
>> wrote:
>>
>>> Ok I'm with you now. I have reconfigured my servers and I cant get
>>> the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
>>> sure
>>> in the options stanza to set it to a listen IP. I have tried several
>>> different variations of this method and all end up with SERVFAIL's using
>>> dig from a client that gets the "internal" view. Here is my config.
>>>
>>> acl internal {
>>> 192.168.254.0/23; // corpnet
>>> };
>>>
>>> acl external {
>>> 192.168.155.0/24;
>>> 192.168.160.0/24;
>>> };
>>>
>>> options {
>>> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master
>>> DNS Servers IP
>>> directory   "/var/named";
>>> dump-file   "/var/named/data/cache_dump.db";
>>> statistics-file "/var/named/data/named.stats";
>>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>>> allow-query{ 

Re: DNS views and zone transfers, cont

[project722]

I am not seeing that but thanks for the heads up. I will keep an eye on it.

On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold  wrote:

> I changed the subject slightly, because I had to cut out a lot of the
> forwarded message - the list server was complaining about the size of the
> messages.
>
> I just found that my setup was not working completely as I expected.  The
> view with only a few zones and forwarding to another view automatically got
> the "empty zones" created, so any queries in those zones did not get
> forwarded.  I am fixing it by adding to that view the line:
>empty-zones-enable no;
>
> --
> Bob Harold
>
>
> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:
>
>>
>> On Thu, Sep 8, 2016 at 9:13 AM, project722  wrote:
>>
>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>> transfers. First off, what is the reasoning or benefit of allowing
>>> localhost to make zone transfers? Secondly, In my new view config since I
>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>> zone transfers?
>>>
>>
>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>> purposes, if I am on the server and want to look at a whole zone.  But it
>> is not required, if you don't use it for transfers.
>> Allowing zone transfers should not affect its use for forwarding, as far
>> as I can see.
>>
>> --
>> Bob Harold
>>
>>
>>
>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:
>>>
 You should change:
   match-clients { internal; key tsigkey; !key tsigkeyext;
 To:
   match-clients { !key tsigkeyext; internal; key tsigkey;

 The 'not' (!) won't work if it is last, they are checked in order, so
 it needs to be first.

 --
 Bob Harold


 On Wed, Sep 7, 2016 at 3:21 PM, project722 
 wrote:

> I think I have found the problem. I did not need dnssec enabled after
> all. All this time I thought it was needed for TSIG to work. But
> apparently, the forwarding is working, and zone transfers are going to the
> right view without it enabled.
>
> On Wed, Sep 7, 2016 at 1:15 PM, project722 
> wrote:
>
>> Ok I'm with you now. I have reconfigured my servers and I cant get
>> the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
>> sure
>> in the options stanza to set it to a listen IP. I have tried several
>> different variations of this method and all end up with SERVFAIL's using
>> dig from a client that gets the "internal" view. Here is my config.
>>
>> acl internal {
>> 192.168.254.0/23; // corpnet
>> };
>>
>> acl external {
>> 192.168.155.0/24;
>> 192.168.160.0/24;
>> };
>>
>> options {
>> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master
>> DNS Servers IP
>> directory   "/var/named";
>> dump-file   "/var/named/data/cache_dump.db";
>> statistics-file "/var/named/data/named.stats";
>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>> allow-query{ internal; external; };
>> dnssec-enable yes;
>> dnssec-validation auto;
>> dnssec-lookaside auto;
>> zone-statistics yes;
>>
>> /* Path to ISC DLV key */
>> bindkeys-file "/etc/named.iscdlv.key";
>>
>> managed-keys-directory "/var/named/dynamic";
>>
>> };
>>
>> key "tsigkey" {
>>  algorithm HMAC-SHA512;
>> secret "x";
>> };
>>
>> key "tsigkeyext" {
>> algorithm HMAC-SHA512;
>> secret "xx";
>> };
>>
>> // Start internal view
>>
>> view "corpnet" {
>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>> };
>>
>>   //IP of slave server
>>   server 192.168.155.77 {
>>   keys { tsigkey; };
>> };
>>
>>   also-notify {
>>   192.168.155.77;
>> };
>>
>>   zone "example.com" IN {   //this zone has one zone file per
>> view
>>   type master;
>>   file "/var/named/db.examplein.com";
>>   allow-query { internal; };
>>   allow-transfer { key tsigkey; };
>> };
>>
>>   forwarders {
>>   // forward to external view
>>   127.0.0.1;
>> };
>>
>>   forward only;
>>
>>   include "/etc/named.rfc1912.zones";
>>   include "/etc/named.root.key";
>> };
>>
>> // Start external view
>>
>> view "external" {
>>   match-clients { any; 127.0.0.1; };
>>
>>   //IP of slave server
>>   server 192.168.155.77 {
>>   

Re: DNS views and zone transfers, cont

[Bob Harold]

I changed the subject slightly, because I had to cut out a lot of the
forwarded message - the list server was complaining about the size of the
messages.

I just found that my setup was not working completely as I expected.  The
view with only a few zones and forwarding to another view automatically got
the "empty zones" created, so any queries in those zones did not get
forwarded.  I am fixing it by adding to that view the line:
   empty-zones-enable no;

-- 
Bob Harold


On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:

>
> On Thu, Sep 8, 2016 at 9:13 AM, project722  wrote:
>
>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>> transfers. First off, what is the reasoning or benefit of allowing
>> localhost to make zone transfers? Secondly, In my new view config since I
>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>> problem or a conflict if I was to leave the localhost IP in the ACL for
>> zone transfers?
>>
>
> I would allow 127.0.0.1 to do zone transfers for troubleshooting purposes,
> if I am on the server and want to look at a whole zone.  But it is not
> required, if you don't use it for transfers.
> Allowing zone transfers should not affect its use for forwarding, as far
> as I can see.
>
> --
> Bob Harold
>
>
>
>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:
>>
>>> You should change:
>>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>>> To:
>>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>>
>>> The 'not' (!) won't work if it is last, they are checked in order, so it
>>> needs to be first.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Wed, Sep 7, 2016 at 3:21 PM, project722  wrote:
>>>
 I think I have found the problem. I did not need dnssec enabled after
 all. All this time I thought it was needed for TSIG to work. But
 apparently, the forwarding is working, and zone transfers are going to the
 right view without it enabled.

 On Wed, Sep 7, 2016 at 1:15 PM, project722 
 wrote:

> Ok I'm with you now. I have reconfigured my servers and I cant get the
> forwarding to work. Since 127.0.0.1 is forwarding request, I made sure in
> the options stanza to set it to a listen IP. I have tried several 
> different
> variations of this method and all end up with SERVFAIL's using dig from a
> client that gets the "internal" view. Here is my config.
>
> acl internal {
> 192.168.254.0/23; // corpnet
> };
>
> acl external {
> 192.168.155.0/24;
> 192.168.160.0/24;
> };
>
> options {
> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master DNS
> Servers IP
> directory   "/var/named";
> dump-file   "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named.stats";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query{ internal; external; };
> dnssec-enable yes;
> dnssec-validation auto;
> dnssec-lookaside auto;
> zone-statistics yes;
>
> /* Path to ISC DLV key */
> bindkeys-file "/etc/named.iscdlv.key";
>
> managed-keys-directory "/var/named/dynamic";
>
> };
>
> key "tsigkey" {
>  algorithm HMAC-SHA512;
> secret "x";
> };
>
> key "tsigkeyext" {
> algorithm HMAC-SHA512;
> secret "xx";
> };
>
> // Start internal view
>
> view "corpnet" {
>   match-clients { internal; key tsigkey; !key tsigkeyext;
> };
>
>   //IP of slave server
>   server 192.168.155.77 {
>   keys { tsigkey; };
> };
>
>   also-notify {
>   192.168.155.77;
> };
>
>   zone "example.com" IN {   //this zone has one zone file per view
>   type master;
>   file "/var/named/db.examplein.com";
>   allow-query { internal; };
>   allow-transfer { key tsigkey; };
> };
>
>   forwarders {
>   // forward to external view
>   127.0.0.1;
> };
>
>   forward only;
>
>   include "/etc/named.rfc1912.zones";
>   include "/etc/named.root.key";
> };
>
> // Start external view
>
> view "external" {
>   match-clients { any; 127.0.0.1; };
>
>   //IP of slave server
>   server 192.168.155.77 {
>   keys { tsigkeyext; };
> };
>
>also-notify {
>   192.168.155.77;
> };
>
> zone "." IN {
> type hint;
> file "named.ca";
> };
>
> zone"testdns.net" IN {
> type master;
> file "db.testdns.net-ext";
> 

Re: DNS views and zone transfers

[Bob Harold]

On Wed, Sep 7, 2016 at 12:49 PM, project722  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  wrote:
>
>>
>> On Wed, Sep 7, 2016 at 11:37 AM, project722  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  wrote:
>>>

 On Tue, Sep 6, 2016 at 5:23 PM, project722 
 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 
> wrote:
>
>>
>> On Thu, Aug 25, 2016 at 12:56 PM, project722 
>> 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 

Re: DNS views and zone transfers

[project722]

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  wrote:

>
> On Wed, Sep 7, 2016 at 11:37 AM, project722  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  wrote:
>>
>>>
>>> On Tue, Sep 6, 2016 at 5:23 PM, project722  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  wrote:

>
> On Thu, Aug 25, 2016 at 12:56 PM, project722 
> 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
>> 

Re: DNS views and zone transfers

[Bob Harold]

On Wed, Sep 7, 2016 at 12:34 PM, /dev/rob0  wrote:

> On Wed, Sep 07, 2016 at 11:48:54AM -0400, Bob Harold wrote:
> > On Wed, Sep 7, 2016 at 11:37 AM, project722 
> 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)
>
> "New" is fair to say, if you call BIND 9.10 "new".  OTOH it is
> unfair/wrong to call it "experimental".  9.10 has been in stable
> release form for quite some time now, and there have been no problems
> with the in-view zone feature, AFAIK.


My apologies.  You are correct, it is just not fossilized enough to be the
default in most Linux distros.


> > > On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold  wrote:
> > >
> > >>
> > >> On Tue, Sep 6, 2016 at 5:23 PM, project722 
> wrote:
>
> snip
> > >> 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;
>
> I have never thought to try this, but I would not expect it to work.
> Does it?


It works, and avoids having extra copies of the zones on disk and in memory
(I don't have 9.10).  Downsides are the caching in both views, and query
logging (if enabled) logs it twice.

> >> };
> > >> 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";
> > >> };
> > >> };
>
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
>
>
___
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

Re: DNS views and zone transfers

[/dev/rob0]

On Wed, Sep 07, 2016 at 11:48:54AM -0400, Bob Harold wrote:
> On Wed, Sep 7, 2016 at 11:37 AM, project722  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)

"New" is fair to say, if you call BIND 9.10 "new".  OTOH it is 
unfair/wrong to call it "experimental".  9.10 has been in stable 
release form for quite some time now, and there have been no problems 
with the in-view zone feature, AFAIK.

> > On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold  wrote:
> >
> >>
> >> On Tue, Sep 6, 2016 at 5:23 PM, project722  wrote:

snip
> >> 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;

I have never thought to try this, but I would not expect it to work.  
Does it?

> >> };
> >> 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";
> >> };
> >> };

-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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

Re: DNS views and zone transfers

[Bob Harold]

On Wed, Sep 7, 2016 at 11:37 AM, project722  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  wrote:
>
>>
>> On Tue, Sep 6, 2016 at 5:23 PM, project722  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  wrote:
>>>

 On Thu, Aug 25, 2016 at 12:56 PM, project722 
 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 

Re: DNS views and zone transfers

[project722]

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  wrote:

>
> On Tue, Sep 6, 2016 at 5:23 PM, project722  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  wrote:
>>
>>>
>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 
>>> 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 

Re: DNS views and zone transfers

[Bob Harold]

On Tue, Sep 6, 2016 at 5:23 PM, project722  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  wrote:
>
>>
>> On Thu, Aug 25, 2016 at 12:56 PM, project722 
>> 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 

Re: DNS views and zone transfers

[Matus UHLAR - fantomas]

On 06.09.16 16:23, project722 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?


in think "in-view" statemend in BIND 9.10 is what you search for.


view internal {

  match clients - internal;

zone - example.org

};

view external {

   match clients - external {

zone example.org {
};

zone example.com {
};

};


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
___
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

Re: DNS views and zone transfers

[project722]

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  wrote:

>
> On Thu, Aug 25, 2016 at 12:56 PM, project722  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
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list

Re: DNS views and zone transfers

[Bob Harold]

On Thu, Aug 25, 2016 at 12:56 PM, project722  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
___
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

DNS views and zone transfers

[project722]

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.

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.

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?
___
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