Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-reflectors-are-evil-02.txt

From: Dean Anderson <[email-masked]>
Date: Mon, 2 Oct 2006 17:38:38 -0400 (EDT)

I strongly oppose this draft.

I've read the draft.  It still asserts that __somehow__ the
amplification potential of authoritative servers is greatly reduced in
comparison with recursive servers.  There is no rational to support this
assertion and facts have been given that repudiate it. (e.g. large DNS
records such as SPF, In-addr; private recursors and authoritative
servers can produce the same size records and same amplification).
Indeed, private recursors and authoritative servers are prefereable for
DDOS attacks.

The claims that public recursive nameservers are somehow worse has been 
refuted: e.g.
====================
> An attack which uses EDNS0-capable public recursive nameservers has  
> the potential to achieve 60-to-80-fold amplification.

An attack which uses EDNS0-capable private recursive nameservers also
has the potential to achieve 60-to-80-fold amplification.

An attack which uses EDNS0-capable authoritative nameservers also has
the potential to achieve 60-to-80-fold amplification.
==================== 

Note that one cannot block internal private recursors, nor authoritative
servers. So, if damage were the actual goal, one would not use public
recursors, but the select servers that can't be blocked or mitigated.  
One would also sensibly select servers for which scanning in preparation
of an attack would not reveal the attacker.

One doesn't need an open recursor to mount the attack at all.  Private
recursors or authoritative are preferable, in fact, because they can't
be blocked or mitigated, while in contrast, public recursors require
searching/scanning or a distribution of a centralized database which
reveals the perpetrator, and can be mitigated.

Indeed, the issues raised in these four messages are still unresolved
and unaddressed:

http://darkwing.uoregon.edu/~llynch/dnsop/msg03702.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03703.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03707.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03708.html

>  Since the majority of documented examples of reflection attacks (if  
>  not all of them) do involve open recursive nameservers,

I note also the comparison with open relay attacks. For almost 10 years,
open relay attacks have been exclusively performed by non-commercial
attackers. No genuine bulk commercial emailer ever abused an open relay
of ours in almost 10 years of open relay operations.  I tracked
solitications of abuse of open relays back to anti-spammers (see
http://www.iadl.org/cn/cn-story.html, particularly Joshua and the
Cleveland Gang).  I found that ORBS.ORG and Osirusoft.org were
instrumental in the abuse of open relays. (see www.iadl.org)  Indeed,
since the closure of these sites in 2003, open relay abuse has dropped
to nearly nothing. There are still occasional abuse activities but
nothing substantial.

In retrospect, its clear that the abusers of open relays were mis-guided
anti-spammers trying to 'prove' the harms of open relays. I think that
open-recursor attacks are performed by a similarly misguided group,
because one can more easily find authoritative servers and private
recursors to mount such an attack, and then there is no mitigation.  
These types of DNS servers are easier to find than open recursors, yet
for some reason, the "abusers" choose open recursors. That fact suggests
an agenda similar to the open relay abusers: Actual harm isn't the goal,
rather attemption to prove the possibility of a specific kind of harm is
the goal.

This draft similarly doesn't address a real problem, but a contrived
problem, for which there is no actual harm but for the actions of those
trying to 'prove' the harm.

Therefore, I don't think this draft should be advanced.

		--Dean

On Tue, 19 Sep 2006 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations Working Group of the IETF.
> 
> 	Title		: Preventing Use of Recursive Nameservers in Reflector Attacks
> 	Author(s)	: J. Damas, F. Neves
> 	Filename	: draft-ietf-dnsop-reflectors-are-evil-02.txt
> 	Pages		: 8
> 	Date		: 2006-9-19
> 	
> This document describes the use of default configured recursive
>    nameservers as reflectors on DOS attacks.  Recommended configuration
>    as measures to mitigate the attack are given.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-02.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ietf-dnsop-reflectors-are-evil-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-dnsop-reflectors-are-evil-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Joe Abley <[email-masked]>
Date: Mon, 2 Oct 2006 18:08:55 -0400

On 2-Oct-2006, at 17:38, Dean Anderson wrote:

> comparison with recursive servers.

The opportunity to do evil is greatly reduced if attackers are forced  
to exploit either authority servers or private recursive servers.

