DNS views and zone transfers, cont
Bob Harold
rharolde at umich.edu
Tue Sep 13 20:26:20 UTC 2016
On Tue, Sep 13, 2016 at 10:58 AM, project722 <project722 at 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 <project722 at 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 <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/20160913/fcc723d2/attachment-0001.html>
More information about the bind-users
mailing list