Re: Removal notice: Response Policy Server (BIND 9.21+)
If that's how it worked then it was indeed an error. That was not Farsight's goal or my understanding. In any case RPZ no longer needs special code from anywhere and I share your joy about that. p vixie On Aug 21, 2024 00:55, Ondřej Surý wrote: No, it didn’t work with any policy. The feature required librpz.so that was a binary blob provided to Farsight customers. It was wrong to accept this code into BIND 9 in the first place. BIND 9 already had working RPZ implementation and the effort would be better spent on improving RPZ for everyone. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 21. 8. 2024, at 9:26, Paul Vixie wrote: It worked with any policy source not just Farsight. However, is no longer necessary since isc now has a native RPZ implementation. Thanks for that. p vixie On Aug 20, 2024 23:55, Ondřej Surý wrote: Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to remove support for Response-Policy Server support. Back in 2018, Farsight Security[1] contributed a patch to BIND that was an optional replacement to our native RPZ implementation. At that time, our RPZ implementation wasn’t scaling very well, and we accepted the patch. This patch, however, only worked with Farsight’s own RPZ service, so its utility is limited to Farsight customers. We do not think this patch really belongs in open source BIND 9 version. Removing the feature that has limited user-base will allow us to improve the RPZ (Response-Policy Zones) feature that's native to BIND 9 and available to all BIND 9 users. The feature is called DNSRPS, or the Response Policy Server. Farsight called it “FastRPZ”, but in the ARM it is called the Response Policy Server[2]. The support for DNSRPS/FastRPZ will be deprecated as of BIND 9.20 and removed in BIND 9.21/9.22. 1. Since then Farsight Security has been acquired by DomainTools. 2. https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-dnsrps-enable. Cheers, -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- bind-announce mailing list bind-annou...@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-announce -- 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: Removal notice: Response Policy Server (BIND 9.21+)
It worked with any policy source not just Farsight. However, is no longer necessary since isc now has a native RPZ implementation. Thanks for that. p vixie On Aug 20, 2024 23:55, Ondřej Surý wrote: Hello, In line with ISC's deprecation policy, I am notifying the mailing list of our intent to remove support for Response-Policy Server support. Back in 2018, Farsight Security[1] contributed a patch to BIND that was an optional replacement to our native RPZ implementation. At that time, our RPZ implementation wasn’t scaling very well, and we accepted the patch. This patch, however, only worked with Farsight’s own RPZ service, so its utility is limited to Farsight customers. We do not think this patch really belongs in open source BIND 9 version. Removing the feature that has limited user-base will allow us to improve the RPZ (Response-Policy Zones) feature that's native to BIND 9 and available to all BIND 9 users. The feature is called DNSRPS, or the Response Policy Server. Farsight called it “FastRPZ”, but in the ARM it is called the Response Policy Server[2]. The support for DNSRPS/FastRPZ will be deprecated as of BIND 9.20 and removed in BIND 9.21/9.22. 1. Since then Farsight Security has been acquired by DomainTools. 2. https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-dnsrps-enable. Cheers, -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- bind-announce mailing list bind-annou...@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-announce -- 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: .prod issues
> I have a subdomain prod.mydomain.com today all of our internal > resources that use this prod subdomain stopped being able to reach > eachother. I believe the issue is related to the release of .prod as > a TLD. Is there a way I can block this TLD or point it back to my > environment? > > Currently, I have added mdots:2 to resolv.conf as a workaround. i think you probably mean ndots not mdots. that's a fine workaround as long as you control all your stub resolvers (which is where the ndots logic runs) and they are all running the BIND stub resolver (for which ndots is a unique feature; see RFC 1535 for the history). a likely better workaround is to use DNS RPZ (so, you'll need BIND 9.9 or later on your recursive servers) and put in a local rule like "*.PROD CNAME ." to cause all of the search-path logic of all your stub resolvers (whether they have ndots logic, or not) to never see the PROD TLD, and thus, fall through to your local PROD.EXAMPLE.COM names. sadly, i think a lot of people in a lot of places are going to do this to a lot of the new GTLD's. but the new GTLD's have been on greased rails since inception, and no amount of warnings about this kind of damage did more than slow things down briefly. so, the hounds of DNS hell are now loose. good thing we have RPZ i guess. vixie ___ 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: RPZ configuration examples
noting, first: there is documentation online for DNS RPZ, see the following:
https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
second, as to the particulars:
babu dheen writes:
> We are new to BIND and would like to implement RPZ in BIND. I have a
> following queries with respect to RPZ in BIND.
>
> 1. Do you have basic example/steps to configure RPZ in Bind? ( I need
> couple of examples like /etc/named.conf file and zone files for rpz
in my recursive server's named.conf file, in the options{} block, i have:
response-policy {
zone "dns-policy.vix.com";
zone "rpz.surbl.org";
zone "rpz.spamhaus.org";
zone "block.c2.rpz.umbradata.com";
zone "hh.c2.rpz.umbradata.com";
zone "active.nx.rpz.iidrpz.net";
zone "dga.nx.rpz.iidrpz.net";
};
all but the first of these is a "slave" zone that i subscribe to. the first
one is my local policy, and that zone looks like:
$TTL 30
@ SOA nsa.vix.com. hostmaster.vix.com. 29 3600 1800 604800 30
NS localhost.
; eric ziegast suggestions
11.156.21.46.32.rpz-ip CNAME *.
96.177.58.207.32.rpz-ip CNAME *.
; pedro bueno suggestions
14.53.199.94.32.rpz-ip CNAME *.
; android market scammer
softthrifty.com CNAME .
*.softthrifty.com CNAME .
; spam houses
*.verticalresponse.com CNAME .
; imports
$INCLUDE "drop/drop.inc"
$INCLUDE "drop/bogons.inc"
the two $INCLUDE files are generated by a perl script using data imported
from Team Cymru and Spamhaus. that method is described at in blog post at:
http://www.circleid.com/posts/using_domain_filtering_to_effect_ip_address_filtering/
drop.inc begins as follows:
24.0.140.196.109.rpz-ip CNAME .
*.140.196.109.in-addr.arpa CNAME .
22.0.212.94.109.rpz-ip CNAME .
*.212.94.109.in-addr.arpa CNAME .
*.213.94.109.in-addr.arpa CNAME .
*.214.94.109.in-addr.arpa CNAME .
*.215.94.109.in-addr.arpa CNAME .
bogons.inc begins as follows:
8.0.0.0.0.rpz-ip CNAME .
*.0.in-addr.arpa CNAME .
10.0.0.64.5.rpz-ip CNAME .
*.64.5.in-addr.arpa CNAME .
*.65.5.in-addr.arpa CNAME .
*.66.5.in-addr.arpa CNAME .
*.67.5.in-addr.arpa CNAME .
*.68.5.in-addr.arpa CNAME .
*.69.5.in-addr.arpa CNAME .
a copy of the perl script that generates these is online at:
http://nsa.vix.com/~vixie/lasso2rpz.pl
> 2. If I use RPZ, recursive DNS will contact remote RBL database for
> every DNS query?
no. all RPZ control plane information is held locally in the recursive
server. per the specification at:
https://deepthought.isc.org/article/AA-00512/0
we see this text:
A DNS Response Policy Zone (RPZ) is a DNS zone, and as such its
contents can be transferred between servers (DNS AXFR/IXFR),
protected by transaction signatures (DNS TSIG), and expedited by
real time change notifications (DNS NOTIFY), all subject to
familiar DNS access controls. An RPZ usually does not support query
access since it is never required for correct operation. Rather it
is the zone transfer of RPZ content from producers to subscribers
which effectively publishes the policy data, and it is the
transferee's server configuration which promotes RPZ payload data
into DNS control plane data.
> 3. Is it possible to download DNS RBLs locally on the DNS server
> automatically daily and then allow RPZ query locally to give malware
> domain lookup response?
yes. that is one of the intended uses of DNS RPZ.
> If you can help on this, it will be very much helpful to understand
> and implement RPZ in our enterprise.
while this discussion is on-topic for bind-us...@isc.org ("here"), there
is also a mailing list specific to DNS RPZ. to subscribe, visit:
https://lists.isc.org/mailman/listinfo/dnsrpz-interest
noting, again: there is documentation online for DNS RPZ, see the following:
https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
thank you for your interest in DNS RPZ.
--
Paul Vixie
KI6YSY
___
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: [META] Usenet cross-posting is back.
Dan Mahoney writes: > I'm happy to announce that as of today, with some help from Russ Alberry > and the fine people at Stanford University, we've restored this > functionality. >... thanks dan, thanks russ. -- Paul Vixie KI6YSY ___ 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: disable dnssec in bind resolver
Doug Barton writes: > On 06/04/10 19:40, Paul Vixie wrote: >> ... >> >> unless a new IETF RFC comes along and disambiguates the meaning of "DO" >> such that it's only to be set if the requestor thinks it has a >> reasonable shot at validating the resulting metadata, i expect BIND to >> keep setting "DO" on all EDNS requests it generates. and i don't think >> you can make a _public benefit_ argument that this is wrong even though >> there are _private benefit_ arguments. > > ... > > With my business hat on though I can see at least 2 possible use cases for > DO=0. The first being related to this thread, "I can't/won't fix/remove the > firewall today, I just want my resolver to work." it works. it's just slower because it has to fall back. this is one of the reasons we fall back to BUFSIZE=512 before falling all the way back to DNS (that is, turning EDNS off all together.) > The hapless user in that spot is either going to use another vendor, or > go back to the old version of BIND that "works." I know market share > isn't a _primary_ concern for BIND, but I would argue that the "go back > to old version" answer to this dilemma is something that we should all be > concerned about. that's been *very* rare on this point. ISC is concerned about relevance, since we don't want to develop stuff that folks don't want to use. that's *not* happening en masse in this case. > ... > > In all fairness, I don't have any actual clients telling me that DO=1 is > a problem for them, this is pure speculation on my part; ... yes, i know that, because i'd see the other side of it if it was going on. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
Doug Barton writes: > I have a guess at why ISC would want to enable it by default, and even in > the presence of an option to turn it off I'm still Ok with that default. > But if it's not a standards requirement to have it on, giving the admin a > choice would be a welcome thing. this was, as you pointed out, a controversial decision. BIND implements the "DO" bit as "this requestor will not vomit or crash if you include DNSSEC metadata in the response". we believe that this supports the eventual goal of near-universal DNSSEC deployment, in which it's foolish to treat "DO" as "this requestor is explicitly interested in DNSSEC metadata on this answer". the earlier we face the UDP fragmentation pain, the smaller that pain will have been by the time we overcome it. same thing for validator bugs, zone signing/resigning errors/expirations, and everything else that makes "always set DO" seem unattractive today, to today's sysadmins, who aren't involved in any DNSSEC deployment crusade and don't appreciate being co-opted for it. unless a new IETF RFC comes along and disambiguates the meaning of "DO" such that it's only to be set if the requestor thinks it has a reasonable shot at validating the resulting metadata, i expect BIND to keep setting "DO" on all EDNS requests it generates. and i don't think you can make a _public benefit_ argument that this is wrong even though there are _private benefit_ arguments. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[no subject]
Chris Thompson writes: > Nothing that I can see. Maybe dnsviz can't cope with multiple PTR > records in an RRset, as your first case has? (On the other hand it > handles multiple A records in forward zones OK.) to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr() in more or less direct contravention to RFC 1034. if dnsviz doesn't handle it (and i don't know if it doesn't) then it's not dnsviz's fault at all since the DNS RFC's say that there will only be one PTR RR at an in-addr. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
