Re: DNS-Format-Eroor
On Tue, Dec 19, 2017 at 09:28:28AM +0300, Mohammed Ejaz wrote: > > No this IP 212.76.76.18 doesn’t belongs to us and even not in a > trusted list of our DNS. After looking at my logs I noticed this IP > asked for this domain mumbai-m.site to which our name server denied > as shown in the below logs. Whereas our NCSA claiming that massive > malicious requests from our dns. Just I want to understand how is > this possible massive attack towards the internet for deny requests. Those logs also show requests from another address in your own netblocks that's been assigned to a customer of Cyberia in Jeddah. That's in 212.119.73.32/27. Sten's explanation was almost certainly right with regards to the traffic seen or analysed by SA's national CERT. The traffic appearing to emanate from your DNS servers will be the result of the botnet or whatever it is making connections back to it's command and control host and spoofing the source addresses of the requests. The DNS resolvers can't tell the difference and reply to all the IPs a request appears to come from. Obviously you can't do anything about 212.76.76.18/32 directly, but if it's taken up this much time already then if I were in your position I'd just null route it at the border of Cyberia's network. Maybe notify Sahara Net that you've had to do it and forward them the same info SA's CERT gave you regarding their IP address. Meanwhile, one of your own customers (the one assigned that /27) need to hire an IT security consultant to clean their network. I'm assuming that log sample was just a quick cut and paste and there's actually a lot more. Search all the resolver logs for addresses in your IP space requesting that hostname and send all those customers a "your computer/network on IP $FOO has been compromised, you have X days to fix it or your connection will be suspended." Just warn your support staff before you do that because they're the ones who will receive the angry calls from confused accountants. Regards, Ben signature.asc Description: PGP signature ___ 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: R: Operating system recommendation
On 12/03/11 12:30 AM, Lightner, Jeff wrote: Linux people and their reinstalls?! Somebody has confused Linux with Windows. We've been running RedHat Eneterprise Linux (RHEL) systems commercially for several years (including our DNS servers) and the only time I reinstall is when I'm redeploying a system and/or want to go to a newer major release. As the prior poster said RedHat is still supports RHEL4 (7 years or more) and RHEL5 (4 years or more) and has now relased RHEL6. Actually EOL for RHEL4 was announced last month, one more year and it's gone (not counting paying exorbitant sums for additional support): https://rhn.redhat.com/errata/RHSA-2011-0219.html Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best Practices Query Logging, On or Off ?
On 22/11/10 7:12 AM, Doug Barton wrote: On Thu, 18 Nov 2010, CT wrote: - BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 Really old, definitely needs upgrading. That just means they're running RHEL 5 or CentOS 5. If they have a support contract with Red Hat, they may not be able to upgrade without forfeiting their support and/or certification. That version will include back-ported security fixes. Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: more flexible serial number handling in dnssec-signzone
On 16/10/10 4:54 AM, Niobos wrote: What's the advantage of using a date anyway? I too can see when a zone was last edited, even down to the second, by watching the RRSIG(SOA) timing. Python 2.6.5 (r265:79359, Mar 24 2010, 01:32:55) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. import time, sys print time.time() 1287165703.67 print time.asctime(time.gmtime()) Fri Oct 15 18:02:12 2010 print sys.maxint 2147483647 print time.asctime(time.gmtime(sys.maxint)) Tue Jan 19 03:14:07 2038 You don't have to worry about it yet, but it may be an issue in the future. Some 64-bit systems still report this same limitation as 32-bit systems. For some read: every one that I've checked this on. Mind you, when the date rolls around we'll have bigger problems when running systems that are affected by that. Regards, Ben -- Ben McGinnes http://www.adversary.org/ Twitter: benmcginnes Systems Administrator, Writer, ICT Consultant Encrypted email preferred - primary OpenPGP/GPG key: 0xA04AE313 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x371AC5BFA04AE313 signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 7/10/10 1:47 AM, Kevin Oberman wrote: I keep hoping for a BIND distro that upgrades nslookup(1) to: print STDERR, nslookup(1) has been replaced by host(1)\n; exit 0; Wasn't nslookup already deprecated about ten years or so ago? Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 7/10/10 2:09 AM, Kevin Oberman wrote: I can find nothing in the documentation that states such. If I missed it, I'd appreciate someone pointing me at it. I have some vague memory of seeing messages to that effect when using it on a Solaris system in around 1999. I stopped using it around then and switched to host and dig. I can't point you to specific documentation (I stopped caring when I started using dig), but I did find these: http://cr.yp.to/djbdns/nslookup.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html As far as I'm aware it only hung around because it was available on Windows NT/2K/etc., while host and dig were not. Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 7/10/10 4:42 AM, Kevin Darcy wrote: ISC has tried to kill it, but the beast is resilient and won't die. Maybe we should call it a wombat then ... Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. Nothing quite like coding/sysadmin laziness is there. Still, I probably can't talk on that front. Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 6/10/10 6:49 AM, Dotan Cohen wrote: On Tue, Oct 5, 2010 at 20:30, Eivind Olsen eiv...@aminor.no wrote: I don't think you've mentioned which OS you're running, and whether you run a bundled or self-compiled version of BIND, so I'm not sure where it puts its logs by default. Do you see _any_ mention of named in your /var/log/messages or /var/log/syslog or similar files if you restart BIND? How to restart it depends on your distribution, whether you use bundled BIND etc. It might be service named restart on one distribution, and rndc stop followed by /usr/local/sbin/named on another, or /etc/rc.d/named restart on yet another.. And I'm not good at guessing :D Sorry, it's CentOS 5.5 and I'm running the distro's packaged bind. There are a few Bind messages in /var/log/messages but no errors (other than no-start error when I have a bad config). I'm running CentOS 5.5 too and the default Bind package is 9.3.6-4.P1.el5_4.2. Dotan, if you run yum list bind you can confirm that. Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
