On Tue, Sep 13, 2016 at 10:58 AM, project722 <project...@gmail.com> 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 <project...@gmail.com> 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 <rharo...@umich.edu> 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 <rharo...@umich.edu> wrote: >>> >>>> >>>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> >>>> 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 <rharo...@umich.edu> 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 <project...@gmail.com> >>>>>> 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 <project...@gmail.com> >>>>>>> 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 "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; >>>>>>>> }; >>>>>>>> >>>>>>>> key "tsigkeyext" { >>>>>>>> algorithm HMAC-SHA512; >>>>>>>> secret "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; >>>>>>>> }; >>>>>>>> >>>>>>>> // 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; }; >>>>>>>> }; >>>>>>>> >>>>>>>> zone"example.com" IN { //this zone has one zone file >>>>>>>> per view >>>>>>>> type master; >>>>>>>> file "/var/named/db.exampleout.com"; >>>>>>>> allow-query { any; 127.0.0.1; }; >>>>>>>> allow-transfer { key tsigkeyext; ext_ns; }; >>>>>>>> }; >>>>>>>> include "/etc/named.rfc1912.zones"; >>>>>>>> include "/etc/named.root.key"; >>>>>>>> }; >>>>>>>> >>>>>>>> >>>>>>>> >> >
_______________________________________________ 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