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

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

>> Stuff that doesn't belong is anything that requires authentication,
>> is ambiguous, can be served by a standalone lookup, or consumes more
>> valuable resources than it provides.

> As for "ambiguous", what exactly do you mean by that term?

I mean multiple things but essentially I mean that DNS shouldn't be viewed
as a cheap distributed database (eg, "lets make an Internet filesystem of
MIME objects, stored in DNS!").

The usage of a specific RR should be unambiguous. The usage of A RRs is
pretty much unambiguous. The usage of WKS tends to be somewhat ambiguous
due to system-specific implementation issues (some have used it as a
supplement for /etc/services). The multiple usages of TXT makes it
extremely ambiguous.

The datatypes should also be unambiguous. Free text is ambiguous;
typed-data (like IPv4 Addresses) is unambiguous. Some free text usages are
okay as long as the usage is unambiguous ("display only" as a rule is
unambiguous).

There should never be a general purpose "8-bit-binary" RR or data-type
defined as that would be ambiguous, which is counter purpose to a lookup
protocol. The EDNS kitchen-sink datatype is a good example.

In essence, the data returned from a lookup should be used for automated
processes like fetching an IP address or the list of mail servers for a
host, and not for reading the of MP3 song titles and artists that are
stored in a specified path on a specified host (no this is not a proposal
for the My-MP3-Files RR).

> It is perfectly normal and acceptable for different clients to get
> different answers to the same DNS question (depending on their source
> address and/or which DNS server they ask, when they ask it, etc.).
> Does that constitute "ambiguity"?

Not by my definition. But since you brought it up, clients should expect
to get the same answer set from the same server, within reason.

-- 
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.