Re: excessive data in the DNS

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


On 20 Oct 2010, at 18:32, Peterson, Jon wrote:
> 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 protected]> wrote:
> 
> 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...
> 
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum