PF> Finally, if one run a DNS server which can not by any means handle
PF> unknown RRs (even via the provisioning, for example by
use of **VERY**
PF> old version of BIND) you should most certainly upgrade your server
PF> anyway. DNSSEC etc is coming, with many many new RRs.
MARID is not the
PF> only wg which is introducing (as I hope) new RR types.
My view is that this is the sort of thing that leads to
failure of a new
proposal. It establishes problematic dependences for
otherwise-independent efforts.
DNSSEC has been comming for ten years, at this point I believe
that the best chance to deploy DNSSEC lies in MARID.
I think that any dependency of MARID on DNSSEC is total
lunacy. At the moment the DNSSEC group is arguing over
whether allowing deployment to be compliant with EU law
should be a requirement.
The way I look at it, pretty has been given a ten years long
chance. If there is to be any progress the result is going
to be something that at least someone regards as ugly.
Given that we have plenty of ugly already I don't see the
reason to insist ugly be a showstopper.
I do not see the proposals as ugly, I see them as different.
On a pure architectural level I think that prefixed TXT
record is actually superior to a new RR. With the benefit
of hindsight the resource record identifiers SHOULD have
been extensible labels all along.
The wildcard issue has been solved. It would be nice to
be able to specify wildcards of the form _marid.*.example.com
but that is not essential, if the server does not support
this wildcard, the form *.example.com is an acceptable
substitute that worst case looks like we used TXT without
a prefix.