[dns-operations] DNS deluge for x.p.ctrc.cc

[Paul Vixie]

# But for the rest of us it's going to be a nightmare we have to deal with
# daily.  New dns servers pop up every day on an ISP's network so it's
# whackamole like it was with open relays. Troubleshooting dns issues which
# can manifest themselves as anything from spam filters to credit card
# processing.

and yet, the time has come when the default out-of-box configuration for
smtp relays is to non-open.  anyone who "pops up" an open smtp relay and
finds it overrun with spam and finds their outbound mail bouncing will
very quickly be told by their isp's and vendor's and beer buddies what
the issue is.  it wasn't that way at first -- the transition was damned
difficult, as this one will be.  but there will be a new steady state at
the end of this difficult transition.

you appear to be arguing that the transition will have a higher cost than
benefit, and for all i know you might even be right.  but since it's an
assymetric cost:benefit equation, where the costs go to one set of folks
and the benefits go to another, it doesn't really matter whether benefits
outweigh costs or not.  you can't control what someone else will choose
to do, other than by offering them choices they find more attractive, and
even then they might not behave rationally.

# With *gress filters we do it once and it's done, it's not a hardship on the
# good guys.

wrong on both points.  BCP38 isn't a one-time deal, it's an ongoing thing
which requires maintainance and will have bugs and bad interactions.  it'll
also be a hardship on various good guys who were depending on it in ways
their ISP didn't know about.  however, even though you're wrong about the
details, i agree with you that universal BCP38 deployment is our mandate.

# Talk google into blocking access from spoofable areas, there are lots of
# ways to get it done.

i don't expect that google or any other major company would be able to justify
that kind of policemanship to their shareholders or customers.  for all we
know it's cheaper for google to overprovision for attacks than to lose any
eyeballs, and if so then that's what they would (and should; and must) do.

# > should root and TLD nameserver operators choose to be available to all
# > parties or should they choose to be available while they are attacked?
# > your answer only has to cover the time between today and universal BCP38
# > deployment.
# 
# should they choose to be available while they are attacked? I don't
# understand what you are asking here, can you reword this?

if root and tld servers accept packets from recursive name servers known to be
open and known to have been used as amplifiers in prior attacks, then they
will not be available during amplifier attacks, but they will be available to
the entire internet.  that's the status quo, and it's a possible choice of
"most responsible way to operate".

if root and tld servers drop packets from recursive name servers known to be
open and known to have been used as amplifiers in prior attacks, then they
will not be available to the entire internet, but they will be available
during attacks.  that's the prospective change, and it's a possible choice
of "most responsible way to operate".

none of the debate here has clarified any of the ingredients to that question.