[dns-operations] Best Practices in DNS security

Paul Vixie paul at vix.com
Sun Mar 19 17:24:07 UTC 2006


i usually don't answer somebody who sends five messages to the same mailing
list in a matter of a few hours, and i try hard not to be one of those people,
and so i'll use up the last of today's quota by point out that...

> You are absolutely right, instead of saying switch dns server software we
> should be saying switch to a router that by default implements BCP38.

...that whether i run a BCP38-compatible configuration on my router will make
no difference in the number of spoofed-source packets i receive from others.
see the archives where i have tried (unsuccessfully, it now appears) several
times to explain the essential assymetry of the BCP38 deployment problem --
the people who need to deploy BCP38 are *not* the ones being hurt by their
nondeployment, and deploying BCP38 (at whatever local cost) will benefit only
"other people".

there are three roles involved here.  let me explain, again, who they are
and what pain they're feeling and what i want them to do differently in spite
of the pain they're not feeling.

Mr. A runs a non-BCP38 network.  His botted customers are allowed to spoof,
which they do, but usually at a fairly slow speed -- the parasites don't want
to injure their host enough to warrant local remediation.  I want Mr. A to
deploy BCP38 even though it won't change his life in any positive way, will
cause pain to some of his non-malicious customers who will have to complain
and ask for exceptional treatment (which is covered by BCP38 but is more work
for a likely-unprofitable ISP.)  So I want Mr. A to do more work for the same
pay, and maybe lose some customers in the process, all to benefit Mr. C.

Mr. B runs an open recursive nameserver.  His routers have no way to tell
that Mr. A's botted customers are spoofing Mr. C's source addresses on queries,
because from Mr. B's position on the network, Mr. C's source addresses can
legitimately come from outside Mr. B's network.  Only Mr. A can prevent Mr. A's
botted customers from spoofing source addresses -- that's a natural law here.
I want Mr. B to close his open recursive nameserver to queries that don't come
from Mr. B's own network, even though the responses he's sending to spoofed-
source queries are usually not hurting him much, and even though his customers
enjoy the convenience of reaching these recursive nameservers from "outside"
of Mr. B's network.  So I want Mr. B to do more work for the same pay, and
maybe lose some customers in the process, all to benefit Mr. C.

Mr. C runs some kind of network service like online gambling, DNS or other
support services for online gambling, or any renumerative service where the
cost of not being reachable by the customer is high enough that they'd be
willing to pay protection money to avoid being unreachable.  Every time they
miss a payment to the Russian "organized crime" mob, their network connection
is flooded, bombarded, and congested by a lot of responses from Mr. B to
spoofed-source queries that Mr. B heard from Mr. A but which appeared to come
from Mr. C.  I want Mr. C to stop responding to any DNS query from any open
recursive nameserver which has previously been used to attack him, and I want
this done far enough up the chain that the congestion-effect is in somebody's
backbone and doesn't show up on the monthly transit bill.  This won't be good
for Mr. A or Mr. B, but it will keep Mr. C in business, which is what I want.

so please stop telling me to deploy BCP38 in order to protect myself against
spoofage that happens on somebody else's network.  if that were an effective
methodology, don't you think we'd've tried it about a decade ago?  the best
thing for everyone on this thread to do is go *read* BCP38.  or if you're a
pointy-haired boss, read my executive summary of it, called SAC004.



More information about the dns-operations mailing list