White PapersThese attacks typically involve a large number of more than 32,000 open recursive name servers to reflect excessive query responses. An unknown, and probably unknowable, number of zombie machines are controlling and instigating the attack. It is probable that multiple actors are involved and that this is not controlled by a single entity, although it may have started out that way. By examining both the traffic to a reflector name server and the traffic from the name server, we have been able to understand with a great deal of detail the anatomy of these attacks.
The attack is designed to generate multiple Gigabits of traffic to any given victim for a prolonged period of time. This is fairly common in DDoS attacks. By engaging in a reflector attack, the actual controlling Bot, or the Bot that is generating traffic to the reflector, is often invisible to the victim. Additionally, by using name servers, the attacker has a substantial pool of reflectors to choose from for an almost infinite amount of time. Each reflector only generates a modest volume of traffic to the victim. But collectively, the volume is enormous. Furthermore, the size and scope of the attack can be modified by changing the parameters of the query.
WH I T E P A P E RAnatomy of Recent DNS ReflectorAttacks from the Victim andReflector Point of ViewVersion 1.0 / April 4, 2006Untitled DocumentWH I T E P A P E R1. EXECUTIVE SUMMARY32. ATTACKS AS SEEN FROM THE VICTIM32.1 SUMMARY32.2 TRAFFIC VOLUMES52.3 TRAFFIC ANALYSIS62.4 FILTERING OPTIONS83. ATTACKS AS SEEN FROM THE REFLECTOR83.1 SUMMARY83.2 TRAFFIC ANALYSIS94. FUNDAMENTAL PROBLEMS144.1 UDP144.2 DNS144.3 OPEN RECURSIVE DNS SERVERS ARE ONLY PART OF THE CHALLENGE154.4 SOURCE VALIDATION155. CONCLUSION166. REFERENCES16CO N T E N T SCOPYRIGHT NOTIFICATIONDISCLAIMER AND LIMITATION OF LIABILITYVeriSign, Inc. has made efforts to ensure the accuracy and completeness of the information in this document. However,VeriSign, Inc. makes no warranties of any kind (whether express, implied or statutory) with respect to the information con-tained herein. VeriSign, Inc. assumes no liability to any party for any loss or damage (whether direct or indirect) caused by anyerrors, omissions or statements of any kind contained in this document. Further, VeriSign, Inc. assumes no liability arising fromthe application or use of the product or service described herein and specifically disclaims any representation that the productsor services described do not infringe upon any existing or future intellectual property rights. Nothing herein grants the readerany license to make, use, or sell equipment or products constructed in accordance with this document. Finally, all rights andprivileges related to any intellectual property right described in this document are vested in the patent, trademark, or servicemark owner, and no other person may exercise such rights without express permission, authority, or license secured from thepatent, trademark, or service mark owner.VeriSign Inc. reserves the right to make changes to any information herein without further notice and disclaims any duty toprovide updates.NOTICE AND CAUTIONConcerning U.S. Patent or Trademark RightsThe inclusion in this document, the associated on-line file, or the associated software of any information covered by any patent,trademark, or service mark rights will not constitute nor imply a grant of, or authority to exercise, any right or privilege pro-tected by such patent, trademark, or service mark. All such rights and privileges are vested in the patent, trademark, or servicemark owner, and no other person may exercise such rights without express permission, authority, or license secured from thepatent, trademark, or service mark owner.April 4, 2006Written by Ken Silva, Frank Scalzo and Piet BarberUntitled DocumentWH I T E P A P E R31. Executive SummaryDistributed Denial of Service (DDoS) attacks are quite common on the Internet today.They have been known to generate tremendous volumes of traffic to the victims. Oftenthe attack can be thwarted with appropriate countermeasures or filters applied to routers.Recently there has been an increase in the number of attacks using a less common, butwell known, technique known as Distributed Reflector Denial of Service (DRDoS)attacks. Although not extremely rare, they are far less common than the traditionalDDoS attack method. DDoS attacks typically use a Bot network to control and execute the attack. Often times,this involves compromised machines which are usually controlled through malware or anopen exposure. These more recent attacks are no doubt controlled and executed by a Botnetwork; however, the Bots are not directly attacking servers. Instead, they send theirtraffic to a perfectly legitimate server with a DNS query and a forged source address. Thesource address used is the victim and all DNS query responses are directed to the victim.In this case also, the answer to the query is significantly larger than the question, therebyamplifying the magnitude of the attack. These more recent attacks are significantly larger, and take advantage of several keyelements of the Internet. The first is the protocol used. In this case, the User DatagramProtocol (UDP) is used. The UDP protocol is stateless by nature and does not requirethe client and server to have an established session. In this case, the servers in questionare DNS servers which require only a single packet in for a query and usually send onlya single packet in return for the answer. Since no validation or establishment of a sessionis required, these are susceptible to source address spoofing. So the reflecting machinesare usually not compromised, functioning as they were configured, and simplyresponding to the question asked to whom they believe asked the question. This report will outline details about these recent attacks. Many of the specific serversinvolved and the few compromised machines known to be involved have been obfuscatedsince they are not relevant to the analysis. Some of the queries are real since they arerelevant. This report will describe an analysis of an actual attack seen by a victim, as wellas an analysis of data seen by a reflector used in the attack. Finally, this report will lookat an extrapolation of estimates of traffic on the Internet due to these recent attacks, andsome of the fundamental problems that make these attacks possible.2. Attacks as Seen from the Victim2.1 SummaryThese attacks typically involve a large number of more than 32,000 open recursive nameservers to reflect excessive query responses. An unknown, and probably unknowable,number of zombie machines are controlling and instigating the attack. It is probable thatmultiple actors are involved and that this is not controlled by a single entity, although itmay have started out that way. By examining both the traffic to a reflector name serverand the traffic from the name server, we have been able to understand with a great dealof detail the anatomy of these attacks.Untitled DocumentWH I T E P A P E R4The attack is designed to generate multiple Gigabits of traffic to any given victim fora prolonged period of time. This is fairly common in DDoS attacks. By engaging ina reflector attack, the actual controlling Bot, or the Bot that is generating traffic to thereflector, is often invisible to the victim. Additionally, by using name servers, the attackerhas a substantial pool of reflectors to choose from for an almost infinite amount of time.Each reflector only generates a modest volume of traffic to the victim. But collectively,the volume is enormous. Furthermore, the size and scope of the attack can be modifiedby changing the parameters of the query. In this case, a number of scenarios were used. The first was using a compromised nameserver in South Africa to seed the attack. Once the name server was compromised, it hada zone added which contained a 4K byte record. That record when using a dig to viewfrom the original seed appears as follows:;; Warning: Message parser reports malformed message packet.; > DiG 9.2.5 > @209.204.165.200 e.tn.co.za any -c any +bufsize=10000; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;e.tn.co.za. ANY ANY;; ANSWER SECTION:e.tn.co.za. 20551 IN TXT xxxxxxxxxxxxxxxxx[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] ................................................................[snip] .............................................................................................................. ;; AUTHORITY SECTION:tn.co.za. 20551 IN NS ns1.genetic.co.za.;; Query time: 280 msec;; SERVER: 209.204.165.200#53(209.204.165.200);; WHEN: Wed Jan 4 12:25:11 2006;; MSG SIZE rcvd: 4028Untitled DocumentWH I T E P A P E R5Note that each line is actually 256 bytes in length. When querying for this record, eachDNS response packet is fragmented into three 1500 byte packets based on the MTU.That is then followed by 3 fragmented packets. The fragmented packets have thefragment bit set as they are coming from a normal responder. In order for this to beeffective, the reflector must support EDNS0, otherwise all packets would be limited to512 bytes (the UDP maximum for DNS). As such, this does somewhat limit the numberof possible reflectors, but only until the name server is upgraded to a later version of BIND. Figure 2-1: Attack Data Flow2.2 Traffic VolumesThe following data is taken from an attack actually seen on a victim server. The graphbelow is a 1% netflow sample showing the attack traffic. The 1% sampling means thisvictim actually received 2.2 Gbps of traffic.Figure 2-2: 1% Netflow of Actual AttackUntitled DocumentWH I T E P A P E R6An RRD Graph of the same attack also showing approximately 2 Gbps of attack traffic.Figure 2-3: SNMP Graph of Actual Attack TrafficThis particular victim host only had slightly more then 2 Gbps of bandwidth availableat the time of the attack. The attack was actually significantly larger, but much of it wasdropped by ISP routers due to congestion. ISPs were able to confirm that the ingresslinks into the upstream routers saw a traffic spike of more than 5 Gbps during the timeof the attack.2.3 Traffic AnalysisA typical DNS query packet is approximately 64 bytes. This particular query is 56 bytes.The response for the TXT RR that was used in this attack was 4,028 bytes. Thisrepresents a 72:1 attack amplification.The following graph is a graph of source and destination IP addresses talking tothe victim during the attack. This data is again based on a 1% netflow sample.Figure 2-4: Graph of Source Destination IP Addresses Based on 1% NetflowThe graph shows an increase of about 25,000 additional sources talking to the victimduring the attack. Analyzing a capture of 1 million packets, approximately 48 secondsof the attack, shows that the number of reflectors was actually 34,688. Random samplingwas performed to verify that the source IP addresses were actually open recursive DNSservers. Looking at a TTL histogram of the packets from a random sampling of sourcesalso implies that the traffic is really coming from the reflector. Analysis of the list ofreflectors shows very sequential IP addresses, indicating the list of reflectors was likelygenerated by a scan of the 200.0.0.0 to 217.255.255.255 address space.Untitled DocumentWH I T E P A P E R7The total traffic volume of 5 Gbps divided by the 34,688 reflectors indicates the averagereflector involved was sending approximately 144,142 bps, which equates to 13.5 packetsper second or 4.5 DNS responses per second. When the amplification factor is takeninto account the average reflector was receiving 2,287 bps. With a reflector seeing 2 kbpsof attack traffic inbound and 144 kbps of attack traffic outbound it is very unlikely thatan operator of a reflector would ever notice the attack. A capture file was analyzed toensure that there were not a small number of high volume reflectors skewing the average.The top reflector was only sending 4 DNS responses per second above the average;indicating a very small standard deviation from the mean.As a reflected attack there is very limited visibility into what is happening by thereflector. However, given the total traffic volume and the amplification factor the volumeof traffic that is being sent by the initiator of the attack can be calculated to beapproximately 79 Mbps.The domain name used in this attack was a .za domain name. Working with theappropriate Registry, ISP , and eventually the owner of the DNS server, it was confirmedthis DNS server was compromised, and had the TXT record maliciously installed.Interestingly, the domain had two authoritative DNS servers but only one had beencompromised. Looking at the attack traffic 65% of the packets were large DNS answers,35% were NXDomain responses. Because the response was larger then the standardEthernet MTU of 1500 bytes most of the reflectors sent the packet in three fragments.The duration of this attack was 24 minutes long. Analyzing the destination source portsof the traffic during this attack reveals that the attack was broken in the three distinctphases during the 24 minutes. During the first phase the destination port of the attacktraffic, set as the source port of the traffic from the initiator, is 666. During the secondphase the traffic immediately changes characteristics and is split between destination port666 and destination port 53. During the third phase the traffic immediately shifts to allport 53 traffic. The following graph is a breakdown of the destination ports over theattack duration.Figure 2-5: Graph of Destination Ports During AttackUntitled DocumentWH I T E P A P E R8It is worth mentioning that the attack traffic ramps up nearly instantaneously. Itrepresents vertical lines on almost every graph. It is also worth mentioning that when theattack changes characteristics the change is also almost immediate. This implies that thecommand and control infrastructure running the attack has very tight control over theinitiating hosts. Botnet command and control is commonly accomplished via InternetRelay Chat (IRC).2.4 Filtering OptionsThere are a number of possible filtering options that could theoretically be used toreduce the effects of this type of attack. Many of these filtering options have beendescribed in various public forums. The challenge is that an attack of this size needsto be filtered upstream on an ISP router, as the attack will likely saturate the victim sInternet circuits. There are very few networks that can absorb a 5 Gigabit DRDoS attackand filter it internally. One of the only techniques that can be used to filter this attackthat is commonly available on ISP router platforms is to filter out fragment packets sentto the victim host on the destination port.There are a number of challenges when working with an ISP to get appropriate filtersput into place. Many ISPs will only install filters while actually seeing attack traffic. Withan attack as short lived as 24 minutes it is difficult for many ISPs to respond and installeffective filtering in that time frame. Another challenge is that some router vendor highperformance interface cards lack the ability to filter on information as specific as themore fragments bit, and offset field. Once the filter is in place on the ISP side, manyISPs will remove the filter after a certain period of time with no attack traffic.3. Attacks as seen from the reflector3.1 SummaryA query log from a reflector was analyzed for the timeframe of January 11 throughFebruary 27. During that time the reflector sent out 1.9 million DNS answers that arebelieved to be attack related. The answers were destined to 1,593 hosts that are believedto be victims. 605 different queries were used to generate answers back toward thevictims. By estimating that this reflector is one of 30,000 used, a conservative numberbased on analysis of actual attacks, there is good reason to believe there have been a largenumber of 3 Gbps to 5 Gbps attacks during the period analyzed, and some that havereached over 7 Gbps, and 222 kpps. There is also good reason to believe that the attackpotential of this attack could be significantly higher by using more reflectors. With aconservative estimate of 500,000 available reflectors this could result in over 100 Gbpsof attack traffic.Untitled DocumentWH I T E P A P E R93.2 Traffic Analysis The graph below is a breakdown of attack queries per day seen by the reflector duringthe time period.Figure 3-1: Attack Queries Per Day Seen from 1 ReflectorNote that after February 15 there is a rapid ramp down, and no further attacks havebeen seen from this reflector. Further work needs to be done to identify if there wereany events that can be correlated to that date.This next graph shows the queries per second that were sent out by the reflector inquestion. The graph shows numbers very consistent with the average per reflectornumbers calculated previously.Figure 3-2: Week number corresponds to week of the year.Most of the attacks that have been analyzed used a 4 KB DNS response. There havealso been a large number of publicly reported attacks that also use a similar 4 KB DNSresponse. That being said, it is a good assumption that 4 KB DNS responses were beingsent. Further, the most common queries used in the attack were verified to be a 4 KBUntitled DocumentWH I T E P A P E R1 0TXT record. Given the packets per second sent graph, multiplied by 4 KB per response,multiplied by 8 bits per byte, results in a graph of probable attack traffic volume sent bythe single reflector studied in bits per second. Again these numbers are consistent withthe average per reflector numbers previously calculated.Figure 3-3: Week number corresponds to week of the year.The next graph is an extrapolation of the single reflector packets per second graphmultiplied by the assumed number of reflectors, 30,000. The number of assumedreflectors is consistent with multiple attacks that have been analyzed as well as publiclystated reports by other organizations. This graph represents an estimate of the actualattack traffic over the time period measured in packets per second. This graph isconsistent with analyzed attacks.Figure 3-4: Week number corresponds to week of the year.Untitled DocumentWH I T E P A P E R1 1This next graph is an extrapolation of bits per second of attack traffic. It is based on thequeries per second sent by the reflector, multiplied by 30,000 reflectors, multiplied by4 KB per response. This graph represents an estimate of the actual attack traffic over thetime period measured in bits per second. This graph is consistent with analyzed attacksas well as publicly stated attack reports by other organizations.Figure 3-5: Week number corresponds to week of the year.Given the above graph the traffic sent by the initiators of the attacks can be estimated.The following graph shows this estimation over the duration of the analysis. The graphshows that even the largest attack was generated with less then 130 Mbps of initiatingtraffic, and that was only a single event. The vast majority of these attacks could beinitiated by a single 100 Mbps attached compromised host. Given that the reflectorscompletely obscure any visibility into the initiators there is no way to know if theattack was initiated by a single host or thousands. It is more likely to have beenthousands, each passing small amounts of traffic as to be difficult to detect.Figure 3-6: Week number corresponds to week of the year.Untitled DocumentWH I T E P A P E R1 2This next graph is an extrapolation of attack potential in bits per second. It is based onthe queries per second sent by the reflector, multiplied by 500,000 reflectors, multipliedby 4 KB per response. This graph represents an estimate of how big the attack couldpotentially be. The 500,000 number is based on the fact that the attacks analyzed onlyappeared to use 6% of the Internet address space which would extrapolate to roughly500,000 potential reflectors. A 500,000 potential reflectors estimate is consistent withpublic claims made by other organizations. This graph shows that this attack could bescaled to 110 Gbps by adding reflectors. This would also involve a correspondingincrease in traffic sent from the initiating hosts to the reflectors. It is a reasonableassumption that 17 times the current number initiating hosts are available on theInternet. A 17 times increase in initiator traffic would represent a total of 2 Gbpsof initiator traffic.Figure 3-7: Week number corresponds to week of the year.The next chart represents the number of attack packets sent to each of the top 25 victimsby the single reflector. If we accept the assumptions of 30,000 reflectors and 4 KBanswers, then this number is also roughly the total Gigabits of attack traffic the top25 victims received over the time period analyzed.Figure 3-8: Attack Queries per Top 25 Victims From 1 RefelctorUntitled DocumentWH I T E P A P E R1 3Looking at the source ports used in the attacks seen by the reflector shows that 65,461different ports have been used. Less then 5% of the attack packets are used by one ofthe top 10 ports. The following chart is a break down of packets per port for the top10 ports.Figure 3-9: Top 10 Ports Used in AttacksThis graph makes the traffic seem very DNS related with port 53 being used. However,this is less then 5% of the traffic. This shows a very even distribution of the 65,461 portsin use. It is interesting that the second most common port is 6667 which is commonlyused by IRC.During the time period analyzed 605 different domain names were used in the queryto trigger the response packet that makes up the attacks. The following shows a relativedistribution of attack traffic per domain.Figure 3-10: Top 20 Domains Used in AttacksUntitled DocumentWH I T E P A P E R1 4When evaluated during the attack almost all of the domains had a 4 KB TXT RR. Anotable exception is the use of the Internet root . which is a 493 byte response. Thisis a significantly smaller amplification, but many more reflectors will answer for . .Interestingly recently there has been an increase in single queries for long domain namesthat appear to be garbage. Further work needs to be done to determine what if anysignificance these have. The following is an example list:bpniejaaguard0000dbaaabbaaabecehbpngjcaaguard0000dbaaabbaaabepklbpmlfcaaguard0000dhaaabbaaabfdefbpkfbeaaguard0000dhaaabbaaabegcobpblmeaaguard0000dbaaabbaaabhojebooodbaaguard0000dbaaabbaaabadckboefnhaaguard0000dhaaabbaaabckncbmajjeaaguard0000dhaaabbaaabfdadblhanlaaguard0000dbaaabbaaabbgllbkpkfoaaguard0000dbaaabbaaabbbhbbjhcagaaguard0000dbaaabbaaabgicebjfgkbaaguard0000dbaaabbaaabcdpdbjegobaaguard0000dbaaabbaaabalehbioacdaaguard0000dbaaabbaaabgjlibghppmaaguard0000dfaaabbaaabfbdkbgfhdoaaguard0000dhaaabbaaabceabbgckfcaaguard0000dbaaabbaaabaliebfoghoaaguard0000dbaaabbaaabbfgibfhekgaaguard0000dbaaabbaaabcpahbfeeiiaaguard0000dbaaabbaaabdoedbfbgdoaaguard0000dbaaabbaaabcepb4. Fundamental Problems4.1 UDPUDP is a protocol that is fundamentally vulnerable to reflected attacks. Without havinga 3 way handshake any UDP protocol that has a small query, large response single packettransaction is susceptible to this attack vector. DNS is a UDP protocol that is prone tomisuse by these types of attackers due to the large number of available open DNS serversthat can be used. Many other common UDP protocols should be evaluated to determineif there are single packet queries that can generate large responses. A short list of othercommon UDP protocols would include things like: SIP , NFS, SNMP , RADIUS, TFTP ,NTP , IRIS, and RTP . Most of these protocols are unlikely to be widely exposed to theInternet. Other UDP protocols are also unlikely to have the large enough number ofreflectors to allow attackers to remain unnoticed by operators of the reflectors.4.2 DNSThere are a tremendous number of open recursive DNS servers; most estimates put thenumber over 500,000. The solution to the open recursive DNS server problem is forDNS server operators to do a better job of securing DNS servers from this and othertypes of attack. Internet operators have for example been taking steps for years to secureopen SMTP relays for similar reasons. Reflective attacks have also been observed usingSMTP , and in particular bounce messages.For purposes of this discussion, there are two important types of DNS servers. An authoritative DNS server is a server which provides DNS answers for a public domainname. A recursive DNS server is a DNS server that looks up information on a client sUntitled DocumentWH I T E P A P E R1 5behalf by starting at the Internet root name servers and traversing the public DNS treeuntil it finds the appropriate authoritative DNS server, at which point the answer iscached and returned to the client. A number of steps can be taken in the operationof these DNS servers that can help mitigate the risks associated with reflector attacks.Authoritative and recursive DNS servers, for example, can be separated. Also, whileauthoritative DNS servers must accept DNS queries from anywhere on the Internet,disabling recursion will ensure that answers are provided only for domains they arehosting. This improves security both for the Internet as a whole, and for the authoritativeDNS server itself. Recursive DNS servers should avoid accepting DNS queries fromunknown sources on the Internet. Recursive DNS servers can be configured to not evenaccept a query, with an allow-query ACL, from outside of their own network. Simplyusing an allow-recursion ACL helps, but still leaves the host open to participate in sometypes of reflector attacks. The problem is there is no motivation for the server operatorsto go through the effort involved in securing the open recursive DNS servers. In mostcases the attack traffic is such low volume they do not even know it is happening. Anadditional challenge is that some of the open recursive servers are poorly implementedDNS proxies on SOHO network equipment.Further adding to the challenge is a strong trend to publishing more types of recordsin the public DNS infrastructure. Larger records being present in the public DNSnamespace means the attackers can skip the first step of breaking into a DNS server andpublishing a large RR. They can simply use a legitimate record that cannot be deleted.Some examples of larger records moving into DNS includes: DNSSEC, IPv6 addresses,Domain Keys and many other new anti-spam technologies that depend on publishingsecurity information in DNS.4.3 Open Recursive DNS Servers are only part of the challengeAttacks using a query for the Internet root . have been seen. This is particularlydisturbing as the record cannot be deleted, and even most authoritative name servers willanswer the query. The attack amplification is much smaller, but the number of reflectorsincreases dramatically. Using the BIND feature allow-recursion to limit where recursivequeries can come from still allows attackers to use information that is already in thatDNS servers cache. This means they simply have to find a large commonly cached RRto use. The RR set for .com is 504 bytes, there are probably easily identified records thatare longer. This is why recursive name servers should be configured to not even answerqueries from outside their network.4.4 Source ValidationThe IETF has published a best current practices document, BCP 38, specificallyaddressing what ISPs should do to filter ingress traffic to stop hosts from spoofing sourceaddresses. This attack vector, along with several others that the Internet has historicallyexperienced, depends completely on the attacker s ability to spoof the source IP addressof packets. Few large ISPs have implemented ingress filtering to make sure that packetscoming into their networks are not spoofed. Implementing this type of filteringrepresents a large change that many ISPs have resisted. There are a number of challengesinvolved with implementing BCP 38. The management of static ACLs on large numbersof customer interfaces on large numbers of routers is a difficult task. Strict RPF workswell, and alleviates the management overhead of managing ACLs. However, strict RPFonly works in limited cases, as it breaks asymmetric routing. The fact that there are anumber of systems on the Internet today that work because they are unknowinglyspoofing packets adds to the challenge of how and where to implement ingress filtering.Untitled DocumentWH I T E P A P E R1 6While this change may be a difficult and expensive change for ISPs to execute, it is oneof the few long term solutions that addresses reflected attacks, as well as several otherattack vectors. Even though BCP 38 has been around since 2000, these recent attacksrepresent an increasing threat to critical Internet infrastructure, and ingress filtering isone of the most effective mechanisms to prevent these attacks. Given the seriousness ofthis threat, and the length of time required for BCP 38 deployment, it is important forISP s to begin making real progress on deploying ingress filtering as soon as possible.5. ConclusionThis wave of attacks is demonstrative of the continuing evolution of Internet securitythreats, both in terms of size and complexity. The purpose of calling attention to thisincreasing threat is to encourage organizations to begin taking the necessary steps tosecure the Internet from this attack vector. To that end, network operators should securerecursive DNS servers, to deny DNS queries received from outside of their own network.SOHO router manufacturers should ensure that built-in DNS proxies only acceptqueries from appropriate clients. Many DNS software vendors provide for filteringwithin the daemon, all DNS software vendors should implement similar tools forappropriate filtering. Finally, and most importantly, ISP s should begin implementingBCP 38.6. References1. DNS RFCs, RFCs 882,883and 973,Domain Names Implementation andSpecification , P . Mockapetris 2. RFC 2671, Extension mechanisms for DNS (EDNS0) by P . Vixie3. RFC 768. User Datagram Protocol, J. Postel4. BCP38, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IPSource Address Spoofing, P . Ferguson and D. Senie5. RFC791, Internet Protocol6. Continuing Denial of Service Threat Posed by DNS Recursion, 16 Dec 2005,http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf7. Cisco IOS Configuration Guide, IOS Release 12.x, Configuration Guides andCommand references,http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/index.htm8. Distributed Reflection Denial of Service, http://grc.com/dos/drdos.htm 9. Securing an Internet Name Server, Housholder,/King/Silva,/Liu,http://www.cert.org/archive/pdf/dns.pdf 2006 VeriSign, Inc. All rights reserved. VeriSign, the VeriSign logo, Where it all comes together, i-Nav, and other trademarks, service marks, and designsare registered or unregistered trademarks of VeriSign and its subsidiaries in the United States and in foreign countries. Google is a tradmark of Google.Yahoo! is a trademark of Yahoo! Inc.04-20-06
