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

[Robert Elz <[e-mail]>]

    Date:        Wed, 11 Apr 2001 09:59:15 -0700
    From:        "Eric A. Hall" <[e-mail]>
    Message-ID:  <[e-mail]>

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

It doesn't need to be defined, no-one is looking at creating an
automated RR registration service.  As long as we can make the
distinction when required, that will be fine.

  | Is it a lookup and not data.

I have no idea what that means.   If it is in the DNS, it is going to
be used in a lookup, or having it would certainly be a wast of time.
If it is going to be represented in the DNS, it is certainly going
to be data.   Hence, I would have thought everything in the DNS is
used in a lookup and is 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).

I'm not sure I would go quite that far.  If the data is going to be
useful all over the place, and it is data that can be made publicly
available (isn't intended to be private) then I don't think it matters
in the slightest whether the majority of the uses will be local.

Certainly the vast majority of the A records are only used locally, are
you suggesting that they shouldn't be in the DNS but should be
someplace else instead?

  | Because too many RRs will trigger UDP overflow which impacts the
  | performance of lookups.

Only if there are large numbers of RRs for the same RR type (that
should certainly be discouraged) - or for used of ANY type lookups,
which I don't consider all that important.

  | Way-too-many RRs will also trigger TCP overflow
  | whichi will prevent lookups from working at all.

There's no way a FOO RR type can prevent my A lookups from working,
regardless of how many RRs are there.   Nor can 2 or 3 hundred other
RR types defined at the same node.

  | This is my primary concern: the main function of the DNS is for lookups,

The only function of the DNS was for lookups - before DynDNS, that (and the
odd zone transfer) were all it could do.   But you seem to have "lookups"
defined somewhere with a particular kind of data being returned, whereas
I can see no justification for that.

  | A lot of the filtering effort comes from trying to keep things like MX out
  | of DNS.

Then that is wasted effort, as that would not be a sane result.

  | Putting MX into the DNS in the first place could be considered a
  | mistake by my defintion.

It could be considered to be that way, but without any rational
justification.   If MX is on the "wrong side", then I don't think
there's any data in the DNS that would justify staying, certainly I
don't see A or PTR as being any different than MX.  Certainly not HINFO
or MB.   I guess you'd just be left with the RRs that build the tree
(NS and SOA), without which there would be no DNS at all.   But at that
stage, there wouldn't be a lot of use delegating domains.

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

RRs like MX (eg; SRV) are just fine in the DNS - that's exactly the kind
of thing it ought be used for.   I wouldn't even look very closely at that
kind of RR (other than the definition of its data format - SRV certainly
had a bunch of that in its time).

The ones that are more problematic are stuff like the (proposed) apl RR,
which just doesn't seen to be able to drum up sufficient interest (and
hence most likely wouldn't really ever be used), and the (still? proposed)
kitchen sink rr, which overloaded an RR type so that people could add
random data without needing to get their own RR type.   This isn't to say
that those ones are automatically no good - just that those are the types
of requests that demand greater scrutiny, not anything which smells like MX.

kre



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