ietf-mxcomp
[Top] [All Lists]

Re: Using MX as the pointer to the other RR

2004-06-03 22:55:17

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