ietf-mxcomp
[Top] [All Lists]

RE: Towards resolution on Wildcards

2004-06-09 14:10:53

In order to reach consensus on the issue of wildcards, we would like
working group participants to answer the following questions.  Please
read through them first before responding.

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

The reason for consolidation to a single DNS MX record for mail was to
prevent a higher overhead of DNS traffic.  Consider this occurred as a
result of establishing sessions.  Now this proposal is suggesting possibly
multiple queries for every message.  It has been pointed out these TXT
records tend to be large and compare in size to the message being checked
and is now expected to reside in a DNS cache.  In addition, there may be probing
required to even find a domain level containing these TXT records resulting
from this lack of wild card.

2) Do you feel a MARID solution needs the capability of DNS wildcards?

There should be a method that minimizes the number of queries and retains a
small record size. A wildcard is but one possible method.

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)?

The underscore technique used to avoid name collision, if abandoned for TXT
records, adds to potential conflicts. Query all name servers and ascertain a
label not in use?  Allow name collision and encourage depreciated use of a
series of labels?

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

What is the advise for solutions that may attempt to also use this
technique?  Does this not forgo an ability to revise records by way of the
label?  The content of TXT is undefined and this relies on an ability to key
on its content.  Perhaps a token followed by a 32-bit record checksum and
then the text contained in the record would provide some added protection.

-Doug