> On 2018-09-17 19:32, Tom Sweet wrote: > Greetings Jason: >> On Thu, Sep 6, 2018, 4:38 PM jmitchel <jmitc...@bigjar.com> wrote: >>> On 2018-09-06 16:21, jmitchel wrote: >>> Hello, >>> I know this is a somewhat annoying question, because it's very >> broad >>> and the server's out of date, but am I going to get in trouble >> using >>> the version of BIND that came with NetBSD 6.1.4. Here's the info: >>> Karma:/etc/namedb# uname -a >>> NetBSD Karma 6.1.4 NetBSD 6.1.4 (GENERIC) i386 >>> Karma:/etc/namedb# named -V >>> BIND 9.9.2-P1 built with defaults >>> using OpenSSL version: OpenSSL 1.0.1g 7 Apr 2014 >>> The box will be answering queries from a cached version of the >> Windows >>> DNS domain, and will also be used to forward all non-local lookups >> to >>> OpenDNS. It is behind a SonicWall firewall and there isn't any >> direct >>> access to port 53 (either TCP or UDP) from the Internet. What are >> the >>> odds the server will be okay? >>> I know I should just install the latest version, but I'm under the >> gun >>> as we've just realized that there are about 400 "Malware" DNS >> queries >>> per day and I'm worried about what's installed on what computers >> and >>> want to know which ones are infected ASAP. > I'd reconsider introducing another host running internet connected > services that you have to manage when the internal environment isn't > well behaved. > By all means run NetBSD at every opportunity, but _not_ "under the > gun". > May I respectfully suggest: > * Update the Sonicwall. > * Turn on the Intrusion Detection & Prevention features to high > levels. > * Configure Sonicwall' s DNS proxy to lookup @ the provider of your > choice. > * Configure the Windows DNS server conditional forwarders to send all > non-local queries to the Sonicwall. > * Monitor your logs and start your cleanup. > * Tune the logs to reduce unnecessary messages. > * Look for opportunities to plan and deploy NetBSD in the > organization. Perhaps as the heart of your new Security Information & > Event Management initiative? > Same results, one less host to attack. I never let AD DNS servers > resolve queries for other than their own zones. Always forwarded to > public providers or ISP. Firewall rules in place accordingly.
Sorry, I didn't do a good job of explaining. The NetBSD machine running named has been up and running for years. And it’s been running secondary from Windows AD DNS servers for years as well. I upgraded it to 6.1.4 a while back. The only new things were: A) Changing DHCP scopes (on Windows) so that the NetBSD server was the first, rather than the second listed DNS server. It was still getting a bunch of queries, so I guess the Windows servers weren't fast enough for the Windows clients' taste :) B) Upgrading BIND to the most recent version available as a binary package (just in case) C) Turning on logging for every query >>> Thanks in advance for reading and any help you can provide. >>> Jason M. >> Never mind (I think). I checked pkgsrc before writing this, but >> didn't >> check the right directory. I just found bind-9.10.8pl1nb1 and will >> use >> that. But if there's any reason I should be wary with the newer >> software, please let me know. >> Thanks, >> Jason M. > Best of luck to your efforts. > Tom S. I will, however, post tomorrow what I think is an obvious core dump, just so I can be sure it happened for the reason I think it happened. Thanks! Jason M.
