Re: excessive data in the DNS
"Peterson, Jon" <[email protected]> Wed, 20 Oct 2010 13:32:09 -0400
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <C8E49FD9.46C48%[email protected]> |
--===============1230553899== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C8E49FD946C48jonpetersonneustarbiz_" --_000_C8E49FD946C48jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the challenges of reaching architectural principles for the guidance= on using DNS as a generic database is wrapping measurable parameters aroun= d 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 depe= ndencies. 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 potenti= al 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 speci= fically, 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 the= re use very large data URLs today - for example, I understand some iPhone h= acks encode multi-megabyte .pdf files as data URLs. If one of those ended u= p 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 sur= e that some people could put that data in the DNS with particular resolver = implementations in mind that would survive and relay the data properly. Wha= t happens, though, when someone outside of that community tries to access i= t? 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... --_000_C8E49FD946C48jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: excessive data in the DNS</TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'><BR> One of the challenges of reaching architectural principles for the guidance= on using DNS as a generic database is wrapping measurable parameters aroun= d 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 cave= ats and dependencies. I’ve certainly seen pages of ASCII art in TXT r= ecords before that didn’t seem to bring the Internet to its knees. Si= nce 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 t= he following text:<BR> <BR> The "data:" URL scheme is only useful for short= values. Note that<BR> some applications that use URLs may impose a length limit= ; for<BR> example, URLs embedded within <A> anchors in HTML h= ave a length limit<BR> determined by the SGML declaration for HTML RFC1866. The = LITLEN<BR> (1024) limits the number of characters which can appear i= n a single<BR> attribute value literal, the ATTSPLEN (2100) limits the s= um of all<BR> lengths of all attribute value specifications which appea= r in a tag,<BR> and the TAGLEN (2100) limits the overall length of a tag.= <BR> <BR> Perhaps in later versions of the document we could call out this text speci= fically, although it doesn’t define “short values” in a w= ay that will give you a hard litmus test. We also have to consider what imp= lementations will realistically accommodate. We need to consider that imple= mentations 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 r= esolver survive? I’m sure that some people could put that data in the= DNS with particular resolver implementations in mind that would survive an= d relay the data properly. What happens, though, when someone outside of th= at community tries to access it?<BR> <BR> Jon Peterson<BR> NeuStar, Inc.<BR> <BR> <BR> On 10/20/10 11:10 AM, "Jim Reid" <<a href=3D"[email protected]">= [email protected]</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>On 20 Oct 2010, at 15:43, Peterson, Jon wro= te:<BR> <BR> > The draft doesn't attribute the story of ringtones in the DNS to any <= BR> > particular source, and perhaps it is apocryphal, but that doesn't <BR> > exempt it from serving as an illustrative example of excessive data <B= R> > in the DNS.<BR> <BR> Jon, I simply don't know what you mean here. Please define <BR> "excessive", preferably with objective qualitative and quantitati= ve <BR> metrics. There are plenty of examples of stupid and/or pointless data <BR> in the DNS. [My favourite was a text-based adventure game.] But who <BR> gets to decide what's stupid and pointless? Or if those things are <BR> excessive?<BR> <BR> We may well agree that ringtones in the DNS are a possibly apocryphal <BR> example of "excessive" data. However the people who put that data= <BR> there and those who consume those ringtones would presumably disagree <BR> with that view. And they'd be right. If whatever they're doing to the <BR> DNS works for them and isn't harming others, who are we to judge? For <BR> some definition of we...<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C8E49FD946C48jonpetersonneustarbiz_-- --===============1230553899== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list [email protected] https://www.ietf.org/mailman/listinfo/enum --===============1230553899==--