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 <rharolde at 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 <rharolde at umich.edu> wrote:
>
>>
>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project722 at 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 <rharolde at 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 <project722 at 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 <project722 at 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";
>>>>>> };
>>>>>>
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160908/2c64e645/attachment-0001.html>