If authority servers are used, finding a large number of authority  
servers which contain records that provide the required amplification  
is harder than finding a large number of open recursive servers.  
Using such servers will also involve sending a different query to  
each server in order to exploit the particular (QNAME, QTYPE) tuple  
which provides the required amplification, which means a single  
botnet with a single set of marching orders can't be used to  
originate the query traffic, thus increasing the logistical  
difficulty in launching the attack.

If private recursive servers are used then in order to gain  
amplification comparable with the attacks which exploit open servers  
the target must be within the corresponding private domain of the  
recursive server. Since it's rare for more than a small handful of  
private recursive servers to serve a single private subset of the  
Internet, this reduces the potential number of sources of attack  
traffic to a number which can probably be dealt with (and which are  
probably also operated by the same set of technicians).

The opportunity to launch a reflection attack of the type described  
in the draft is greatly reduced if no open recursive nameservers are  
available.

If you can describe other mechanisms by which an equivalent attack  
could be launched with similar ease to those that have been observed  
to exploit open recursive nameservers, then you might have a point  
worthy of consideration in this draft. However, the objection you  
voiced (which I am replying to) appears to be based on an inadequate  
understanding of the attacks in question. I hope this clarification  
is useful.

Joe

.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 2 Oct 2006 23:34:39 -0400 (EDT)

There is nothing in Joe's assertions that wasn't refuted in May. So, at
the risk of repeating the discussion from May, here is a version-02
specific version:

> is harder than finding a large number of open recursive servers.  

I think not. Finding authority servers for large in-addr responses is
just a walk of the in-addr.arpa.  One can get forward zones from a
variety of places to find large SPF, DNSSEC or TXT records.  
Furthermore, the search for such records is completely innocent, while
the search for open recursors is suspicious. [one can put up traps for
the latter search]

Private internal recursors are found by a call to the ISP support line.  
Which ISP to call depend only on the target, and are easily found
through routeviews and whois and web pages.  This question will be
happily answered by first level support. It may even be available on the
ISP web site.

By contrast, to find open recursors, you usually need to walk all of IP,
though you could still walk in-addr and the forward zones as before, but
searching for open recursors will leave log entries that tend to
identify the searcher. By contrast, querying in-addr records or SPF
records from authority servers is entirely innocent.

Open recursors that aren't also authority servers are very difficult to
find. One needs to walk all of IP to see if port 53 responds.  That kind
of search will be noticed by somebody.  Ask the open relay scanners.

> Using such servers will also involve sending a different query to each
> server in order to exploit the particular (QNAME, QTYPE) tuple which
> provides the required amplification, which means a single botnet with
> a single set of marching orders can't be used to originate the query
> traffic, thus increasing the logistical difficulty in launching the
> attack.

As previously described in May, a botnet can easily handle the marching
orders necessary. The amplification is dependent only on the number of
queries sent.  A list of 25, 100, 200, 25000,+++ tuples is easily within
the payload of a modern botnet.  One might not even need very many
tuples. A single, high bandwidth server might be sufficient.  Try
blocking all of say, MSN's nameservers or the nameservers of some other
top bandwidth domain. [BTW, DNS Anycast makes this attack worse, too,
but I already previously pointed that out in May. I see this too, was
ignored, in draft 02.]

> probably also operated by the same set of technicians).

Every ISP has 'private' recusors.  Those recursors are more "deadly" to
that ISPs customers for two reasons: The customer can't easily block the
traffic, and that server has more bandwidth to the customer than, say,
some open recursor half way around the world.

> The opportunity to launch a reflection attack of the type described in
> the draft is greatly reduced if no open recursive nameservers are
> available.

This is mantra. Repeating it does not make it true. I suppose, as was
the case with the open relay experience, the mantra will grow more
insistent, but no more true.  As Gauss said, 'fear the howls of the
boeotians.'

The opportunity to launch a reflection attack is the same for all types.  
Every server that has a large record offers an opportunity for
reflection attack.  The mitigation is close to zero for authority
servers and private recurors. The game-theory choice for the bad guy is
easy: pick the target ISP private recursor or search the authority
servers for large records.  Choosing ordinary open recursors is a
distant third because of the added risk of discovery and the mitigation
options at the target.

And finally, a public or private recursor needs a large record to start
the attack. That record is best obtained from a legitimate authority
record.  But that authority server, once found, can be directly used for
the attack if it has sufficient bandwidth. That authority server won't
be able to stop the attack except by removing the legitimately large
record, or by blocking incoming DNS queries. Neither option is going to
be palatable for, say MSN or Some Large Domain(SLD). Probably, they
won't do it if the record is important to them.

