Set aside the theoretical and philosophical discussion against text RRs
for a minute and just look at the practical issues.
For one thing, memory size of caches is already a problem and large
answers make it worse. Folks that are likely to implement whatever pops
out of this effort are already doing a bunch of lookups; I look for any
MX/A for the HELO domain, the MAIL FROM domain, and the From: domain
already (via Postfix/SpamAssassin filters), and also lookup a bunch of
blacklist entries including SpamCop, cbl.abuseat and spamhaus in Postfix
and a bunch more inside SpamAssassin. I'm already pulling down more DNS
data than the size of the original SMTP message in some cases (an easy
guesstimate is +1k), and all that data is going into my cache. Since my
email address is published in several places, I'm a frequent target,
getting at least one connect every minute just for me. Assume a rolling
three-day average for TTL (high considering default negative cache but
safe for budgeting), and that's (1024 bytes * 1000 per * 3 day vol) or
3,072,000 bytes of cache data at any given time, and that's just for
processing the mail requests -->for one person.<-- Multiply as necessary
and you can imagine what the big domain caches look like. A single
300-byte response of uncompressed textual data will increase my cache
consumption by 30%. XML documents with lots of uncompressed textual
widgets that hit ~1k will double my minimum cache size.
Don't cry for me though, it's far worse for orgs that don't do lookups,
since they will be facing magnitudinal increases over their basic PTR
checks. If they are already running with a 500 MB cache from 100-byte
PTR-sets, they're gonna need 5.5 GIGABYTE caches when they start reading
RRs that produce ~1k uncompressed text routinely. Even at just 300-byte
messages, they'll need 2.0 gig caches to handle the same volume.
Another problem area is with potential for reverse-DDoS attacks from
forgery runs. If a miscreant were to forge a domain, and one million
recipients decided to check the RR, it would produce a surge of one
million additional lookups to those DNS servers. A large RR that
overflowed the UDP limits would result in one million TCP connection
requests, which the DNS server would have to deal with, and which would
certainly cause them to stop dealing with other regular traffic. So in
this case, an attack on MARID results in every other infrastructure
service that uses DNS as well.
If the policy descriptor were put into SMTP directly (as an alternative
example), then the scope of the attack would be limited to the affected
service and would not take out the whole neighborhood. Plus, most SMTP
servers are designed with process limits that can restrict the number of
connections they'll handle. From that perspective, an attack on MARID can
be reasonable constrained.
Those are just a couple of the practical implications from sticking very
large descriptor-type data into the DNS. The other issues remain alive
too, of course, in that large and ambiguous datasets trigger message
overflow which has several negative effects. I would also point out that
DNS is one of the two critical infrastructure services that keeps the
Internet actually working (the other is global packet routing) and that
folks should be very worried about anything that hints at disruption.
I strongly encourage you to pursue tiny and binary RRs that will minimize
the impact on DNS.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/