In <B1419169-A8C3-11D8-810E-000A95B2B926(_at_)cisco(_dot_)com> Patrik Fältström
<paf(_at_)cisco(_dot_)com> writes:
BUT, one have to remember that:
- On the receiving side, the application have to be updated to use
whatever algorithm is specified by the
MARID-protocol-whatever-thing. As part of this upgrade you can always
query for whatever DNS record you want. The software have to be
updated anyway.
Many of the upgrades to MTAs for SPF support is a matter of updating
the MTA config files and running a new external daemon. Work is going
on to make things even simpler.
Upgrading things like dig/nslookup to correctly display the new RRs,
updating name servers on the mail server and in the DMZ/Firewall,
etc. is much more work.
- On the sending side, there is a problem because [...]
DNSSEC etc is coming, with many many new RRs. MARID is not the
only wg which is introducing (as I hope) new RR types.
Can you give some examples of new RR types that were quickly adopted
and ones that weren't? What was done right, and what was done wrong?
At the MARID BOF, there were some comments about how MARID might be
used to force the adoption of DNSSEC, new DNS software, cleaning up
the in-addr tree, etc. I recognize that these were individuals, not
official IETF policy statements and many of these were just off-hand
comments that even those individuals weren't real serious about.
Still, I am somewhat concerned.
When SPF was being developed, it was the issues raised in
draft-ymbk-dns-choices-00.txt were all discussed and I think fairly
widely understood. SPF records are short and have well-defined "magic
numbers" that go a long way to prevent collisions with other uses,
much like the "magic numbers" in unix files prevent incorrect
interpretation by the wrong applications.
The TXT records used in DMP, FSV, etc. are all even less of a problem.
Those TXT records are generally even shorter and they are in separate
parts of the domain trees.
If a new RR type needs to be created for MARID, I think that maybe the
best way to do it would be to create a generic TXT-like record. It
should have an unregulated 8-character (text) "filetype"/magic-number
that any future application could use and a (very) limited record
selection query system. Like the unregulated unix magic numbers,
there could indeed be collisions, but it has worked well in practice.
-wayne