Discovering policy

Mark Andrews Mark_Andrews at isc.org
Thu Aug 16 00:34:16 UTC 2007



> 
> On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:
> 
> >
> >> On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
> >>>
> >>>  Since all valid email domains are required to have a working  
> >>> postmaster you can safely drop any email from such domains.
> >>
> >> Use of root "." as a name for a target may create undesired non- 
> >> cached traffic when applications unaware of this convention then  
> >> attempt to resolve an address for servers named root.
> >
> >  All modern iterative resolvers are required to support negative  
> > caching.
> 
> Indeed, RFC 2308 changed negative caching support from optional for  
> any caching resolver.  Those that have negative caching may  
> significantly truncate the duration.  There are several websites  
> recommending negative caching be disabled to permit faster recovery  
> from intermittent negative answers.  In other words, a negative  
> answer is less likely to have been cached.  Use of root target names  
> will impact roots in cases where:
> 
> - an assumption of negative caching is wrong,
> - for MX records where the root name convention is not in place.
> 
> With email, transaction rates are high and highly distributed which  
> tends to diminish negative caching protections.
> 
> >> The use of root as a convention will complicate a general strategy  
> >> identifying adoption of a protocol by publication of a discovery  
> >> record.  The use of root as a target name in SRV records has been  
> >> problematic, although this convention was defined for SRV records  
> >> at the outset.
> >
> >> Using an MX record to mean "no email is accepted" by naming the  
> >> target 'root' changes the meaning of the MX record.
> >
> >  Not really.  It's entirely consistant with existing DNS usage  
> > where "." is a domain name / hostname place holder.
> >
> >  Lots of RR types use "." to indicate non-existance.
> 
> Yes, and this convention still generates nuisance root traffic  
> whenever the application fails to comprehend "." is a special  
> target.  This is true even when _defined_ as a special target for the  
> specific resource record, as with SRV.  In the case of an MX record,  
> there is _no_ such definition.

	So we write a RFC.  That I though was implicit.

	If you have applications which don't honour SRV's "."
	processing rules report the bug.
 
> >> It is also not clear whether the root target would mean "no email  
> >> is sent" as well.
> >
> > That is, I'll agree, more of a issue but no one can reasonably  
> > expect people to accept non-repliable email.
> 
> That would have been made clear by simply requiring MX records for  
> acceptance!
> 
> >> A clearer and safer strategy would be to insist that anyone who  
> >> cares about their email delivery, publish a valid MX record.   
> >> Especially when the domain is that of a government agency dealing  
> >> with emergencies.  At least FEMA now publishes an MX record.  This  
> >> requirement should have been imposed long ago. : )
> >
> > I much prefer positive data vs the absence of data to make a  
> > decision.  "MX 0 ." is a definitive response saying you don't want  
> > email.
> 
> Not having an SMTP server and no MX record provides a clear  
> indication of a policy "I don't want email."

	Which requires a SMTP server to attempt the TCP connection.
	It also requires the SMTP server to re-try until it times
	out the messages which could be days.

	SPF is optional.  MX processing is NOT optional.

	Most SMTP client will fail immediately if they get a
	positive indication that there are no address records
	for the MX.  Fixing them not to ask the question is
	a optimisation.

> Policy will often  
> require a greater amount of information.

	This is a simple binary decision.  I want email for this
	domain or not.

> To discovery policy must  
> the entire domain be queried?

	You have the name.  It has a address.  You don't want email to
	be sent there.  You add a single MX record next to the address.
	No seaching.  Just direct query.

> A wildcard MX record and root name  
> convention exposes a domain to an SPF script attack, where a  
> different convention is expected for no email.

	No the presence of the record with "." as the MX target
	would stop all further processing.  You don't go to
	SPF processing as the source address is non repliable.

> In this case, one  
> cached SPF record may utilize a sequence of originating email-address  
> local-parts in a spam campaign to generate 10, 20 or perhaps 30 MX  
> record transactions per message.  Each MX transaction might be given  
> a maximal label size as well.  This attack would completely free for  
> spammers and would not expose their 0wned systems, as the attack will  
> emanate from the recipient's resolvers.  Email logs may not offer  
> clues in how the attack happened, as victim domains might have been  
> obfuscated by a combination of local-part and SPF script.  And yes,  
> SPF is another method some recommended for expressing email policy.
> 
> When can the recipient of a message know whether the originating  
> domain expressed policy that goes beyond NO?  Query all TXT RR?   
> Examine policy at some policy location?  The only place where policy  
> should published is at a protocol discovery record.  In the case for  
> email, it would be at the MX record.  Wildcards for policy will  
> likely create other problems.
> 
> The XPTR proposal by Phillip Hallam-Baker envisions such a wildcard  
> scheme where a new pointer record is to be published at _every_  
> existing node.
> 
> http://www.ietf.org/internet-drafts/draft-hallambaker-xptr-00.txt
> 
> A simpler scheme would be to require a protocol discovery record and  
> then expect any related policy be published adjacent to the discovery  
> record.  For email, the MX record would be a protocol specific  
> discovery record.
> 
> -Doug
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the NANOG mailing list