Subject: Designing and Allocating a new RR type

From: Hadmut Danisch <[email-masked]>
Date: Thu, 24 Jun 2004 18:29:59 +0200

My current thoughts about how a new RR type should
look like:

We should not allocate a MARID record type (surprise!)

We should contact the DNS crew and cooperate with them
to invent a new generic binary container RR type, not
specific to MARID.

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

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

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

I vote for ASN.1 with OID.

I believe such an easy to implement and generic record
suitable for other uses than MARID too would be accepted
and implemented much faster.

regards
Hadmut

---

From: Claus Assmann <[email-masked]>
Date: Thu, 24 Jun 2004 09:52:28 -0700

> - ASN.1 tagged with a OID for unambigous identification

Hmm, people are discussing possible security problems due to the
use of XML. What about ASN.1? It seems that writing a parser for
it is not trivial; just look at some OpenSSL security advisories:

    o Security: fix vulnerabilities in ASN.1 parsing
      CAN-2003-0543, CAN-2003-0544                            [0.9.7c & 0.9.6k]
    o Security: fix additional vulnerability in ASN.1 parsing
      CAN-2003-0545                                                    [0.9.7c]

---

From: wayne <[email-masked]>
Date: Thu, 24 Jun 2004 12:11:55 -0500

> to invent a new generic binary container RR type, not

Huh.  I hadn't thought about that for a binary record.

I had thought that the DNS folks should allocate something like 10
generic TXT records in the RR type range of 0-255 and another 100 in
the range of 256-65536.  People would be free to pick and choose
whichever one they wanted with far less chance of collisions.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jun 2004 10:25:07 -0700

On Thu, 2004-06-24 at 09:29, Hadmut Danisch wrote:
<snip>
> SRV records. So this should not be an issue.

This is an issue if wild cards are used.

> or decode it, just forward it as it is.

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

> the container should contain

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

> - ASN.1 tagged with a OID for unambiguous identification
>   of the content type
> 

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

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 24 Jun 2004 19:43:14 +0200

>the sender with an SRV mechanism is safer and more extensible.

  * sigh *

That's why I proposed RMX++ which does exactly that. For
exactly those reasons. Almost no resonance yet.

Hadmut

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 24 Jun 2004 13:17:29 -0500

I think that the idea of using ASN.1 is fine as an architectural point
(DNS certainly suffers from a lack of strict data-typing), but it's
overkill for what we need, while the implementation and potential exploit
problems are on par with XML. So I don't think we should use it for this
specific RR. Too much work for too little gain.

Remember that every ~100 bytes of RR data is roughly the same as whatever
was cached from PTR/A/NS lookups, and saving ~30% or so on that is a good
enough target, so getting to ~70 bytes per RR is really what we should be
looking to reasonably achieve.

If the scope of data is limited, it will probably be good enough to have
coded types and textual field data within the limited subset of types.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 24 Jun 2004 21:45:12 +0200

>specific RR. Too much work for too little gain.
I don't see how ASN.1 should be any more exploitable than
SPF. You have a strict set of data types, one-byte-tags and
length fields. Even if there were a few bugs in implementations,
there were bugs in any kind of software. Are SPF parsers
free of bugs by design?  Or parsers for other binary formats?
Why should writing a new thing from scratch be more safe than
e.g. using existing ASN.1/DER parser generators?

I believe ASN.1 parsers will be less overhead than SPF due to a
small set of well defined data types. Significant fewer cases to
handle. Less string operations. Existing tools to check and
proofread the structure. On linux there is an asn1dump program,
which dumps any ASN.1 structure (if not too much use of IMPLICIT was
made). How much overhead is it to have a syntax checker for SPF?

Before I got that asn1dump program, I wrote a similar program on my own
from scratch. Straigth forward work, rather simple. Much easier than
writing an SPF or XML parser. The only disadvantage about ASN.1
is that the existing books about it make it look much more complicated
than in actually is.

And I believe it is a good design decision to not have a new proprietary
encoding for every RR type, but to start using generic standard encoding,
as done with e.g. LDAP.

>looking to reasonably achieve.

Isn't this a strong argument for ASN.1? DER can be quite compact.

I admit that with ASN.1/DER you have two different styles:
Have everything tagged and make things a little bit bigger (without 
using IMPLICIT),
or make use of IMPLICIT, omit the tags were redundant, and get a very small
and compact encoding, were a parser must know the data structure.

But I think having that choice is an advantage, not a disadvantage.
ASN.1/DER is well proven. It is used for X.509, SNMP, LDAP, Kerberos V5, ...
were they roughly have the same requirements as we have them here.
Why should we make a different choice?

>coded types and textual field data within the limited subset of types.
OK, make a proposal.

But I still believe that textual field data is a disadvantage: MARID 
records will in
 >99% not be read directly by humans, but interpreted by machines.
What is better: Storing IP addresses in decimal ASCII dot notation,
and have every machine convert it every time, or to store it
as binary in network order?

And if read by humans, the DNS records are subject to decoding anyway.

regards
Hadmut