DNS views and zone transfers, cont
Bob Harold
rharolde at umich.edu
Thu Sep 8 15:14:48 UTC 2016
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>
More information about the bind-users
mailing list