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 <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/daee1ea8/attachment.html>