Strangely, the existing attacks that I know of from the Nanog thread,
started by using a cracked server to create an 8Kb TXT record for the
attack. This crack is the hardest part of the attack, and it leaves a
huge forensic trail, and is completely unnecessary to conduct the
attack. The attackers in that case were very stupid, and hadn't really
thought through the attack. Almost exactly the same analytical behavior
of another group of miscreants. One wonders if it could be the same
group.

		--Dean

.

---

From: Matt Larson <[email-masked]>
Date: Tue, 3 Oct 2006 05:58:28 -0400

On Mon, 02 Oct 2006, Dean Anderson wrote:
> Finding authority servers for large in-addr responses is

That is all true.  However, I am extremely dubious that today--right
now--one could mount a reflector attack using only authoritative
servers that would equal the magnitude of the attacks seen at the
beginning of this year that used open recursive servers.  To mount an
attack equivalent to those already seen, one would need to find tens
of thousands of authoritative servers able to produce a 4K response.
Every byte in the response size is significant, given the large number
of reflectors involved.  The bar has already been set at 4Kb, so one
needs to find at least ~34,500 authoritative servers with responses at
least that large to equal this year's earlier attacks.

(The problem is actually worse, because the number of open recursive
name servers has been estimated at around half a million by multiple
sources, so that's the current theoretical worst case, an even harder
number to reach using authoritative servers.)

Can you point us to even one 4Kb response from an authoritative
server?

> of search will be noticed by somebody.  Ask the open relay scanners.

I highly doubt that most networks are sufficiently instrumented and
monitored to detect even a network scan moving sequentially through
the address space.  If one went to the trouble to scan address space
in a random order, such a scan would be even harder to detect.

> of another group of miscreants. One wonders if it could be the same

The attack actually used a 4Kb TXT record and, contrary to your
opinion, the attack was quite sophisticated and showed attackers with
tight C&C who adapted in real time.  More information is available in
a presentation from VeriSign given at NANOG 37 in San Jose; please see
http://www.nanog.org/mtg-0606/scalzo.html.

Matt
.

---

From: Alexander Gall <[email-masked]>
Date: Tue, 3 Oct 2006 14:21:23 +0200

> Can you point us to even one 4Kb response from an authoritative

This one is close:

; <<>> DiG 9.4.0b1 <<>> @192.134.0.49 195.in-addr.arpa. any +dnssec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1806
;; flags: qr aa rd; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 17
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;195.in-addr.arpa.		IN	ANY

