1) During the MARID interim meeting, Ted Hardie suggested a
dual record
type approach whereby TXT would be used in servers incapable of
supporting a new record type, but more capable servers would
use a new
record type (specifically defined for MARID). Do you feel this is a
workable solution? (Reference Margaret Olson's description here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01512.html).
If we did this, we'd have a MARID client (DNS UDP client) querying a DNS
server first for the MARID record type and then for a TXT record. Without
this, there'd be no incentive to move to a unique record type.
However, we'd add more work to an already network-intensive process.
Multiple queries per e-mail were shot down in the original DMP mailing list
as being too network-intensive - the idea of looking for a record and on
NXDOMAIN look for some kind of placeholder, in this case. If that can get
shot down, multiple queries here will get shot down, too. And supposedly
some DNS servers won't even return NS records for queries of unknown record
types, but that's just heresy.
If implementors and "purists" can get past arguments against multiple
queries, then a migration path like this will work and you can use TXT to
start followed by a unique type.
2) Do you feel a MARID solution needs the capability of DNS wildcards?
To create one record to cover multiple nodes in one's DNS zone? I thought
this wouldn't work if any nodes up the DNS tree were defined, for example:
$origin example.com.
@ in marid [useful marid data 1]
* in marid [useful marid data 2]
host in a 192.0.2.1
If I queried example.com for a record of type "marid" I'd get [useful marid
data 1]. If I queried anything but host.example.com for a record of type
"marid" I'd get [useful marid data 2]. If I queried for host.example.com for
a record of type "marid" I'm supposed to get NXDOMAIN.
Needing the capability of wildcards? Sure, to prevent spoofing a subdomain.
Workable? Not without changing existing DNS wildcard semantics.
3) If you answered "yes" to both of the above questions, then is it
reasonable to expect DNS wildcard capability only with the new record
type and not the TXT usage (because TXT may be defined to use a
prefix)?
If you want to say the wildcard will work with one record type but not
another, you're changing DNS semantics again.
And can't you have more than one TXT record at a given DNS node? Why can't I
do the following?
$origin example.com.
@ in txt [data completely irrelevant to marid]
@ in txt [useful marid data 1]
* in txt [useful marid data 2]
* in txt [some other data irrelevant to marid]
host in a 192.0.2.1
If I query example.com for TXT I'm supposed to get [data completely
irrelevant to marid] and [useful marid data 1]. If I query anything but
host.example.com for TXT I'm supposed to get [some other data irrelevant to
marid] and [useful marid data 2]. If I query host.example.com for TXT I
should get NXDOMAIN.
Or am I completely off base with DNS wildcard behaviour here?
4) If you answered "no" to either (1) or (2), then do you feel it is
acceptable for TXT reuse to specify a prefix and that environments
needing DNS wildcard behavior may do so at the risk of collision or
other side-effects? (Reference
http://www.imc.org/ietf-mxcomp/mail-archive/msg01691.html for
discussion of this).
If I'm not completely off base here, I don't think TXT records storing MARID
data need to be prefixed with _ep or anything else. But the MARID client
must be able to parse all received records for valid data. Parsing
information already received does not require any more network bandwidth.
If it's just a matter of appearance to us humans editing MARID TXT records,
to group all of the MARID records somewhere, well, it doesn't make a
difference. If it's a matter of being able to dynamically change such a
record, well, then it makes more sense so you don't overwrite any existing
TXT record the domain already has.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>