Re: Bind9 Container Error
在 2021年1月9日 +0800 AM3:14，Juarez Souza Junior ，写道： > Hi All! > > I'm trying to run Bind9 container but the these errors are happening: > > 08-Jan-2021 19:08:54.217 running as: named -g -c /etc/bind/named.conf -u bind > 08-Jan-2021 19:08:54.217 compiled by GCC 9.3.0 > 08-Jan-2021 19:08:54.217 compiled with OpenSSL version: OpenSSL 1.1.1f 31 > Mar 2020 > 08-Jan-2021 19:08:54.217 linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar > 2020 > 08-Jan-2021 19:08:54.217 compiled with libxml2 version: 2.9.10 > 08-Jan-2021 19:08:54.217 linked to libxml2 version: 20910 > 08-Jan-2021 19:08:54.217 compiled with json-c version: 0.13.1 > 08-Jan-2021 19:08:54.217 linked to json-c version: 0.13.1 > 08-Jan-2021 19:08:54.217 compiled with zlib version: 1.2.11 > 08-Jan-2021 19:08:54.217 linked to zlib version: 1.2.11 > 08-Jan-2021 19:08:54.217 > 08-Jan-2021 19:08:54.217 BIND 9 is maintained by Internet Systems Consortium, > 08-Jan-2021 19:08:54.217 Inc. (ISC), a non-profit 501(c)(3) public-benefit > 08-Jan-2021 19:08:54.217 corporation. Support and training for BIND 9 are > 08-Jan-2021 19:08:54.217 available at https://www.isc.org/support > 08-Jan-2021 19:08:54.217 > 08-Jan-2021 19:08:54.217 found 4 CPUs, using 4 worker threads > 08-Jan-2021 19:08:54.217 using 4 UDP listeners per interface > 08-Jan-2021 19:08:54.221 using up to 21000 sockets > 08-Jan-2021 19:08:54.225 loading configuration from '/etc/bind/named.conf' > 08-Jan-2021 19:08:54.225 directory '/var/cache/bind' is not writable It seems that this directory is not writable. Did you have checked the '/etc/bind/named.conf’ config file yet? It may find some clues. > 08-Jan-2021 19:08:54.225 /etc/bind/named.conf.options:7: parsing failed: > permission denied > 08-Jan-2021 19:08:54.229 loading configuration: permission denied > 08-Jan-2021 19:08:54.229 exiting (due to fatal error) > I've already checked the permissions and seems to be ok. > > I'm using this line command to run: > docker run --name=bind_test --restart=always --publish 192.168.56.1:53:53/udp > --publish 192.168.56.1:53:53/tcp --publish 127.0.0.1:953:953/tcp -v > /var/lib/bind9-data/etc/bind:/etc/bind -v > /var/lib/bind9-data/var/cache/bind:/var/cache/bind:Z -v > /var/lib/bind9-data/var/lib/bind:/var/lib/bind:Z -v > /var/lib/bind9-data/var/log:/var/log:Z internetsystemsconsortium/bind9:9.16 > > Could someone give me some help? > > -- > Regards, > > Juarez > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamic update rejected within a view
在 2020年7月14日 +0800 PM9:06，Per Weisteen ，写道：
> Hi
>
> I've a BIND setup with my ISP with two views, one external and one internal.
> At the same time I also need to be able to do a dynamic update from some
> addresses within the internal range. This worked ok before I had to define my
> two views.
>
> I'd be very grateful if someone could suggest what I'm doing wrong. My ISP is
> running BIND 9.11.4.
>
> Due to the ISPs need to have control over the BIND setup I'm just allowed to
> add my config via include files.
>
>
> Zones.mydomains.config file contains:
> include "keys/mydomains-keys.conf";
> include "keys/zone1-keys.conf";
> include "keys/zone2-keys.conf";
> acl external { 10.222.33.0/18; 10.222.44.0/18; };
> acl internal { 10.11.0.0/16; 10.12.0.0/16; };
> //
> // zone1 and zone2 keys used to ensure correct zone transfer from slave
> //
> view "external-sites" {
> match-clients { !key zone2.key; key zone1.key; external; };
> zone "aa.example.net" {
> type master;
> file "zones.master/aa-view1.example.net";
> notify explicit;
> also-notify { 10.12.143.56 key zone1.key; };
> update-policy {
> grant "ext-update.key." name web.aa.example.net. CNAME;
> };
> };
> include "zones.common.config.view1";
> }; // End view "external-sites"
> view "internal-sites" {
> match-clients { !key zone1.key; key zone2.key; internal; localhost; };
> zone "aa.example.net" {
> type master;
> file "zones.master/aa-view2.example.net";
> notify explicit;
> also-notify { 10.12.143.56 key zone2.key; };
> update-policy {
> grant "int-update.key." name web.aa.example.net. CNAME;
> };
> };
> include "zones.common.config.view2";
> }; // End view "grus-zone2"
> view "default" {
> match-clients { any; };
> include "zones.common.config.view2";
> }; // End view "default"
> mydomains-keys.conf file contains :
> key ext-update.key. {
> algorithm HMAC-SHA512;
> secret "secret2";
> };
> key int-update.key. {
> algorithm HMAC-SHA512;
> secret "secret3";
> };
> Error message in /var/log/named/named.log is :
>
> 10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30
> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone
> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
> 10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30
> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone
> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
>
It seems that you have used a key named arc-zone2.key for updating but only
allow int-update.key for updating in configuration?
> --
> Best regards,
> Per Weisteen
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Zhiyong Cheng
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS_RRL_MAX_RATE defines 1000
在 2020年7月10日 +0800 AM2:11，Tony Finch ，写道： > Zhiyong Cheng wrote: > > > > We are using named cluster in our internal network as the authoritative > > DNS. So there are no cache servers between clients and named cluster. > > Maybe we should add one but it is just another story. > > Sorry, I wasn't completely clear: I was not saying that your authoritative > servers should have a cache. I was saying that all the legitimate clients > of your servers (the resolvers at ISPs areound the Internet) have caches. > All of these authoritative servers are only serve for our private clients. So there won't have ISPs' resolvers. I read the Bv9ARM again and noticed a hint in it: This mechanism is intended for authoritative DNS servers. It can be used on ecursive servers but can slow applications such as SMTP servers (mail receivers) and HTTP clients (web browsers) that repeatedly request the same domains. When possible, closing "open" recursive servers is better. So it implies that I just should not use RRL in my authoritative servers. Because all clients in my IDC internal queries my authoritative servers directly. But RRL is not for this scenes. > > To my mind the RRL should not limit queries with different qnames from > > the same client. So is it my misunderstanding or wrong config? > > If you are querying for nonexistent names then RRL will treat the NXDOMAIN > responses as equivalent, so it will rate-limit them. RRL limits responses, > not queries. You can configure a different `nxdomains-per-second` limit if > you want. That’s it! All of my queries are treated as equivalent. Thanks for your patience :) > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Rockall, Malin: Northwest 4 or 5. Moderate. Showers. Good. Zhiyong Cheng ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS_RRL_MAX_RATE defines 1000
Thanks for this reply : ) We are using named cluster in our internal network as the authoritative DNS. So there are no cache servers between clients and named cluster. Maybe we should add one but it is just another story. There was a strange thing when I tested RRL using queryperf. I generated 1 qnames to test.txt and every qname queried once. The queryperf’s output pastes below: Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1 queries Queries completed: 9820 queries Queries lost: 180 queries Queries delayed(?): 0 queries RTT max: 0.009435 sec RTT min: 0.72 sec RTT average: 0.000503 sec RTT std deviation: 0.000785 sec RTT out of range: 0 queries Percentage completed: 98.20% Percentage lost: 1.80% Started at: Thu Jul 9 11:16:03 2020 Finished at: Thu Jul 9 11:16:48 2020 Ran for: 45.300412 seconds Queries per second: 216.775070 qps The named rate-limiting logs pastes below: 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44ed190 10.0.0.10#38722 (anvq.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4414020 10.0.0.10#38722 (anwi.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4518840 10.0.0.10#38722 (anvf.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4552680 10.0.0.10#38722 (anvx.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44dea00 10.0.0.10#38722 (anwa.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4487ca0 10.0.0.10#38722 (anva.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4405890 10.0.0.10#38722 (anwg.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4526fd0 10.0.0.10#38722 (anvr.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b446ad80 10.0.0.10#38722 (anvs.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4430f40 10.0.0.10#38722 (anvh.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44227b0 10.0.0.10#38722 (anvj.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b450a0b0 10.0.0.10#38722 (anvm.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44a4bc0 10.0.0.10#38722 (anwe.internal): view : rate limit drop all response to 10.0.0.10/32 09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4496430 10.0.0.10#38722 (anwh.internal): view : rate limit drop all response to 10.0.0.10/32 To my mind the RRL should not limit queries with different qnames from the same client. So is it my misunderstanding or wrong config? BIND version pastes below: version: BIND 9.11.4-P2 (Extended Support Version) 在 2020年7月8日 +0800 PM11:45，Tony Finch ，写道： > 程智勇 wrote: > > > > So could anybody tell me why DNS_RRL_MAX_RATE defined 1000? > > RRL is designed for authoritative DNS servers. Legitimate queries come > from recursive resolvers with caches. There should not be more than one > query for each RRset from each resolver per TTL. So a normal response rate > limit is relatively small - I set it to 10. > > If you are hitting 1000 queries per second, that implies either there > are 1000 resolvers behind one IP address (which is VERY unlikely); or the > query traffic is abusive. > > Are you sure the dropped traffic is legitimate? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Channel Islands: West to southwest 4 to 5, occasionally 6 mid-channel > overnight and Thursday morning, occasionally west to northwest 2 to 4 in the > far south of the area. Slight to moderate with a low swell, perhaps > occasionally rather rough mid-channel until late morning. Occasional mist and > fog, especially overnight rain and drizzle at times, especially from Thursday > morning. Moderate to poor or very poor, locally good at times. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
