DNSSEC - Signature Only vs the MX/A issue.

[Mike StJohns <Mike.StJohns@nominum.com>]

Rob Austein brought up one of the few issues that I hadn't previously 
considered.

His question - In the signature only model, what happens if an 
attacker does a deletion attack on the MX record at a label forcing 
the MTA to fall back to looking up the "A" record?

In PNE, this isn't an issue as you can determine whether or not the 
MX record actually existed.

There's a couple of things that should be said here.  The MX/A 
fallback was simply a hack to deal with the early days of the 
internet and the transition from host table to DNS.  Most email 
accounts were tied to machines on which people had accounts.  The PC 
as an internet node was still quite a few years away.  The host table 
model (prior to DNS) basically mapped stjohns@umd5.umd.edu to email 
on umd5.umd.edu and used the IP address in the host table as the 
delivery address.  Most MTAs at that point had no concept of MX 
records nor did the admins of the various subnets.  When DNS came 
out, most MTAs still queried only for A records, but eventually 
started querying for MX records.  At this point in time, I'd be 
surprised if there are more than a very few MTAs that don't lead with 
MX queries.  Anyone have data on any MTAs that don't lead with MX records.

Of course, there may also be zones (or names within zones) that host 
MTAs, but that don't also have MX records - anyone have data on this?

I chatted briefly with John Klensin about deprecating this MX/A 
alternate in the next revision to RFC2821 - comments on whether this 
is a reasonable approach?

Going forward, if an MTA is adapted to use SO, it may be a reasonable 
policy to require MX records for a "validated" result.  If an MX 
record doesn't exist, or if its unsigned, then the output of the 
validator would be "unvalidated"  regardless of any validation on the 
"A" alternate and the MTA would take whatever action is appropriate 
for any unvalidated response. The guidance to use MX records would 
added to the general guidance for anyone managing an SO zone.


Any other ideas in this general topic?

Mike




--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>