Re: DNSSEC - Signature Only vs the MX/A issue.

[Mark Andrews <Mark_Andrews@isc.org>]

> 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?

	MX/A/AAAA deletion attack will result in mail bounce that
	would otherwise be queued under PNE.

	MTA's treat lookup failure differently to non-existance
	results. Under SO you will have a lot of mail bounce which
	otherwise wouldn't under PNE.  If you are clever enough you
	can also make the bounce, bounce, leading to silent loss
	of the original email.
 
> 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.

	There are lots of MX only mail domains.  I long ago (+10 years)
	stopped worrying about MTAs that don't lookup 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?

	There are still lots of those.
 
> 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?

	It would have been if we had said at the start that fallback
	was only a N year transition mechanism.  These days the
	education process would be too hard I think.
 
> 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.

	There will be more than MX records.  SRV for lots of services
	does / will require PNE.

	Anything that is attempting to deliver a robust automated
	service needs PNE.
 
> 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--
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/>