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

[Thomas Narten <[e-mail]>]

Robert Elz <[e-mail]> writes:

> I think we already have that policy - the philosphical question being asked
> is when and why should new RR records get approved by DNSEXT, and when should
> they be rejected.

Personally, I think defining DNS RRs should be encourgaged where it
makes sense. I.e, the DNS does the things it is designed for quite
well. New RRs that fit within the existing model should be encouraged.
Criteria could include:

- Would use of the new RR cause operational problems?

- Would it cause problems for existing implementations, or would
  existing resolvers/servers handle them just fine (i.e., don't forget
  about caching servers that could just cache the RR without
  undestanding its semantics)?

- Is the usage of the RR consistent with the basic service the DNS
  provides well?

  - E.g,. lookup based on a heirarchical name (the DNS name).

  - Small number of RRs at a given name, as opposed to tens or
    hundreds

  - Relatively infrequent updates to the data (i.e., non-realtime)

  - Can use reasonable TTLs (i.e., other than zero)

Surely there are more (does it duplicate existing RRs, is it specified
clearly enough for implementors, etc.), and enumerating/documenting
the issues that should be considered when evaluating a proposed RR
would be a useful exercise, especially for folks that are thinking
about whether they should define a new RR.
    
"Eric A. Hall" <[e-mail]> writes:

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

I think this distinction is too absolute. As long as the application
data can easily be put into the DNS without causing contortions, why
shouldn't that be allowed? And isn't the info in an MX record
"application data"?

Thomas


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