[dns-operations] EDNS0

[Paul Vixie]

mark and i are here as individuals, not as representatives of ISC, and so
some of our answers will be different.  note that he's been in the code in
recent years which i havn't, whereas i've been operating high volume servers
and tracking ddos in recent years which he hasn't, so some perspective is
in force here.

# > Would that always cause the response to go to the spoofed ip address?
# 
# 	Yes.

i agree.

# > How is that different then amplification with recursive dns servers?
# > (since in both cases the a smaller request packet of about 40-50 bytes 
# > causes dns server to send large response up to 500bytes to forged 
# > source ip address)
# 
# 	Essentially there is no difference.

i disagree.  there are two differences, both of which are useful for defense.

1. there will be a lot fewer servers, since as of this moment there isn't very
much large-rrset content available.  certainly one would not expect to see
122K or 580K or even 10K different source addresses on ~4K responses today.
SPF or another TXT RRset application, or DNSSEC, could push this up but even
if we started right now it would take years to get to 10K authority servers
pushing ~4K responses.  this means WRED and other policy-based queuing methods
are likely to be very effective at stopping this kind of attack, and i mean
stopping it far enough upstream that its harm can be mitigated.

2. there will be a lot more Q-tuples.  it won't be one or a small number of
TXT RRsets, it'll be one or more Q-tuples per authority server.  this will
not make defense any easier but it will make analysis more interesting and
in the past, interesting analysis has led to new kinds of defenses.

# > Would this change in anyway with EDNS (if so how)?
# 
# 	Only the size of the response.  At this point in time it
# 	is hard to find responses that would get to the 4k mark
# 	unless you craft it yourself.  Recursive servers were need
# 	for the current attack so that you could get a lot of
# 	responses from the records you put in place.

i mostly agree.  the important part of this attack is the amplification
factor, where each (spoofed) query is ~60 bytes in size and each response
is ~4K in size.  that's a roughly 65X amplification factor, enabling the
attack-flow to be so small per recursive server that the operators don't
see it coming in and the drone-owners (that's our moms' and aunts' PC's)
don't see it going out.

without EDNS0 the factor will be closer to 8.  that would mean a lot more
drones, or larger flows per drones, and will in any case mean more ingress
flows (or larger ones) per amplifier and/or more amplifiers.  some of those
changes would make an attack easier to detect and/or trace, some would make
it easier to detect but harder to trace.  it's not an automatic win or lose.

the bigger issue is that RFC 2671 was written with some goals in mind, and
any of EDNS0's harms have to be looked at in light of those goals.  we also
have to ponder the size of the list of the feature we're willing to discard
due simply to our industry-wide unwillingness to take BCP38 seriously --
open recursive name service won't be the last casualty, nor would EDNS0 be
if we thought we could successfully turn that off (assuming we wanted to
forego the original goals of RFC 2671.)

# 	As DNSSEC is deployed finding a 3+k authoritative response
# 	will be about as easy as finding a 500 byte response is
# 	today.  You will be able to do the attack w/o needing the
# 	recursive servers.

"DNSSEC in 2008!"