Re: Malicious DNS request?
Hi, thanks for your help. I noticed that the requests of those non-exist domain name disappeared yesterday. But the NXDOMAIN record in named.stats keep increasing. ( see attachment) I'm using BIND9.2.5 BIND9.3.1 on two Solaris box, each box has two CPUs installed. it's found BIND8.4.6 running on one CPU could reach the throughput of BIND9.*.* running on two CPUs. Could we improve server throughput or lower lower the effect of those requests on NXDOMAIN? Joe __ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com
Re: Malicious DNS request?
Sorry to attach the rndc stats result. I run rndc stats continuously( interval is less than 2 seconds), it's shown: success 17950622 referral 225680 nxrrset 1691861 nxdomain 11203490 recursion 3648017 failure 1363923 ... --- Statistics Dump --- (1116319437) +++ Statistics Dump +++ (1116322885) success 18889882 referral 229772 nxrrset 1809835 nxdomain 11474755 recursion 3825876 failure 1415044 --- Statistics Dump --- (1116322885) +++ Statistics Dump +++ (1116322886) success 18890342 referral 229772 nxrrset 1809868 nxdomain 11474873 recursion 3825976 failure 1415052 --- Statistics Dump --- (1116322886) Joe __ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com
Re: Malicious DNS request?
Sorry to attach the rndc stats result. I run rndc stats continuously( interval is less than 2 seconds), it's shown: success 17950622 referral 225680 nxrrset 1691861 nxdomain 11203490 recursion 3648017 failure 1363923 ... --- Statistics Dump --- (1116319437) +++ Statistics Dump +++ (1116322885) success 18889882 referral 229772 nxrrset 1809835 nxdomain 11474755 recursion 3825876 failure 1415044 --- Statistics Dump --- (1116322885) +++ Statistics Dump +++ (1116322886) success 18890342 referral 229772 nxrrset 1809868 nxdomain 11474873 recursion 3825976 failure 1415052 --- Statistics Dump --- (1116322886) Joe __ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com
Re: Malicious DNS request?
[EMAIL PROTECTED] (Joe Shen) writes: I'm using BIND9.2.5 BIND9.3.1 on two Solaris box, each box has two CPUs installed. it's found BIND8.4.6 running on one CPU could reach the throughput of BIND9.*.* running on two CPUs. Could we improve server throughput or lower lower the effect of those requests on NXDOMAIN? yes. but we isn't nanog. can you take your bind-specific questions to a bind-related mailing list or newsgroup? www.isc.org has pointers. -- Paul Vixie
Re: Malicious DNS request?
Paul, I'm sorry if this is JUST to BIND or some other specific software. But, IMHO this is just a sample that requests which only generate NXDOMAIN responds. According to someone's presentation on NANOG (DNS anomailies and their impact on DNS Cache Server ), such record may be type of attack. If we only rely on cacheing to remove paient of CPU time, cache server load will be increased. So, what I'm tryting to ask is , is there some mechanism proposed to deal with such problem? BIND is just a sample. joe --- Paul Vixie [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Joe Shen) writes: I'm using BIND9.2.5 BIND9.3.1 on two Solaris box, each box has two CPUs installed. it's found BIND8.4.6 running on one CPU could reach the throughput of BIND9.*.* running on two CPUs. Could we improve server throughput or lower lower the effect of those requests on NXDOMAIN? yes. but we isn't nanog. can you take your bind-specific questions to a bind-related mailing list or newsgroup? www.isc.org has pointers. -- Paul Vixie __ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com
Re: Malicious DNS request?
At 8:45 AM +0800 2005-05-18, Joe Shen wrote: I'm sorry if this is JUST to BIND or some other specific software. But, IMHO this is just a sample that requests which only generate NXDOMAIN responds. Do a DNS query for slartibartfastisacharacterinamoviewrittenbydouglasadamsthathasnotgottenverygoodreviewslatelyandisbasedontheoriginalBBCradioshowandtheresultingBBCtvminiseries.com, and you'll probably get an NXDOMAIN. Indeed, query for any other non-existent domain, and you'll get an NXDOMAIN response. That's what it means. According to someone's presentation on NANOG (DNS anomailies and their impact on DNS Cache Server ), such record may be type of attack. NXDOMAIN == Attack? Please show me how you arrive at that logic. If we only rely on cacheing to remove paient of CPU time, cache server load will be increased. So, what I'm tryting to ask is , is there some mechanism proposed to deal with such problem? BIND is just a sample. Well, only caching servers have to worry about getting an NXDOMAIN response back. Authoritative-only servers may have to worry about sending them out, but that's pretty cheap. Indeed, it's pretty cheap for the caching servers to handle getting them. Yes, bad clients can abuse either caching servers or authoritative-only servers by doing things that result in a lot of NXDOMAIN responses, but that falls in the category of the programmers doing whatever is possible to protect themselves and their code against whatever kind of abuse gets hurled at them by poorly-behaved clients. As far as that goes, that's a generic problem, and in the case of nameservers there are appropriate places to discuss this sort of thing -- such as the namedroppers mailing list. Now, if you want to drag BIND into this picture as a specific example, there are appropriate places to discuss that, too -- such as the bind-users mailing list, or maybe one of the developer-oriented BIND mailing lists. But none of these places are NANOG, and this discussion doesn't belong here -- either in the general case of nameservers, or in the specific case of BIND. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: Malicious DNS request?
Tunneling IP over DNS - Dan Kaminsky's ozymandns project. One source of really strange DNS packets I've seen is Dan Kaminsky's experiments with tunneling IP over DNS , which he presented at Codecon, Defcon, and other places. Dan has often done Really Twisted Things With Packets, and once you've already tunneled IP though HTTP, it's time to do something a bit more aggressive. His first implementations were relatively straightforward, good enough for using SSH and email from the DNS servers on random wireless access points without needing to log in, but they weren't really high performance. The work he demonstrated at Codecon 2005 was able to do high-performance streaming video over DNS, which required spreading the data stream over tens of thousands of DNS servers. It was quite impressive, in a this-is-seriously-wrong kind of way. Perhaps somebody's running something like that somewhere near you.
Re: Malicious DNS request?
On 5/12/05, Joe Shen [EMAIL PROTECTED] wrote: By tcpdump, it's found a remote computer keep asking address for record like 999d38e693b9e6293b450.0existence.com, 60d38e693b9e6293b450.0be6c1xfa.net. is that a virus affacted computer? Sure looks like some kind of massmailer trojan, or a affiliate program based spam sending software like Atriks. These two domains you quoted have rather interesting whois records, particularly 0existence.com .. Domain Name.. 0existence.com Creation Date 2004-10-23 Registration Date 2004-10-23 Expiry Date.. 2009-10-23 Organisation Name William Peter Organisation Address. 52 THIRD AVENUE Organisation Address. Organisation Address. Woonsocket Organisation Address. 02895 Organisation Address. RI Organisation Address. UNITED STATES Admin Name... William Peter Admin Address 52 THIRD AVENUE Admin Address Admin Address Woonsocket Admin Address 02895 Admin Address RI Admin Address UNITED STATES Admin Email.. [EMAIL PROTECTED] Admin Phone.. +1.4067672231 Admin Fax Tech Name Existence Corporation Tech Address. 701 First Ave. Tech Address. Tech Address. Sunnyvale Tech Address. 94089 Tech Address. CA Tech Address. UNITED STATES Tech Email... [EMAIL PROTECTED] Tech Phone... +1.6198813096 Tech Fax. +1.6198813010 -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Malicious DNS request?
Joe Shen wrote: Hi, In past days I noticed the nxdomain statistics in named.stats keeps increasing.( I run it every 5 min) By tcpdump, it's found a remote computer keep asking address for record like 999d38e693b9e6293b450.0existence.com, 60d38e693b9e6293b450.0be6c1xfa.net. is that a virus affacted computer? How could such request be filtered or minimize its affaction on DNS server? Either this is a DDoS (woohoo!! I used the forbidden word) or you are seeing a botnet trying to connect and putting in some smoke-screen while at it to try and poison dns-top. I'd suggest dropping requests for domains you don't hold. Gadi.
Re: Malicious DNS request?
At 11:26 AM -0400 2005-05-12, [EMAIL PROTECTED] wrote: It's often suggested that you have *two* DNS setups - one that only answers requests from inside for recursion and caching, and an authoritative one that faces out and refuses to recurse. The original question from Joe Shen said that a remote computer was asking questions about certain servers, but did not specify whether or not the remote computer in question was a customer. Gadi's response was to refuse to answer requests for domains that you don't own, which didn't address the issue of whether or not the remote computer was a customer, or what kind of server that Joe was running. Your answer is the complete and correct one, at least for the technical issue of how you should br running your nameservers so that you avoid external abuse and reduce the probability of having your DNS servers compromised. It's taken us a while to get to this correct and complete answer, however. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