;; ANSWER SECTION:
195.in-addr.arpa.	172800	IN	SOA	ns-pri.ripe.net. ops.ripe.net. 2006100353 43200 7200 1209600 7200
195.in-addr.arpa.	172800	IN	RRSIG	SOA 5 3 172800 20061102102216 20061003102216 26612 195.in-addr.arpa. V0esxFs3uzdS0I+dyfe1ncIGak7MMEY0hLrHcTO7fqhxauIklJkhTnqG 0/VF4qiWEw1SiGWjp76dFIYYbnmrt1KYUY5vixyLV4XD34jCsjze1b/K +++i5Hm1fTjuaqFqTNN207s3rhngE7kxlJsw3k2x1hi6JsW95XPcwxoa 0aDFAiVKfKNAJe1sMIzyDMyebzl3rrP9
195.in-addr.arpa.	172800	IN	NS	tinnie.arin.net.
195.in-addr.arpa.	172800	IN	NS	ns3.nic.fr.
195.in-addr.arpa.	172800	IN	NS	sec1.apnic.net.
195.in-addr.arpa.	172800	IN	NS	sec3.apnic.net.
195.in-addr.arpa.	172800	IN	NS	sunic.sunet.se.
195.in-addr.arpa.	172800	IN	NS	ns-ext.isc.org.
195.in-addr.arpa.	172800	IN	NS	ns-pri.ripe.net.
195.in-addr.arpa.	172800	IN	RRSIG	NS 5 3 172800 20061102102216 20061003102216 26612 195.in-addr.arpa. OSO/7t1Dj4DMYy8nnwECk9rHmGUPeqkDHjgZXDC27ksfMagLqHDl+ZTJ cKeSyq1M1P632kJ2jtER3Dauk/mGtYmVjwXZ5dGfftHKnh6wuFxo95BU pjMZEl6+KojakdZILOLNrYkm0QVPzGsbpa9wq9v8lPFwIAy7xx2eMKtH caPP0YerMO28HiFWoTbU4dBTCdcgklF+
195.in-addr.arpa.	7200	IN	NSEC	10.0.195.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY
195.in-addr.arpa.	7200	IN	RRSIG	NSEC 5 3 7200 20061102102216 20061003102216 26612 195.in-addr.arpa. BtKF1tVnQaTtZMbdE/y54vMuutxgm8QXsM9hbzyN40sZM7pAIIXdE+sM o2stuznuWxTA2ZdQfZ5ybFHNrbKuzcqExuQ8cW+hVc3hiZrQLVM8yYlD paxvbPx2wWwqMdX1f1o8Zr4LkKMQ3UCzQ0vAkyi1aQmiz4ArK9eKWoOv vO/hBF6Uv9HPlc3g6B6HtzLWIUJsVBP9
195.in-addr.arpa.	3600	IN	DNSKEY	257 3 5 AwEAAaMN4kOrGaiHJBikvcf+mhPxzprL85Q40VA0hbRca8FDDn6Xlkuj 95Nizy2vMrOy1MjIjo7a+GACGp6C/Rdj6nDimsRrUBr/G/dq+zBgg8qv RXWJZhx+zNCgkfv9gs1BeRlPnjXr1K/x5viTzQRDK3SYfHiCMVNxuYN+ T7kniDLxQRUI/ASF3YxqNQ+Oo+T5L6nYtO7uLeAUdxzToRdIHaeyiSnq 52boA/3Yg6X8Kbo1uAUpeU4QDD7bOwq+obmaToLUm/FvNUKx0l9U2P2I tcsqRCHQut/RxK2pj8GGRDCDco1J5UAi7hiwP1eEWmbigbPnDQg++QDj egV39vTJQ2c=
195.in-addr.arpa.	3600	IN	DNSKEY	256 3 5 AQO/m4C8ktcSkEFAyhxNIPTliVqsjepVqhXcK/IpSXzZHDFYTHfpi91M zKnyQ7WxJDtPYecEaxcObGXeY6BiU+/Kcm3g2QwxszRBDd338EoInxun ku25MN4T+P76PquQtrhnnQn6jOceP5bbocSbkKldiPkxc2RI4Vru22l5 KEQqCYpO/lb6QHO2p8iIS87vmbknP6eLYls=
195.in-addr.arpa.	3600	IN	DNSKEY	256 3 5 AwEAAfPuhijNQG3Pbk2FGe6lGzGsBZR3qDiEWruyanast2JCEaC10Ox+ Hi4tcVR7oYMpAwdtQClpx/F/cy8W/U9HN60a+qh+WVj+gWlFeDYbpIW1 7qg3tg2lltQpDi2Md2O0c4K1YkdX1U1O+doLCt+gRqBfc5O1Tx0X8snN mE0qdk95kWOkcj+LZnFEmAtHZrweqIT4lhpPnQ==
195.in-addr.arpa.	3600	IN	DNSKEY	257 3 5 AQOyc738W3Vh1b23oPnoQZCOA3OVmm3FUSLckfaG0azm8ffu2igo2GnN NnwHLlMhLCPWJDCcVfUkXlwNgpk9OQQnndTvk5QP7iEhU/ynzAO1o4SK ctWITnRIMO8vOethiIBkpArrLpvSsYqIKpUdIT9Qb/tCyBHtwUCf89E2 19R0EbiF3bLacN5czb3RaxV6Mu4/Hl/q3R9ggjZ8HyakYz7zceB20+YO T32eKS1Gc59cIFRcLLqGjV6+vM2CfDHk5EnicZ3zrWjeGFAQUV6JhTGq HmNFrRBVA+6PoSYUUP2vEsFgN6ESZGKF03ySz8hGMJ+8v7ZnelLlHhC1 H3bPwDVr
195.in-addr.arpa.	3600	IN	RRSIG	DNSKEY 5 3 3600 20061102102216 20061003102216 6810 195.in-addr.arpa. DemjAyV2kU6ZXKO9o0sxPZ4W96ST7oUEN740/7B7L7XLRVP3dOcmlB+f QqI3fAvBJ377KYLtZosVwsenT+OZN/TBqVLD1Hp1yFiaZ8X4vL4Z7RJq AzXknGAcalhM+HlMuNS2j8IojuMJCeBCRwoyKo09o2WCcxIg2fy8bQqu 98YdBFtB+TH8Cv7BlRQBtpt/YZM0hCeEggNOuA6Aum6nUoruI6Bk9+FI UJDFCvuJeT9jsXWFevBg995n/BrWGFDTwOjkDbCb2RoM8aFiyX5uaIfx Q4xD009YuOoJ3Rmx+rIcQbGw3UIz8Snvwn1iQX+Dz7TyUhdgq9X/cGCf uxkBQg==
195.in-addr.arpa.	3600	IN	RRSIG	DNSKEY 5 3 3600 20061102102216 20061003102216 22747 195.in-addr.arpa. HYVm7MCpHheT67rXjDHS8yTgaxIjtAS1w98ywXhc5IZcIA21+qOmLeua RMvKCtFjxMxi64TXuVzohXCR9ZARUmYy7f4HKUxp6sWpSFj3Q036Xb+2 Jy8MxKLm2dOn/vXw1IYIzSVXyjKsWQrftfm7ydDv/Ms9dPWAQ7k92sT5 FoZB6LMwMheLJwilq61q0GT2gi2Mq927gnt4ffdx3ZXzKk7Ba/fbTRwT KU0a+GzjQd4RvyqVSP2grDR8LW+upawcp02YfvMvM1rbqg2OJmzO7XBJ i3vk84vchPFHxfnDLBB4/Ssj72ZA9FGkCvT/x8pYntolmiD3LApYQWRS Dgu7cA==
195.in-addr.arpa.	3600	IN	RRSIG	DNSKEY 5 3 3600 20061102102216 20061003102216 26612 195.in-addr.arpa. OJfF6LOoQaMx0muoEeyDUkDTSTkHLyMinuSFeVdp+ITA9Ig5Uu9JNVML dxKBN2BgQr66ThS1eCeohEllswtFJaDmHBHHqZ5IhkHOyPqm7F4ji7xi TH7RhMN4DO5TFMq1hcZkyIeFueNx4cNPN7Xc1ZaRKNqME6tuhY/gF8pX mWrjZsifNE2KUOAEC13DCwlF+xk66nGs

