Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt))

["Eric A. Hall" <[e-mail]>]

> | If for example under the "anything goes" principle somebody defines
> | the dreaded My-MP3-Files RR which returns records for every MP3
> | cataloged on a specific server, it is possible for thousands of RRs
> | to be returned.
> 
> Yes, and for that reason (the RRset would not be expected to fit in any
> rational packet), that wouldn't be a sane thing to store, technically.

Of all the reasons to limit, message size probably isn't one of them.
There are lots of valid reasons to have very large answer sets. I think it
is better to define filters which are based on content/context.

> anyone who chose to load up thousands of RR's at the kind of domain
> label that would be used for other purposes (like mail) would deserve
> to have all kinds of things start failing. Inventing a new name for
> such things (say mp3.my.dom.ain) is not difficult to achieve
> (assuming it was rational to use the DNS for a purpose like this -
> which it isn't).

But then somebody publishes their email address (user@mp3...) and mail is
broken again. Or a user puts their MP3 collection on their rent-a-domain
redirector box, the same box/domain that they use for mail, the same box
they use for web pages, etc.

The use of qtype=* is probably going to become more common over time, what
with there being A, A6 and AAAA RRs in the field now. Since DNS doesn't
provide a way to enumerate the RRs that it wants, it has to use qtype=* if
it will pick and choose.

The key point in my argument is that data in the DNS should only be used
for lookups. It should provide a critical piece of information which is
necessary for some other application process to complete, and nothing
more. It should not provide any application data whatsoever.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.