Subject: [e2md] E2MD and DNS overload

From: Lawrence Conroy <[email-masked]>
Date: Fri, 30 Apr 2010 10:12:00 +0100

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, 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.

	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.
	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.

-	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).

I contend that those objections are bunkum.
Lest anyone misunderstand, I'm sure Dean is acting only as the messenger,
so this is NOT a dig at him.

all the best,
  Lawrence

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 30 Apr 2010 10:02:47 -0400

Exactly!!  The premise behind this point of opposition is simply off base.  And it requires the proof of an open ended negative, which is always a huge red flag (i.e you can't design that widget with a square corner on it because someone might use it to hurt someone).

One down.  On to the next.  We cannot continue having the same debates over and over and expect to get anywhere.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lawrence Conroy
Sent: Friday, April 30, 2010 5:12 AM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] E2MD and DNS overload

Hi Dean, folks,

To which I answer:

all the best,
  Lawrence
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.