;; ADDITIONAL SECTION:
ns3.nic.fr.		172800	IN	A	192.134.0.49
ns3.nic.fr.		172800	IN	AAAA	2001:660:3006:1::1:1
sec1.apnic.net.		5010	IN	A	202.12.29.59
sec3.apnic.net.		1494	IN	A	202.12.28.140
sunic.sunet.se.		151449	IN	A	192.36.125.2
sunic.sunet.se.		65113	IN	AAAA	2001:6b0:7::2
ns-ext.isc.org.		76900	IN	A	204.152.184.64
ns-ext.isc.org.		170531	IN	AAAA	2001:4f8:0:2::13
ns-pri.ripe.net.	172800	IN	A	193.0.0.195
ns-pri.ripe.net.	172800	IN	AAAA	2001:610:240:0:53::3
tinnie.arin.net.	8661	IN	A	199.43.0.195
tinnie.arin.net.	1314	IN	AAAA	2001:440:2000:1::22
195.in-addr.arpa.	3600	IN	DNSKEY	256 3 5 AwEAAfPuhijNQG3Pbk2FGe6lGzGsBZR3qDiEWruyanast2JCEaC10Ox+ Hi4tcVR7oYMpAwdtQClpx/F/cy8W/U9HN60a+qh+WVj+gWlFeDYbpIW1 7qg3tg2lltQpDi2Md2O0c4K1YkdX1U1O+doLCt+gRqBfc5O1Tx0X8snN mE0qdk95kWOkcj+LZnFEmAtHZrweqIT4lhpPnQ==
195.in-addr.arpa.	3600	IN	DNSKEY	257 3 5 AQOyc738W3Vh1b23oPnoQZCOA3OVmm3FUSLckfaG0azm8ffu2igo2GnN NnwHLlMhLCPWJDCcVfUkXlwNgpk9OQQnndTvk5QP7iEhU/ynzAO1o4SK ctWITnRIMO8vOethiIBkpArrLpvSsYqIKpUdIT9Qb/tCyBHtwUCf89E2 19R0EbiF3bLacN5czb3RaxV6Mu4/Hl/q3R9ggjZ8HyakYz7zceB20+YO T32eKS1Gc59cIFRcLLqGjV6+vM2CfDHk5EnicZ3zrWjeGFAQUV6JhTGq HmNFrRBVA+6PoSYUUP2vEsFgN6ESZGKF03ySz8hGMJ+8v7ZnelLlHhC1 H3bPwDVr
195.in-addr.arpa.	3600	IN	DNSKEY	257 3 5 AwEAAaMN4kOrGaiHJBikvcf+mhPxzprL85Q40VA0hbRca8FDDn6Xlkuj 95Nizy2vMrOy1MjIjo7a+GACGp6C/Rdj6nDimsRrUBr/G/dq+zBgg8qv RXWJZhx+zNCgkfv9gs1BeRlPnjXr1K/x5viTzQRDK3SYfHiCMVNxuYN+ T7kniDLxQRUI/ASF3YxqNQ+Oo+T5L6nYtO7uLeAUdxzToRdIHaeyiSnq 52boA/3Yg6X8Kbo1uAUpeU4QDD7bOwq+obmaToLUm/FvNUKx0l9U2P2I tcsqRCHQut/RxK2pj8GGRDCDco1J5UAi7hiwP1eEWmbigbPnDQg++QDj egV39vTJQ2c=
195.in-addr.arpa.	3600	IN	DNSKEY	256 3 5 AQO/m4C8ktcSkEFAyhxNIPTliVqsjepVqhXcK/IpSXzZHDFYTHfpi91M zKnyQ7WxJDtPYecEaxcObGXeY6BiU+/Kcm3g2QwxszRBDd338EoInxun ku25MN4T+P76PquQtrhnnQn6jOceP5bbocSbkKldiPkxc2RI4Vru22l5 KEQqCYpO/lb6QHO2p8iIS87vmbknP6eLYls=

