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

[Paul Vixie]

# > I might simply be ignorant. If you can give me a plausible common scenario
# > where a user would need to resort to a random open recursing nameserver,
# > i'm all ears.
# 
# I use them to confirm that my dns is resolving correctly beyond my
# nameservers. It's not required but it's a nice capability that I would hate
# to lose because spoofing is possible.

so if OARC were to set up a public web page that allowed folks to do lookups
using HTTP, (1) that would be a useful thing and (2) you'd stop worrying?

# ... and I don't know of anything that will break if we get rid of the
# ability to spoof.

several folks here have squawked about it; apparently there are non-harmful
uses for spoofing where the upstream ISP is not expected to be cooperative,
which is a corner case i hadn't imagined when i wrote down SAC004 or when i
read BCP38.  i hope that barry greene, who is now on this list, will look at
the archives from late february and try to isolate this into a new corner
case for BCP38 deployment and get the vendors (both his employer and others)
working on it.

# Ingress/Egress filters should be configured by default by routers when a
# route or local subnet is configured much like relay should be disabled by
# default in a mail server. If we can get the router people to understand this
# the problem with go away much quicker just like relay has.

in a private response to someone else on the list (who contacted me privately)
i spake thusly, and it's relevant to questions of BCP38 deployment timing:

+---
| we're having terminology trouble, methinks.  there are three agents involved:
| 
|       A: emits queries spoofed to come from C, aims them at B
|       B: amplifies these spoofed queries into a response stream at C
|       C: receives the resulting deluge
| 
| for most values of A and B, the operator of the equipment won't be bothered
| by the traffic, because the bad guys (like any parasite) don't want to
| become enough of a nuisance that their hosts/enablers will notice them at
| all.  so, we know that most values of A and B are people without incentive
| to stop the attack by reconfiguring or upgrading things.
| 
| C's options are limited; their pipes are full of crap, and no amount of
| upgrading or reconfiguring their equipment is going to stop the attack, and
| the kinds of rate-limiting or filtering they can do have to be done "far
| upstream" in order that any good traffic be able to arrive at all.
| 
| the only person who can stop this by deploying BCP38 is "A", and as noted,
| "A" has no incentive.
| 
| the only person who can stop this by disabling internet-wide recursion is
| "B", and as noted, "B" has no incentive.
| 
| the only thing "C" can block is "B", since "A" is spoofed.
| 
| if "C" blocks "B" then "B" gains incentive to stop being an amplifier.
| 
| your suggestion that we shun someone for not deploying BCP38 is nonsequitur,
| since the only person we (C) can block (B) is probably already BCP38-
| compliant, the only BCP38 problem is at "A" whose identity we cannot know.
+---