ietf-mxcomp
[Top] [All Lists]

Re: Designing and Allocating a new RR type

2004-06-24 10:25:04

On Thu, 2004-06-24 at 09:29, Hadmut Danisch wrote:
<snip>
The link to MARID would be in the fqdn, i.e. the _marid. prefix.

Giving an entry it's content type not by the RR type only, but by
parts of the dns name also is not in the spirit of the original
DNS. DNS has nevertheless made this step already with
SRV records. So this should not be an issue.

This is an issue if wild cards are used.

This way we also have a container for future work, e.g. when
describing what kind of mail a receiver is willing to accept,
or records for other kinds of services. Or storing public keys,...

As I stated in earlier postings, DNS servers should not modify
or decode it, just forward it as it is.

Returning only essential data would be good; preferably in binary
structures.

It would be to be discussed with the DNS people whether
the container should contain

Named references to RFC 3123 record types returned in the Additional
Data section would be one choice. 

- any binary data
- ASN.1 encoded data only
- ASN.1 tagged with a OID for unambiguous identification
  of the content type

I vote for ASN.1 with OID.

DNS was never designed to return comprehensive answers to simple
queries.  The query should be specific with the response equally
specific.  If a broad and comprehensive answer is needed, then use an
SRV record to point to a port on an HTTP server.  Shifting processing to
the sender with an SRV mechanism is safer and more extensible.

-Doug