Re: DNS views and zone transfers, cont
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
};
acl external {
192.168.155.0/24;
192.168.160.0/24;
};
options {
listen-on port 53 { 192.16
Re: DNS views and zone transfers, cont
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{ internal; external; };
>>> dnssec-enable yes;
>>> dnssec-validation auto;
>>> dnssec-lookaside auto;
>>>
Re: DNS views and zone transfers, cont
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 {
>> keys { tsigkeyext; };
>> };
>>
>>also-notify {
>> 192.168.155.77;
>> };
>>
>>
Re: DNS views and zone transfers, cont
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";
> allow-query { any; 127.0.0.1; };
> allow-transfer { key tsigkeyext; ext_ns; };
> };
>>
