BIND-RPZ and Views
Hi Using BIND 9.10.4-P2: I've a question about configuring DNS-RPZ and views: I configured view1 and view2. After configuring all rpz-zones in both views, I had errors like this (slave file in view2 is already in use from view1): config: error: /etc/named/named.conf:403: writeable file 'slave/malware.rpz.spamhaus.org': already in use: /etc/named/named.conf:259 Is there a way to support RPZ in views? I want to achieve that Customer01 (view01) should have different RPZ-options than Customer02 (view02) using the same RPZ-Files. Thank you. Kind regards, Tom ___ 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: BIND-RPZ and Views
On 16/09/16 09:06, Tom wrote: Hi Tom, > Using BIND 9.10.4-P2: I've a question about configuring DNS-RPZ and views: > I configured view1 and view2. After configuring all rpz-zones in both > views, I had errors like this (slave file in view2 is already in use > from view1): > config: error: /etc/named/named.conf:403: writeable file > 'slave/malware.rpz.spamhaus.org': already in use: /etc/named/named.conf:259 In newer versions of BIND, you cannot share a writable file in different views. This is a bad configurtion, and newer versions of BIND reject it. Just use different file names. Regards, Anand ___ 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: Load balancer for Bind
> So what we recommend is using dnsdist to balance to your backends, and have > it prefer one backend when all things are equal. Then run multiple dnsdists > which each prefer a different backend. And then announce your dnsdist > service addresses a few times over BGP. +1 on this. We moved from an all anycast resolver setup to an anycast+dnsdist, resolver backend setup the way Bert described it. I would add that with dnsdist and caching enabled you don't need as many backend resolvers. 90% of the queries can be answered from dnsdist caches. So in our case, we have multiple dnsdist instances across the swiss NREN network but only few backend resolvers. Daniel ___ 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: BIND-RPZ and Views
Anand Buddhdev wrote: > > In newer versions of BIND, you cannot share a writable file in different > views. This is a bad configurtion, and newer versions of BIND reject it. > Just use different file names. To clarify, you couldn't in older versions of BIND either! It would cause weird data corruption problems. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Faeroes, Southeast Iceland: Southerly or southwesterly 4 or 5, increasing 6 or 7 later, perhaps gale 8 in Southeast Iceland. Moderate or rough, occasionally very rough later. Showers, rain later. Moderate or good, occasionally poor later. ___ 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: Load balancer for Bind
On 15/09/16 15:49, bert hubert wrote: Sorry for running advertisement here. But please know dnsdist is software neutral, it is not "powerdnsdist". I've never come across dnsdist before. Would you describe it as production-ready? ___ 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: Load balancer for Bind
On Fri, Sep 16, 2016 at 02:03:31PM +0100, Phil Mayers wrote: > >Sorry for running advertisement here. But please know dnsdist is software > >neutral, it is not "powerdnsdist". > > I've never come across dnsdist before. Would you describe it as > production-ready? Hi Phil, A large CDN, one of .nl largest hosting providers, several country-sized telecommunications service providers and most Swiss universities would let us know if it wasn't. Your question is justified of course. The history of dnsdist goes back to 2013. We spent most of 2015 ramping it up, and even as we were doing so it was already being deployed, pre-1.0.0. Since we released 1.0.0 at UKNOF 34 https://www.youtube.com/watch?v=5abqhVfJFhg we have seen adoption skyrocket, and we have just accumulated enough reasons to release 1.1.0 shortly. The release notes for beta-1 describe the sort of things we are working on now https://blog.powerdns.com/2016/09/01/dnsdist-1-1-0-beta-1-released/ Not a single production crash or incident has been reported in 1.0.0. So to answer your question - our users have deployed it at scale, and we are not aware of any issues you should know about. http://dnsdist.org/ has more background & links to our mailing list. Bert ___ 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: Load balancer for Bind
On 16/09/16 14:16, bert hubert wrote: Your question is justified of course. The history of dnsdist goes back to 2013. We spent most of 2015 ramping it up, and even as we were doing so it was already being deployed, pre-1.0.0. I was mainly wondering about the comment: """ dnsdist is still very fresh software. However, we are actively seeking feedback, but not quite yet production users. Please let us know your thoughts on powerdns.id...@powerdns.com! """ ...from https://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/, linked prominently from the project homepage. Anyway, it's a really interesting looking bit of software - I've got a new thing on the TODO list to inspect. ___ 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: Load balancer for Bind
On Fri, Sep 16, 2016 at 02:22:24PM +0100, Phil Mayers wrote: > I was mainly wondering about the comment: > > """ > dnsdist is still very fresh software. However, we are actively seeking Hi Phil, Thanks - that statement was accurate in March 2015 when we posted that item. I have now replaced it with: "dnsdist 1.0.0 was released on the 21st of April 2016 at UKNOF34. Packages, documentation, source code and news can be found on http://dnsdist.org/"; > Anyway, it's a really interesting looking bit of software - I've got a new > thing on the TODO list to inspect. Thanks! Bert ___ 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
dig +trace = Bad Referral orBad Horizontal referral
I have an interesting problem. I started noticing that when I do a dig
+trace against one of the domains we are authoritative for, we get errors
from our nameservers for "Bad Referral" and you can see where it forwarded
the request back up the namespace tree instead of giving the answer.
Unfortunately I am unable to reproduce this problem at the moment. However
I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
referred to our name server I see this:
;; BAD (HORIZONTAL) REFERRAL
;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms
Sometimes this loops until I reach the "too many lookups" error and it just
gives up, or it will stop and try our other server which then gets an
answer. Here's the interesting part. If I was to perform a simple dig A
lookup against the server that continusouly failed the trace, I get an
answer and a correct one. If I then turn around and do the dig +trace
against that same query again *it never fails again.* Its almost like
records are being cached somewhere and after it expires, then you will
start to see the message again. Can anyone help me figure out what id going
on here? Here is info about our environment.
1)RHEL 6 running BIND 9.8.2
2)Public facing auhtoritative Master and Slave Server."
3)Servers are setup in a "view" configuration. (dual-view - one for
"internal" one for external)
4)It seems like we just started to see these oddities after implementing
views.
5)Queries that hit the internal view are forwarded to the external view for
zones not contained in the internal view. We use the loopback IP to acheive
this.
6) These authoritative servers are also setup to answer non-authoritative
queries with recusrion through the use of the recusion statement and root
"hint" zone.
Here is our setup simplified.
Master server:
acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.
ccl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"
options {
directory "/var/named";
recursive-clients 3;
tcp-clients 2000;
check-names master ignore;
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named.stats.txt";
memstatistics-file "/var/named/data/named_mem/stats.txt";
zone-statistics yes;
cleaning-interval 30;
// Listen on ipv4: // Adding localhost for view forwarding
listen-on port 53 { x.x.x.x; 127.0.0.1; };
// And, also listen on ipv6:
// loopback is required for view forwarding do not remove
listen-on-v6 { ::1; x.x.x.x; };
// Enforce the Customer DNS Query ACL Defined Above:
allow-query { ext_trusted; int_trusted; };
// Enforce the Zone-Transfer ACL Defined Above:
// This will now be defined on a "per view" basis
//allow-transfer { other_ns; };
};
key "internal" {
algorithm HMAC-SHA512;
secret "x";
};
key "external" {
algorithm HMAC-SHA512;
secret "";
};
view "internal" {
match-clients { !key external; int_trusted; key internal; };
//IP of slave server
server x.x.x.x {
keys { internal; };
};
server x.x.x.x {
keys { internal; };
};
also-notify { //slave servers go here
x.x.x.x; x.x.x.x;
};
allow-transfer { key internal; local_ns; int_ns; };
empty-zones-enable no;
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
zone "example.org" {
type master;
file "db.eample.org";
allow-query { int_trusted; };
};
forwarders {
// forward to external view //
127.0.0.1; ::1;
};
forward only;
};
view "external" {
match-clients { any; };
//IP of slave server
server x.x.x.x {
keys { external; };
};
server x.x.x.x {
keys { external; };
};
also-notify { //IP address of slave server
x.x.x.x; x.x.x.x;
};
allow-transfer { key external; ext_ns; local_ns; };
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
empty-zones-enable yes;
recursion yes;
allow-recursion { any; };
zone "." {
type hint;
file "/var/named/named.ca";
};
zone "example.org" {
type master;
file "db.eampleout.org";
allow-query { any; };
};
zone "example.com" {
type master;
file "db.eample.com";
allow-query { any; };
};
};
Slave server config:
acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.
ccl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"
options {
directory "/var/named/slaves";
recursive-clients 3;
tcp-clients 2000;
check-names master ignore;
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
cleaning-interval 30;
// Listen on ipv4:
// Change this to
