Re: bugs with BIND 9.11.0-P3 edns client subnet
> On Oct 12, 2017, at 10:00 AM, Shawn Zhou via bind-users > wrote: > > Hello all, > > Does anyone use BIND 9.11.0-P3 in recursive setup with edns client subnet > support? > When I dig against a local recursive resolver (BIND 9.11.0-P3) with > '+subnet=' option, it doesn't send 'Client subnet' option to the > authoritative server which also runs the same version of BIND; however, if I > dig directly against the authorize server with '+subnet=' option and it works > fine. Is this a known bug with client subnet implementation in BIND? Hi Shawn, The resursive support for EDNS client-subnet is only in our subscription edition. It is not in any version of 9.11.0. The subscription edition is available to support subscribers but is not posted publicly. The company that sponsored the work required that we embargo it from the open source to give them a chance to market it in their own version of BIND. If you have any more questions about this, I invite you to unicast to me at vi...@isc.org. Regards, Vicky Risk Product Manager > > > Thanks, > Shawn > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users Victoria Risk Internet Systems Consortium vi...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bugs with BIND 9.11.0-P3 edns client subnet
Hello all, Does anyone use BIND 9.11.0-P3 in recursive setup with edns client subnet support?When I dig against a local recursive resolver (BIND 9.11.0-P3) with '+subnet=' option, it doesn't send 'Client subnet' option to the authoritative server which also runs the same version of BIND; however, if I dig directly against the authorize server with '+subnet=' option and it works fine. Is this a known bug with client subnet implementation in BIND? Thanks,Shawn___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Query for newly added/modified data in zone fails at random
On 12 October 2017 at 11:03, Nikkilä, Tommi wrote: > Hi! > > > > My BIND (version 9.9.4-RedHat-9.9.4-51.el7) is displaying some odd > behavior. When updating a zone, BIND randomly refuses to return the newly > added and/or modified data for client. In my named.conf I have dozens of > views, main interest in the following > Each view keeps its own internal state for its zones. The way you appear to have this configured, for any zone in 'common-slave.conf' you have several versions stored (one per view) each trying to write to the same state file (e.g. slave/db.207.31.172.in-addr.arpa). If I were to speculate (you'd want to do some more troubleshooting to confirm), I would suspect you're running into problems with your views stomping on each other's slave files. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Query for newly added/modified data in zone fails at random
Hi!
My BIND (version 9.9.4-RedHat-9.9.4-51.el7) is displaying some odd behavior.
When updating a zone, BIND randomly refuses to return the newly added and/or
modified data for client. In my named.conf I have dozens of views, main
interest in the following
view "nwserv" {
include "config/zones.conf";
match-clients {
backup;
};
};
view "CLIENT1" {
include "config/common-slave.conf";
include "config/CLIENT1-internal.conf";
match-clients {
CLIENT1;
};
};
view "CLIENT2" {
include "config/CLIENT2-internal.conf";
include "config/common-slave.conf";
max-cache-ttl 180;
match-clients {
CLIENT2;
};
};
[...]
view "isfi" {
include "config/common-slave.conf";
match-clients {
any;
};
};
The "zones.conf" and "common-slave.conf" both include configurations for
several zones of which the zone 207.31.172.in-addr.arpa is currently not
functioning correctly. Current configuration for that zone is
zone "207.31.172.in-addr.arpa" in {
type slave;
file "slave/db.207.31.172.in-addr.arpa";
masterfile-format text;
masters port 8054 { 192.168.100.22; };
};
When updating the zone, the master server transfers the zone to my slave
correctly. This can be verified by viewing the corresponding db file which
contains newly incremented serial and any changes made to master's db file. My
problem is, however, that when querying the zone, the newly distributed changes
(i.e. new serial) are at random not displayed to any clients within "nwserv"
view. By doing a SIGKILL for BIND the correct behavior is restored and clients
within the "nwserv" view are able to view the contents of the entire zone,
including any recent changes/additions. The zones.conf includes configuration
for the 207.31.172.in-addr.arpa zone and no other configuration file includes it
# grep 207.31.172.in-addr.arpa zones.conf
zone "207.31.172.in-addr.arpa" in {
file "slave/db.207.31.172.in-addr.arpa";
# grep 207.31.172.in-addr.arpa common-slave.conf
# grep 207.31.172.in-addr.arpa *.conf
zones.conf:zone "207.31.172.in-addr.arpa" in {
zones.conf: file "slave/db.207.31.172.in-addr.arpa";
My question is: has anyone observed similar behavior and if so, what was your
solution for it?
Tommi Nikkilä | System Specialist
Network Services | CGI
Karvaamokuja 2, FI-00380 Helsinki | Finland
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
