Re: Removal notice: Response Policy Server (BIND 9.21+)

— 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

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

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? > > Curre

Re: RPZ configuration examples

ollowing: 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 __

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

Re: disable dnssec in bind resolver

ng 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 ma

[no subject]

addr() 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 __