Subject: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Oct 2010 16:57:06 -0400

I'm reading this as the "ENUM is considered harmful to the DNS" or don't
even think about E2MD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, October 18, 2010 2:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-iab-dns-applications-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Architecture Board Working Group
of the IETF.

	Title		: Architectural Considerations on Application
Features in the DNS
	Author(s)	: O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba
	Filename	: draft-iab-dns-applications-00.txt
	Pages		: 23
	Date		: 2010-10-18
	
While the principal purpose of the Domain Name System (DNS) is to
   translate Internet domain names to IP addresses, over time a number
   of Internet applications have integrated supplemental features into
   the DNS to support their operations.  Many of these features assist
   in locating the appropriate service in a domain, or in transforming
   intermediary identifiers into names that the DNS can process.
   Proposals to piggyback more sophisticated application behavior on top
   of the DNS, however, have raised questions about the propriety of
   instantiating some features in the DNS, especially those with
   security sensitivities.  This document explores the architectural
   consequences of installing application features in the DNS, and
   provides guidance for future work in this area.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 19 Oct 2010 02:20:37 +0100

Hi Richard, folks,
 ... and you're surprised, given the authorship ?)p

This is a good document, it is needed, and I don't read it that states that ENUM
is a bad idea.

Seriously, this had to be shipped today as it's a -00 draft, so it has some rough edges.
 
My initial notes on the draft are:

- In 3.1, the end of the second sentence on page 8 "needs work".

- The second sentence of section 3.3 on page 9 also needs work; 1464 applied
  the TXT record that was defined in 1035 for use for arbitrary data. 1464 did
  NOT define the TXT record.

- The last sentence in 4.1.1 on page 12 has "like" when I'd expect "likely".

- The first sentence of 4.2 uses "surfaced" in a slightly odd way; maybe "raised"
  or "exposed"?

- in section 4.2 on first paragraph of page 13, void should be replaced by unused.
  (draft-ietf-enum-void is ancient; the last one was draft-ietf-enum-unused-04.txt).

- The second sentence of the second paragraph of 4.4 on page 14 starts with a typo
  -- should be "In".

- being picky, the second "bullet" of section 5 on page 16 could replace "are only
  depended on" with "only depend".

- missing closing parentheses missing in third sentence of first paragraph on page 18.

----

I await with interest the IAB's comments on the Google resolver proposals (perhaps on
page 12) and also on the keyassure work (apparently on page 17, if I decode it correctly)
-- after all, Phil *might* (eventually) get carpal if he's the only one to fight those
evil people.

There are places where the authors' dry sense of humour made me laugh:

- http (or TLS) is the same as DNS -- on page 17, second paragraph,

- by implication, CNAME considered a bad sign (there, and earlier on page 16, second
  "bullet" of the second set of items on page 16),

- the thought that DKIM did NOT chose to use TXT records partially because it was
  infeasible at the time to get an RR type while as the DKIM syntax and semantics
  was still crystallising (or that they had been through enough pain by that point :)

Send-n as currently written may be in the sights, but it is perfectly possible to design
a "number length" DNS tree that will be very heavily cached and uses the DNS ability
to scale and be information-dense (unlike almost any other protocol, even TLS -- ha!).
Whether that would use NAPTRs or just plain TXT records (like everyone else) is an
entirely different question. It would avoid any need for standardisation in the IETF,
which may be the point.

Finally, I really would like to find the bogey man who thought of putting ringtones
in the DNS; I hear much talk of how bad this is, but no-one ever proposed doing such
a perverse thing, AFAICT.

all the best,
  Lawrence

On 18 Oct 2010, at 21:57, Richard Shockey wrote:

> _______________________________________________
> enum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 20 Oct 2010 09:59:19 +0200 (CEST)

Hi Rich et al.

Let's look at the bright side of draft-iab-dns-applications-00.txt:

Finally we have the concerns expressed in written, and thus a much better 
basis for future discussions concerning any ENUM extensions (including 
E2MD).

Hopefully, with this document we can finally get rid of an odd form of 
communication, which was "conveyance of concerns by Grey-Beard-Proxy".

cheers,
  Bernie

PS: I'll try to figure out, on which list draft-iab-dns-applications is 
to be discussed, as the ENUM list is certainly too narrow for this problem 
space.

--

http://ucom.ch/
Tech Consulting for Internet Standardization

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Oct 2010 10:43:43 -0400

Lawrence,

Thanks for these notes. Your editorial concerns will be fixed in the next revision.

I'm not sure that dns-applications would be the right place to address Google's pubic resolver, as the scope of this document is really the interplay of applications and the DNS, and at least off the top of my head I don't see how the Google resolver is salient to that. In much the same way that iab-dns-applications does not rule out DKIM's use of credentials in the DNS, initially I don't think it should rule out the keyassure work either, which in my opinion could turn out to be useful, although there are also paths where it could turn out not to be useful.

The draft certainly does not suggest that HTTP and DNS are the same - merely that HTTP (or really any query-response protocol) can emulate the query-response semantics of the DNS. Obviously the two protocols are otherwise very different.

