DNS views and zone transfers, cont
project722
project722 at gmail.com
Tue Sep 13 14:58:11 UTC 2016
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.
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
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/ec5dcd26/attachment.html>
More information about the bind-users
mailing list