Subject: Re: [e2md] E2MD and DNS overload

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 10:02:27 -0500

On Apr 30, 2010, at 4:12 AM, Lawrence Conroy wrote:

> Hi Dean, folks,
> on the grounds that the previous mail thread had a vague title, I've  
> started a new one.
>
> To summarise earlier posting -- channeling 20 bunkum-spouting demons,

I hope I was only channeling a dozen or so . . . if there's 20 of  
these guys out there, we're going to need to bring more of our own  
people!

> Dean said:
> *	People could put a set of 200 resource records into a domain.
>
> *	If people use this with large RRSets on the open Internet it will
> 	cause widespread problems.
>
> *	Servers would have to generate large answers.
>
> To which I answer:
> -	You could do that now. You don't even need to use type 35.
> 	That is a provisioning issue, not a protocol issue.
> 	I do not see how this is any different from existing RR types.

The difference, according to some greybeards, is that Having an RFC  
That Defines Lots Of Resource Records somehow says to people that  
using lots of resource records is OK. Sure, you can do crazy stuff  
now, but there aren't quite so many officially published guidelines  
that appear to be encouraging you to do it.

It's like the argument that while any chemistry student can figure out  
how to nitrate glycerine, not too many preschoolers try it. But if we  
published comic books on the procedure, kids are likely to skip the  
"add LOTS of ice" step and blow themselves up.

We might be able to ameliorate this argument by having strong  
guidelines on how NOT to use the specification incorporated into it.

>
> 	Viz. DNSOPS discussions on signed response sizes and rollover.
> 	With the exception of that particular corner case where the minimum
> 	size can be large, people do not do it.
> 	It seems unreasonable to block use of a resource record type for
> 	what is a purely operational issue.
> 	This is certainly nothing to do with E2MD.
> 	This is a complaint at ENUM.

Also quite true. I've noted that some of the greybeards seem to be  
pretty much fundamentally offended by the existence of ENUM. I'm not  
sure there's a lot we can do about this. But they don't come straight  
out and attack ENUM directly; rather they slip in their arguments  
about ENUM with respect to any other uses of the ENUM approach, as  
they think this helps Contain the Evil.

I don't have a good solution for dealing with this strategy.

It may be that the best approach is a head-on confrontation that puts  
the central question on the table: Is ENUM too broken to use? If not,  
then this is no worse, and they need to get off their soapbox. Risk:  
We get a community consensus that ENUM is in fact too broken to use. I  
can't estimate the risk of this, but it is greater than zero.

> 	There is nothing stopping someone putting any number of email, web,
> 	sip E2U NAPTRs (and D2U NAPTRs) voice:tel and sms:tel or even h323
> 	NAPTRs into a domain, now.
> 	As a user of E2U NAPTRs, I do queries regularly and I do get RRsets
> 	that are in the 10s of records. It just works.
>
> -	I don't understand how ENUM can be a Weapon of Mass Destruction.
> 	What widespread damage will be caused?
> 	Regardless of RRset size, the request is not large, so bouncing that
> 	through the authoritative hierarchy repeatedly is not an issue.
> 	The response may be large. This comes from the authoritative server
> 	that hosts a large RRset. This response also traverses the recursive
> 	resolver from which the query was sent.
> 	The victims are the Auth server that hosts the large RRSet and the
> 	recursive resolver that makes the query and receives the truncated
> 	result.
> 	The recursive resolver wil send one query over UDP, receive one
> 	truncated response over UDP, and then fallback from that truncated
> 	response using TCP. That IS a congestion-controlled protocol.
> 	So ... someone provisions a large RRset into an auth server; the
> 	auth server consumes bandwidth sending its responses, and it may
> 	take some small time for the recursive resolver to get a response
> 	due to the fallback to TCP. This is not news.
> 	What other collateral damage is caused?
> 	The volume of interweb traffic that is used for DNS is tiny.
> 	ASSUMING that the Auth server for facebook.com is not the same one
> 	that is hosting ENUM domains, people will continue to waste their
> 	time without any interference.
> 	It's not like the Interweb has a separate tube for DNS, and that
> 	tube can get full.
>

What I seemed to be hearing from some of the greybeards was that while  
it's "supposed to work this way", in practice it doesn't. If they're  
throwing fud, can we respond with peer-reviewed
evidence? Do we have any nice research papers showing measurements of  
this sort of usage and giving "proof" that TCP fallback is working?

> -	Finally (from a previous channel), DNS servers don't do a lot to
> 	generate RRsets.
> 	Auth DNS servers are not like some LDAP or Web server (as would be
> 	used with any redirection scheme).

