Discovering policy

Wed Aug 15 16:33:55 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.

>> 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."  Policy will often  
require a greater amount of information.  To discovery policy must  
the entire domain be queried?  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.  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