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

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

Thomas Narten wrote:

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

Agreed. The tricky part is defining what that is exactly.

> - 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)?

Does it provide unambiguous data.

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

Agree

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

Is it a lookup and not data. Does it provide information about Internet
resources and not local data (lookups that only have relevance within an
administrative domain should not be stored in the global DNS).

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

Because too many RRs will trigger UDP overflow which impacts the
performance of lookups. Way-too-many RRs will also trigger TCP overflow
whichi will prevent lookups from working at all.

This is my primary concern: the main function of the DNS is for lookups,
it should not be hampered or blocked with excessive RRs which are better
served by other processes.

> And isn't the info in an MX record "application data"?

Yes, but I'm not advocating its removal.

A lot of the filtering effort comes from trying to keep things like MX out
of DNS. Putting MX into the DNS in the first place could be considered a
mistake by my defintion. However, I certainly recognize the value and
stickiness of MX and also recognize that there was no other alternative at
the time, and so I certainly have no desire or goal of pulling it out of
DNS. But that doesn't mean new MX-like RRs should go into the DNS either.

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