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