Eric A. Hall wrote:
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.
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.
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.
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?
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.
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