Re: Slow recursive query performance on Windows x64

2020-01-19 Thread Mark Andrews
Devices should return ICMP unreachables when networks are not reachable. This allows applications to move onto the next address. Not returning unreachables results in timeouts being the mechanism to move to the next address. Additionally applications can make parallel connection attempts. This

Re: Slow recursive query performance on Windows x64

2020-01-19 Thread Lee
On 1/20/20, Ondřej Surý wrote: > > Please note that filter--on-v4 was always wrong. how so? > You should fix your network instead. It’s a bandaid, not a fix. My ISP doesn't offer ipv6, so I'm not sure how to fix my network.. unless you mean disable ipv6 on everything? (which I'm not sure

Re: Slow recursive query performance on Windows x64

2020-01-19 Thread Ondřej Surý
Run named with -4 option, that will disable IPv6. Please note that filter--on-v4 was always wrong. You should fix your network instead. It’s a bandaid, not a fix. Ondrej -- Ondřej Surý — ISC > On 20 Jan 2020, at 04:38, Carl Byington via bind-users > wrote: > > -BEGIN PGP SIGNED

RE: Slow recursive query performance on Windows x64

2020-01-19 Thread Carl Byington via bind-users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-01-19 at 21:54 -0500, Steve Farr via bind-users wrote: > Does anyone know of a functionality that replaced the now-obsolete > filter--on-v4? plugin query "filter-.so" { filter--on-v4 yes; }; -BEGIN PGP

RE: Slow recursive query performance on Windows x64

2020-01-19 Thread Steve Farr via bind-users
Lee, that was fantastic. Thank you! Setting the whole IPv6 internet to be Bogus worked like a charm. It would appear that even though IPv6 is unbound from the NIC that BIND is running on, and even though BIND is only listening on v4 addresses, and even though I had the v6 roots commented out

Re: Slow recursive query performance on Windows x64

2020-01-19 Thread Lee
On 1/18/20, Steve Farr wrote: > > I don't have IPv6 connectivity through my ISP, and don't use it on my LAN, > so I have it unchecked/not bound in Windows, Same here. When I tried running named on windows it didn't support the -4 option; the workaround I was given was to add server ::/0 { bogus

Re: securing bind in todays hostile environment

2020-01-19 Thread John W. Blue
Since it sounds like you have not had much experience with, I urge you to check it out should you have anything in your environment that could benefit from automation. Simply telling someone to chunk it and not have any experience with it is a little misguided IMO. We pay multiple different

Re: securing bind in todays hostile environment

2020-01-19 Thread Grant Taylor via bind-users
On 1/19/20 4:01 AM, N. Max Pierson wrote: I honestly couldn’t tell you either way as I have not even begun to start to dive into DNSSEC. I can recommend the following book from Michael W. Lucas / @mwlauthor and say that it provides a good, actionable, introduction to DNSSEC. Link - DNSSEC

Re: securing bind in todays hostile environment

2020-01-19 Thread Grant Taylor via bind-users
On 1/19/20 3:25 AM, N. Max Pierson wrote: Hi Grant, Hi, I should have been a little more descriptive in the scenario by giving the purpose of these name servers. They are basically being deployed as a managed DNS service that we offer. We are a MSP for the most part and the DNS

Re: securing bind in todays hostile environment

2020-01-19 Thread N. Max Pierson
Hi John, > 1. What is your/teams plan B to fix this type of ansible environment should > it get horked up? There is a ton of stuff that is being configured for you > all under the hood and by your own admission your a novice. The laws of > unintended consequences apply. With bind, I am a

Re: securing bind in todays hostile environment

2020-01-19 Thread N. Max Pierson
Hi Grant, A couple of things …. I should have been a little more descriptive in the scenario by giving the purpose of these name servers. They are basically being deployed as a managed DNS service that we offer. We are a MSP for the most part and the DNS infrastructure was not being very well