On 25 May 2004, John Levine wrote:
Last week we were arguing about using a TXT record vs. using a new
MARID record type, and since _ep.*.foo.com doesn't work with existing
DNS servers, the question came up whether there's a lot of people
using wildcard MXes.
That was quite clear from the start despite objections from the M company
people. Perhaps because their windows dns server has problems with how
wildcards are implemented and nobody is using it in that way and they think
its not used at all. But in reality windows dns server is rare choice for
dns where greater majority run on unix and even on windows different dns
server software is usually used especially for large number of zones.
I checked around and there are indeed a lot of them. Any scheme that
doesn't support wildcards will break a lot of existing mail systems
and make it impractical to deploy useful new ones.
Agreed.
All this shows that people really do use wildcards for mail. I see
three ways to make this work with MARID:
a) define a MARID record type and tell people with strange firewalls
that can't deal with new record types to do MARID validation at the
gateway. (This is a reasonable design, although I realize there are
plenty of unreasonable systems around.)
My understanding is that we're going to ask for new MARID record type
anyway while at the same time suggesting that until infrastructure can
be upgraded, clients can continues to use TXT record.
As such a) is not really a choice but we still need support for wildcards
for TXT.
b) use TXT records in the same domain as the MXes, start them all with
a unique string that serves as a magic number, and hope that other
applications that use TXT records don't get too confused.
Ok
c) put TXT records in subdomains and tell people that use wildcards
that they'll have to use peculiar DNS servers to serve up their
_ep.*.domain TXT records.
What was discussed at the meeting is approach to this where if direct
lookup for _marid.user.host.domain.com fails, then as part of the failure
code dns server provides AUTHORITY section which contains information
about actual domain zone (i.e. most likely domain.com) and then lookup
can be done to _marid.domain.com for the default record.
I note however that above approach will mean that during initial deployment
there would often be necessary for clients to send 3 consequative dns queries
and that is often just to find out that there is not MARID record for domain:
Query 1: For MARID type if supported by client
Query 2: If no MARID record entered, then lookup _marid.host TXT record
Query 3: If no _marid.host TXT record found, lookup default _marid.domain
If not found here we can then assume there is no MARID record for this host...
Quite a bit of bandwidth waste, don't you think?
Add to that Query 3 can not be done unless Query 2 answer is received
(as data from AUTHORITY section from Query 2 is used for Query 3).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net