Well, that's true "now". But if we start doing requester-specific DNS  
responses (which people are talking about, example Hadriel's draft)  
instead of just pasting the memory-cached records into the response,  
then it is likely to increase the computational load on the Auth DNS  
server dramatically. So we perhaps need to be careful about this one.

--
Dean

---

From: Jim Reid <[email-masked]>
Date: Mon, 3 May 2010 16:30:34 +0100

On 3 May 2010, at 16:02, Dean Willis wrote:

> using lots of resource records is OK.

WTF? We're not supposed to put data in the DNS because some clueless  
bozo might put "too many" RRs? This is beyond FUD. What next? Don't  
use IP because you might send too many packets? Or don't buy a  
computer because you'll burn too many CPU cycles and spend too much  
money on software?

> Sure, you can do crazy stuff now, but there aren't quite so many  
> officially published guidelines that appear to be encouraging you to  
> do it.

And there's nothing in this e2md discussion which suggests doing crazy  
stuff either. At least nothing yet,

> It's like the argument that while any chemistry student can figure  
> out how to nitrate glycerine, not too many preschoolers try it. But  
> if we published comic books on the procedure, kids are likely to  
> skip the "add LOTS of ice" step and blow themselves up.

So let them. We're all supposed to be adults here and responsible for  
our own actions. I don't see why anyone can argue DNS has to be a  
special case. There's no other RFC or protocol spec that says "if you  
do stupid shit or add too much data, Bad Things will happen". So  
insisting e2md does this is unreasonable.

> guidelines on how NOT to use the specification incorporated into it.

This is asking to prove a negative and quite unreasonable Dean. Should  
the spec say "here's not how to (ab)use the scheme to disprove the  
existence of the Loch Ness monster"? It would be much more sensible  
and practical to provide guidelines on the recommended/likely use  
cases wrt to numbers of RRs, packet sizes and so on.

> pretty much fundamentally offended by the existence of ENUM.

Tough. That ship has sailed. These anonymous greybeards just have to  
get over it. Life sucks sometimes.

> I'm not sure there's a lot we can do about this. But they don't come  
> straight out and attack ENUM directly; rather they slip in their  
> arguments about ENUM with respect to any other uses of the ENUM  
> approach, as they think this helps Contain the Evil.
>

I would hope rational argument and common sense will do the job.

Get some hard data based on actual use cases and requirements. Show  
why the ENUM-like NAPTR approach works best (or least-worst). List the  
other options that were considered and explain why they were rejected.  
So if anyone pushes back, they won't be doing so from grounds that  
have a valid basis in engineering or operations.

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 11:59:43 -0500

> computer because you'll burn too many CPU cycles and spend too much  

If we define an easy way for people to extend a protocol, experiences  
shows us people will use that easy way, and often use it in an ill- 
advised manner. In response to this, some people (notably Jon Peterson  
in this debate) seem to favor requiring a standards-track effort for  
each new extension

>> officially published guidelines that appear to be encouraging you  
>> to do it.
>
> And there's nothing in this e2md discussion which suggests doing  
> crazy stuff either. At least nothing yet,

I seem to recall David Schwartz popping up with a bunch of new use  
cases during ITF 77. I think the number I heard was "At least 50."

> So let them. We're all supposed to be adults here and responsible  
> for our own actions. I don't see why anyone can argue DNS has to be  
> a special case. There's no other RFC or protocol spec that says "if  
> you do stupid shit or add too much data, Bad Things will happen". So  

Actually, caveats on extensibility are pretty common in protocol  
specifications.  I can give you some pretty good examples from the SIP  
world. Originally, all SIP extension headers required standards-track  
work.  RFC 3427 relaxed this and allowed informational documents to  
define a special class of extension header fields called "P-headers".   
Almost immediately, 3GPP starting writing up P-header info-RFCs, most  
of which have turned out either to be specification/interop  
nightmares, or absolutely critical standards that should have been  
Standards Track all along.

Another corollary is the SIP INFO method, When first specified, it  
provided an unbounded range of message communication between two SIP  
UAs. As long as the two UAs in question knew what they were doing with  
it, they could stick any MIME payload type in an INFO and send it  
using SIP. Chaos ensued, and there are people who have been working  
for years to clean it up.

Yet again with SIP: the MESSAGE method. Originally envisioned for  
sending instant messages (eg, texts) between users, it immediately  
swelled up with big payloads (often over UDP and started killing both  
servers and networks. So another protocol, MSRP, was introduced along  
with a replacement architecture. Incidentally, this is pretty much  
like putting a metadata pointer into the DNS, then using some other  
protocol to get the actual metadata.

> This is asking to prove a negative and quite unreasonable Dean.  
> Should the spec say "here's not how to (ab)use the scheme to  
> disprove the existence of the Loch Ness monster"? It would be much  
> more sensible and practical to provide guidelines on the recommended/ 
> likely use cases wrt to numbers of RRs, packet sizes and so on.

Ok, I can see that.

>> I'm not sure there's a lot we can do about this. But they don't  
>> come straight out and attack ENUM directly; rather they slip in  
>> their arguments about ENUM with respect to any other uses of the  
>> ENUM approach, as they think this helps Contain the Evil.
>>

Then we're going to need some of both ;-).

> why the ENUM-like NAPTR approach works best (or least-worst). List  
> the other options that were considered and explain why they were  
> rejected. So if anyone pushes back, they won't be doing so from  
> grounds that have a valid basis in engineering or operations.
>

Excellent suggestion!

--
Dean