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

[Patrik Fältström <[e-mail]>]

--On 01-04-07 13.33 +1000 Robert Elz <[e-mail]> wrote:

> Personally, I have no problem with storing almost any kind of data in the
> DNS, provided that it makes technical sense to put it there (that is,
> given the limited available space for RDATA, so for example, storing
> images in the DNS wouldn't be rational) and provided that the DNS is the
> sane mechanism for the data and the way it is to be retrieved (so
> anything that you want to be able to find based upon an imprecise query,
> or a query that isn't easily mapped into a domain name, should go
> someplace else).  Also the data needs to be of unrestricted access (DNS
> data is available to the universe, despite the misguided efforts of some
> to provide implementation defined access restrictions).
>
> But where it makes sense to use a domain name to fetch a small amount of
> public data, then I don't mind defining an RR code for the thing.   About
> all that is left is to decide whether the definition of the object is
> precise enough that we know what is really being fetched and how to use
> it, and whether it is realistically going to be used enough to make it
> worth the bother of doing the assignment (there have been cases proposed
> where I though the thing being defined so useless that it just wasn't
> worth the effort).

I agree completely.

I just want to let you DNS people know that I try to tell the wg's in my 
(Applications) area that it is ok to store references to data in the DNS if 
the references are to be looked up given the unique name of the owner. 
Searches is a nono, and storing actual data is also a nono.

That kre above accepts some small amount of data which is tied to the zone 
in DNS is something which I also think is ok, but I don't tell people in 
the beginning of the "negotiation" :-)

     paf



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