I have a few problems with this...but, it at the same time fulfil a few
other "requirements" I see.
What _I_ am looking for (I am not asking everyone to agree with me):
The record should be found using the same owner as the MX, and
this so the record will end up in the same zone as the MX -> makes
DNSSEC more interesting for this application.
This gives we might have:
foo.com. IN MX a.b.c.
foo.com. IN XX 192.168.1.1 <--- Just an example, domain->IP address
a.b.c. IN A 192.168.1.1
Now, if the record is at the target of the MX instead, I see two
problems:
foo.com. IN MX a.b.c.
bar.com. IN MX a.b.c.
a.b.c. IN XX foo.com / 192.168.1.1 <--- Just an example, domain->IP
address
a.b.c. IN XX bar.com / 192.168.1.1 <--- Just an example, domain->IP
address
a.b.c. IN A 192.168.1.1
First problem:
What happens if the owner of bar.com doesn't like their mail provider
and removes the MX? There will still be the old XX record close to the
target of the old MX. Is it bad if that is still laying around?
Second problem:
How do we protect a hijacked domain from "simply" producing the XX
record at the target at a potential MX, and faking a situation like the
first? Will applications really look up the MX first, and then the XX,
or will they take a short-cut and just look up the XX? If this happens,
we have the ability to inject a false XX record, and not only an old
one.
Third problem:
If the target of the MX is hosting thousands of virtual domains, what
will the selection criteria for the individual domains be when looking
for the XX record? Will we end up doing prefix:ing instead? If we do
this, then we have the risk for a delegation (if the record is
foo.com.a.b.c., then we might have com.a.b.c IN NS ...) and once again
a disconnect between the real owner of the a.b.c record and the XX
record. A false NS record (or false glue in some cache) in there might
do bad stuff.
Fourth problem:
I don't see how this solves the wildcard problem. If the domain name is
unknown (*.foo.com) it will be unknown at the target of the MX as well.
But, I have not heard the description, and don't know any details.
I am just nervous.
paf
On Jun 4, 2004, at 07:30, Nate Leon wrote:
This was raised (probably by the same guy :-) at the SPF BOF. Suresh
Ramasubramanian from Outblaze strongly echoed his sentiment. I didn't
hear any disagreement. More work for implementers, but interesting.
Nate
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Andrew
Newton
Sent: Thursday, June 03, 2004 10:14 PM
To: MARID WG
Subject: Using MX as the pointer to the other RR
At the INBOXEVENT, I had an interesting talk with a gentlemen working
for an email hosting provider. His company hosts email but rarely DNS
for their customers (the split was something like 2,000 domains that
they host vs. 65,000 that are customer hosted). As I recall, there are
a couple of spam-filtering companies that do this too (MX redirection).
His comment was that it is very difficult for them to get the
customers to correctly add/change MX records and fears that a MARID
record would be much more difficult.
So he had an interesting idea. He suggested that instead of looking
for the MARID record in the domain of the sender, look for it at the MX
target of the sender. This solves his problem since his DNS zone is
the MX target. This also leads to a solution to the wildcard issue.
Comments?
-andy