I think I do agree that the second bullet in the second set of bullets on page sixteen doesn't capture what we meant here, though instinctively there must be some discouragement of excessive recursion. We'll try to find a more exact way of stating that which doesn't seem to ban CNAME. We do want to preserve concerns about redirecting between names in the DNS without DNSSEC, though.

While there are alternative technical solutions to many of the practices discussed in dns-applications, the issue the draft raises with send-n is its "predictive" quality, the practice where one node in a tree tells resolvers about the the state of nodes down the tree and the resulting synchronization issues. Perhaps there are ways to approach send-n in the DNS that don't exhibit this quality, but perhaps there are ways to do it outside of the DNS entirely which require a lot less imagination.

The draft doesn't attribute the story of ringtones in the DNS to any particular source, and perhaps it is apocryphal, but that doesn't exempt it from serving as an illustrative example of excessive data in the DNS.

Jon Peterson
NeuStar, Inc.

On 10/18/10 6:20 PM, "Lawrence Conroy" <[email-masked]> wrote:

Hi Richard, folks,

----

all the best,
  Lawrence

---

From: Jim Reid <[email-masked]>
Date: Wed, 20 Oct 2010 16:10:23 +0100

On 20 Oct 2010, at 15:43, Peterson, Jon wrote:

> The draft doesn't attribute the story of ringtones in the DNS to any  
> particular source, and perhaps it is apocryphal, but that doesn't  
> exempt it from serving as an illustrative example of excessive data  
> in the DNS.

Jon, I simply don't know what you mean here. Please define  
"excessive", preferably with objective qualitative and quantitative  
metrics. There are plenty of examples of stupid and/or pointless data  
in the DNS. [My favourite was a text-based adventure game.] But who  
gets to decide what's stupid and pointless? Or if those things are  
excessive?

We may well agree that ringtones in the DNS are a possibly apocryphal  
example of "excessive" data. However the people who put that data  
there and those who consume those ringtones would presumably disagree  
with that view. And they'd be right. If whatever they're doing to the  
DNS works for them and isn't harming others, who are we to judge? For  
some definition of we...

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Oct 2010 13:32:09 -0400

One of the challenges of reaching architectural principles for the guidance on using DNS as a generic database is wrapping measurable parameters around concepts like "excessive", I agree. We do understand what it means for a label to be excessive, and give numbers for that in the draft. For the data part of a resource record, that probably has a variety of caveats and dependencies. I've certainly seen pages of ASCII art in TXT records before that didn't seem to bring the Internet to its knees. Since a lot of the potential for generic NAPTR data comes from the potential use of data URLs, it is worth pointing out that the data URL RFC contains the following text:

   The "data:" URL scheme is only useful for short values. Note that
   some applications that use URLs may impose a length limit; for
   example, URLs embedded within <A> anchors in HTML have a length limit
   determined by the SGML declaration for HTML RFC1866. The LITLEN
   (1024) limits the number of characters which can appear in a single
   attribute value literal, the ATTSPLEN (2100) limits the sum of all
   lengths of all attribute value specifications which appear in a tag,
   and the TAGLEN (2100) limits the overall length of a tag.

Perhaps in later versions of the document we could call out this text specifically, although it doesn't define "short values" in a way that will give you a hard litmus test. We also have to consider what implementations will realistically accommodate. We need to consider that implementations out there use very large data URLs today - for example, I understand some iPhone hacks encode multi-megabyte .pdf files as data URLs. If one of those ended up in the DNS, would your resolver parse it or die? If the resolver survives, would the application that receives it from the resolver survive? I'm sure that some people could put that data in the DNS with particular resolver implementations in mind that would survive and relay the data properly. What happens, though, when someone outside of that community tries to access it?

Jon Peterson
NeuStar, Inc.

On 10/20/10 11:10 AM, "Jim Reid" <[email-masked]> wrote:

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 20 Oct 2010 18:54:23 +0100

Hi Jon, Jim, folks,
 If we're talking about URLs in NAPTRs, these have to be in the REGEXP field, and that
gives a hard limit of 255 bytes. In practice, with the limits to the REGEXP field content
and the data: URL's syntax, we're really talking about a lot less for useful binary data.
See the x-crypto draft for the gory details.

I guess you might string a set of NAPTRs together, each holding a small chunk of stuff
inside a data: URL, and using the ORDER/PREF fields to defined the sequence in which
the payloads were to be stitched together, but that's waaaay beyond sensible.

For a single NAPTR, this is not a realistic problem, IMHO. That's why I have remained
skeptical of concerns over data: URLs inside NAPTRs; the field a data URL must inhabit
is severely restricted. Sure, one can bulk up NAPTRs (e.g. using full blown 3GPP-compliant
SIP URLs) and have a lot of them in a domain (speaking of different identities a la 3GPP)
but for individual NAPTRs, they simply can't be that big.

TXT is much "better" for that kind of bulk. With due deference to Jim, I still think
that putting a ringtone in the DNS is perverse; consenting adults or not, DNS is hardly
in the privacy of one's own home.

all the best,
  Lawrence