[dns-operations] Why would an MTA issue an ANY query instead of an MX query?

[Vernon Schryver]

> From: sthaug at nethelp.no

> I have several gigabytes of pcap from *my* DNS clients indicating that
> for the majority of clients this is *not* the case. Source port is
> generally >= 1024 and seems pretty randomized (without having done any
> deeper analysis of this). A small minority of clients are sending DNS
> queries with a source port of 53.

(quoted without comment for emphasis)

> What *could* make sense for my clients would be blocking inbound UDP
> port 53 traffic to the clients caught doing ANY queries for ripe.net
> or isc.org (blocking inbound UDP port 53 to the CPE WAN side that is),
> and at the same time running a portal where those clients who needed it
> could easily remove such a block.

And then remove the limitations when DNSSEC becomes too common to
list all of the sources of DNS jumbograms?  (DNSSEC for .com gives
respectable amplification now.)  That end result would be a standard
block-with-exceptions-for-some-users.

I think one implementation of that is a complete block on UDP 53 from
the Internet to CPE and an intercepting DNS proxy (ordinary DNS resolver
with easy modification to forge source addresses) for CPE to Internet
and with the portal for needful clients informing an RPZ zone for the
proxy.


Blocking inbound UDP port 53 *to* the CPE WAN side answers the big
problem with port 53 blocks that no one mentioned.  It protects an
ISP from outside attackers without the ISP paying the costs of
dealing with attacks on the outside from within the ISP.

ISPs in general have always refused to do anything about abuse unless
the abuse costs them.  They worried about incoming spam because it
angers users, but generally didn't care about outgoing abuse.  That's
why they can't be bothered to deploy BCP 38, they couldn't find their
own spamers without Spamhaus' occassionally blocking their corporate
mail systems, and modern content provider "feedback loops" are ignored
unless enforced with wholesale blocking.

I keep asking about current port 25 blocking because I don't know.
I do know that many ISPs effectively blocked port 25 by requiring the
targets of their spam to do almost all of the work by using Spamhaus' PBL.

   ...


} From: Edward Lewis <Ed.Lewis at neustar.biz>

} 1 - DNS providers are paid to answer questions, not drop traffic.

Many of the expected users of the BIND rate limiting patch are not
paid to answer questions by the questioners.

Besides, rate limiting identical answers for a single question from
a single questioner is a standard part of good protocol design.
It's why many UDP based protocols include transaction IDs or XIDs.
Sometimes XIDs are necessary because requests are not idempotent,
but it's always wise to include defenses against stuck clients in
your protocol.


} The suggestion to limit EDNS0 to "a smaller size" might be the first 
} step to decent (but still suboptimal) improvement.  Guessing that the 
} malicious data seeks two things - a large, valid and reputable chunk 
} of data to throw at a victim and an reputable and capable address 
} from which to throw it, perhaps at least limiting the data size in a 
} way that does not cause choking to legitimate uses is a good thing.

That seems to be based on the notion that a DoS attack needs large
chunks.  4,000 128 byte DNS/UDP packets per second would be a bigger
attack than 125 4K byte DNS/UDP packets per second for bandwidth and
processing reasons, although they are the same number of DNS/UDP/IP bits.

Even if first stream were only 125 responses in 4,000 IP fragments it
would still be the bigger attack because IP fragment (and TCP segment)
reassembly is a major cost in hosts.  There are additional reasons why
informed people ask first about packets/sec instead of bits/second
rates for both routers and hosts.

}         Rate limiting is one technique, not a cure-all.  If it was, 
} we'd not be talking about it in 2012.  So, use it with caution.

of course

} PS - One possibility, instead of simply not responding, send back 
} rcode=REFUSED.

The BIND rate-limiting patch limits error responses because a flood of
25 byte REFUSED DNS/UDP packets per second could be a DoS attack.
The default SLIP rate is not 1 because a flood of TC=1 packets 
could also be an attack.


Vernon Schryver    vjs at rhyolite.com