ietf-mxcomp
[Top] [All Lists]

Re: Wild card MXes

2004-05-25 08:45:08

Replying to both William and Andrew...


--"william(at)elan.net" <william(_at_)elan(_dot_)net> wrote:

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.


Right, the assumption here is that the "closest SOA" would be a logical place to stick a "catchall" record, if you want one record to cover all hosts in your domain or subdomain.

It's not a bad idea, because it keeps people from having to create TXT records to match all the MX and A records that already exist, but in cases where they already have a wildcard for A or MX, they may still want a wildcard TXT (since it may be different from the base MX)


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


I don't think bandwidth is going to be as big an issue as the sequential nature of it. A "does not exist" answer with authority included should be between 100 and 150 bytes. But, the sequential requirement may be a hit to performance. (Still cheaper than filtering though :)



--Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:

For instance,
they are bigisp.com (this is the domain used by their retail/residential
customers), but I get spam from x-x-x.pa.client.bigisp.com and
x-x-x.nj.client.bigisp.com where the former is covered by an SPF record
and the latter is not.  It would seem that a wildcard at *.bigisp.com
would help them out.


It should be pointed out, according to my tests, if you have a wildcard TXT, that would cover any made-up name that doesn't have any other records, but if you have names with A or MX but no TXT, the wildcard TXT doesn't apply to those.

 *.bigisp.com.   IN  TXT  "v=marid record goes here"
 www.bigisp.com. IN  A    10.2.3.4

In this case a query for "www.bigisp.com TXT" would give no answer (NOERROR result, meaning the empty set is the correct answer)

Someone should probably check my results. If this is true, that decreases the value of wildcards even more (but you still need them if you have A or MX wildcards). That's even more reason why a fallback behavior is interesting.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>


<Prev in Thread] Current Thread [Next in Thread>