;; Query time: 32 msec
;; SERVER: 192.134.0.49#53(192.134.0.49)
;; WHEN: Tue Oct  3 14:15:27 2006
;; MSG SIZE  rcvd: 3736

--
Alex

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 3 Oct 2006 15:33:07 +0200

> 195.in-addr.arpa.	172800	IN	NS	ns-pri.ripe.net.

<smile>
Can you now point to the remaining  34,493 other authoritative  
servers needed to launch the attack of the magnitude that Matt was  
referring to. (There are reverse-address-space entries that have an  
insane number of PTR RRs for virtual servers, you may find a fair  
number of those servers too)
</smile>

On the topic:
I support the document with the understanding that this is not a  
magic bullet. IMHO the document does not claim that.

I am not saying that Dean is incorrect. It is possible to use  
authoritative servers to launch attacks. Given sufficient  
amplification --which will be easier with DNSSEC deployed--, given  
sufficient authoritative servers, given sufficient bots those attacks  
can (shall?) be damaging.  As Matt just 'doubted', the problem caused  
by open recursive servers is of another order of magnitude than all  
the other attacks (currently). For me the trade-off between patching  
this problem and having open-recursive servers available for  
troubleshooting is in the advantage of closing the open-recursive  
servers.

Obviously proper source origination of UDP is the answer. But even in  
the case of universal BCP38 deployment a big botnet with an  
appropriate control channel might be bursting away queries with valid  
source addresses to one specific host might generate significant  
problems.

I don't like that we are at the point where this document is needed,  
but I do consent.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Oct 2006 16:42:28 +0200

On Tue, Oct 03, 2006 at 03:33:07PM +0200,
 Olaf M. Kolkman <[email-masked]> wrote 
 a message of 101 lines which said:

> referring to.

There is no name server like our 192.134.0.49 :-)

.

---

From: John Kristoff <[email-masked]>
Date: Tue, 3 Oct 2006 10:46:41 -0500

On Mon, 2 Oct 2006 23:34:39 -0400 (EDT)
Dean Anderson <[email-masked]> wrote:

> Open recursors that aren't also authority servers are very difficult
> to find. One needs to walk all of IP to see if port 53 responds.

Scanning address space for this sort of thing isn't too terribly
difficult and we know of at least one person who publicly claimed to
have done it for the entire public Internet address space:

  Communications of the ACM, June 2006
  Explorations in Namespace: White-Hat Hacking Across the Domain Name System
  Dan Kaminsky

If one has access to an authoritative server, watching what queries
it is one way to build a list of potential open recursors.  You have
to probe them to verify that they are in fact open and you may not be
able to tell if they are authoritative for anything however.

Another way, for those unfortunate souls who have the problem, is to
collect the list of source addresses used in a reflection attack that
were already found by someone else.

It would be interesting to know, if there were a way to determine,
what percentage of recursors are also authoritative for something.
Going the other way is pretty easy and the numbers have been shown
elsewhere.

> That kind of search will be noticed by somebody.  Ask the open relay
> scanners.

Evidence suggests otherwise.  Did you notice any probes a few months
ago to:

  130.105.19.3
  130.105.11.3
  198.3.136.10

I've done some extensively probing (in the millions) for open recursors
to large sets of addresses (sound found using the example methods above)
and I've gotten a single email from a remote admin wondering what was
going on.  In fact, their inquiry was only for a corner case fingerprint
attempt.  They didn't realize they were even running an open recursor and
that it had been used in a reflective amplification attack.  Furthermore,
I had later found out this open recursor was not authoriative for anything,
at least not facing the public Internet.  While it is possible that there
were bots internal to that network using it for the attack, it seems very
unlikely.  Accepting that, one can easily surmise how that open recursor
was found by the attacker.

FYI... Duane Wessels gave a nice, concise talk about his work in finding
open resolvers and I highly recommend reviewing the slides if you haven't
seen them yet.

  <http://public.oarci.net/files/wessels-openresolvers.pdf>

John
.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 3 Oct 2006 15:33:07 +0200

<smile>

On the topic:

--Olaf

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Oct 2006 09:10:08 +0300 (EEST)

On Tue, 3 Oct 2006, Olaf M. Kolkman wrote:
> I am not saying that Dean is incorrect. It is possible to use authoritative 
> servers to launch attacks. Given sufficient amplification --which will be 
> easier with DNSSEC deployed--, given sufficient authoritative servers, given 
> sufficient bots those attacks can (shall?) be damaging.  As Matt just 
> 'doubted', the problem caused by open recursive servers is of another order 
> of magnitude than all the other attacks (currently). For me the trade-off 
> between patching this problem and having open-recursive servers available for 
> troubleshooting is in the advantage of closing the open-recursive servers.

FWIW, I've (also) made the argument that this document should include 
both the authoritative and open recursive server attacks.  It is 
unfortunate that we'll (be that dnsop or dnsext) need to write another 
document on how to reduce the authoritative server attack vector. 
But given that the consensus seems to fast-track this document as its 
recommendations are less controversial and the impact is more 
significant, this approach also seems acceptable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Thu, 5 Oct 2006 12:20:40 -0400 (EDT)

> Evidence suggests otherwise.  Did you notice any probes a few months

Actually, everyone who does this scanning, is noticed by _some_ one.  
Some complain, some just have logs. Many have logs that are either not
reviewed, but exist, or are reviewed and noticed, but no complaints are
issued.

As I told you in May, I'm not one of the people looking for this
scanning at the moment. However, like many, I do keep logs.  No doubt
your scanning generated some log messages that could be retrieved to
identify you as the scanner. 

Below you note that your scanning has also been noticed and complained
of--and I probably wouldn't initially suspect ultradns of bad
intentions, and wouldn't complain even if I had noticed.  This seems to
refute your claim that such scanning can't be detected.  Your claim of
non-detection is somewhat similar to claims made by some open relay
zealots.  Some people back then actually, genuinely believed that open
relay abuse couldn't be detected, and performed abuse from their desktop
work computers. (see information about Chris Neill at www.iadl.org.)
Neill was particularly obtuse in that he continued abuse even after he
was notified that we could detect his abuse, and was told to stop by his
management. I recall he was kind of stunned by the revelation, but he
continued abuse until he was fired, anyway.

I also note that two open relay anti-spam sites that claimed to be
"legitimate open relay scanners" were involved in conducting the abuse
of open relays.  They used their "anti-spam" moniker as a cover for
their abuse activities.

If public DNS recursors were to become a problem of abuse, operators
have the same recourse as did open relay operators:  They change IP
addresses occasionally and distribute those changes to customers/users.  
Then abusers have to continuously scan for such servers, and this
scanning will be both detectable and non-scalable.  (One can't keep
scanning the entire internet and not be noticed, especially once people
begin actively looking for scanning)  Similarly, open recursor scanning
will become anathema just like open relay scanning. People will start
watching for route cache entries to UDP port 53 instead of (or in
addition to) TCP port 25, and setup up traps at UDP 53 to detect
scanners, etc.  So there is already a solution to open recursor abuse.

Of course, none of this works for the private recursors or the authority
servers. As explained, this is why abusers interested in real harm would
choose these servers. I'm sorry I don't have any solutions for these
cases. I'm thinking about it, though.  I think that one must go after
the launch mechanism. Either a host controlled legitimately by the
attacker or a botnet.  One has to follow the botnet to get the botnet
operator.

> I've done some extensively probing (in the millions) for open
> recursors to large sets of addresses (sound found using the example
> methods above) and I've gotten a single email from a remote admin
> wondering what was going on.

And its not even a big problem that anyone is looking for in their logs.
Yet someone still noticed.

> While it is possible that there were bots internal to that network
> using it for the attack, it seems very unlikely.

I don't know why this would be unlikely.  It is also possible the
attacker knew something of this network and this server.  Maybe one
should query to see if they had any disgruntled employees or
ex-employees or customers.

> Accepting that, one can easily surmise how that open recursor was
> found by the attacker.

Such large scans are recorded in various logs, even if they aren't
generating complaints at present.  However, perhaps we should encourage
a lot of people should go back through their logs to see if we can find
the scanner and identify the culprit of these attacks.

> FYI... Duane Wessels gave a nice, concise talk about his work in
> finding open resolvers and I highly recommend reviewing the slides if
> you haven't seen them yet.
> 

Thanks, will do.

.

---

From: John Kristoff <[email-masked]>
Date: Thu, 5 Oct 2006 12:09:48 -0500

On Thu, 5 Oct 2006 12:20:40 -0400 (EDT)
Dean Anderson <[email-masked]> wrote:

> --and I probably wouldn't initially suspect ultradns of bad
> intentions, and wouldn't complain even if I had noticed.  This seems
> to refute your claim that such scanning can't be detected.  Your

Although we've done some probes from UltraDNS systems, the millions of
probes I was referring to did not originate from an UltraDNS system.
And while I'd like to think UltraDNS (now Neustar) is widely known,
generally trusted and respected, thank you, many people, even those
responsible for DNS within their organization, don't know who we are.

> > wondering what was going on. [[ In fact, their inquiry was only for
    a corner case fingerprint attempt.  They didn't realize they were
    even running an open recursor and that it had been used in a
    reflective amplification attack.  Furthermore, I had later found
    out this open recursor was not authoriative for anything, at least
    not facing the public Internet. ]]

> And its not even a big problem that anyone is looking for in their
> logs. Yet someone still noticed.

I fixed that quote for you. :-)

> generating complaints at present.  However, perhaps we should
> encourage a lot of people should go back through their logs to see if
> we can find the scanner and identify the culprit of these attacks.

That might be useful.  However, in my experience many DNS operators
are not logging queries.  That is beginning to change slowly as the
value of having that data is being realized (and not just for this
issue) for those that can enable it.  Some have resorted to passive
packet capture.  Duane Wessels (again), had an interesting idea for
a "dnsflow" system, that might operate like NetFlow, generating
summary DNS query and/or answer data to a collector.  I had made the
suggestion for a popular implementation to generate "sampled" query
log messages.  This an interesting side discussion and might be
better put on a more operation-oriented list though.

Please note, I have made no claim that probing cannot be detected as
you stated.  I do suggest that this sort of probing is not currently
being detected by an overwhelming majority of operators.

John
.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Oct 2006 11:41:22 -0700

On Oct 5, 2006, at 10:09 AM, John Kristoff wrote:
>
> Please note, I have made no claim that probing cannot be detected  
> as you stated.  I do suggest that this sort of probing is not  
> currently being detected by an overwhelming majority of operators.

SPF script offers a means to covertly scan for DNS.  This script is  
executed at each access point by spam filter plug-ins seeking  
additional message related information.  The queries created by this  
macro rich SPF script conveys information to a bad actor without any  
of this looking nefarious.  Requests are initiated by the victim with  
knowledge of DNS placement.

http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt

In addition, the DDoS amplification possible using SPF dwarfs the  
attack that might be possible using just a DNS reflector method.  Of  
course, SPF can also query a sequence of 24 large text records per  
message, where these SPF records also often use a wildcard to allow  
randomized queries.  The many ways these scripts can be applied in  
rather evil ways has not been fully considered, nor fully described  
in SPF-dos-exploit draft.

-Doug

.