Re: Discovering policy

[Mark Andrews <Mark_Andrews () isc org>]

> On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote:
>
> > > 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.
>
> Do not depend upon applications not to resolve addresses for root  
> names, even when a convention is explicit.  Depending upon root  
> answers to support a protocol feature unrelated to DNS is normally  
> considered a design mistake isn't it?

        No.  The root must exist.  To many things break when there
        is no root.
 
> > If you have applications which don't honour SRV's "." processing  
> > rules report the bug.
>
> Even Paul Vixie, the author, will likely agree the RFC has the "bug".

        No, it's the implementations that have the bug.

        If you want really scary "A 0.0.0.0" to indicate that you are
        offline but exist.  This is actually using 0.0.0.0 as it was
        intended. i.e. I exist but I do not know my address.

> > > 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.
>
> Who would be motivated in making the change?  Trying every address  
> record is unsuitable for today's email environment.  Its time for a  
> change.

        I suspect the SMTP vendors would pick it up reasonably quickly.

        I suspect everyone that uses "MX 0 nonexistant" today would
        pick it up.

        I suspect everyone has a SPF record indicating they don't
        send email would pick it up.  They don't want the bounce
        traffic.

        It's usable by sites with idiotic resolver libraries that
        can't return unknown record types.

> > SPF is optional.  MX processing is NOT optional.
>
> MX records should not optional, but they are.

        I said MX processing.  You *have* to do the lookup.
 
> > 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.
>
> Publishing wildcard MX root records everywhere represents a poor and  
> possibly hazardous solution.
>
> > > Policy will often require a greater amount of information.
> >
> > This is a simple binary decision.  I want email for this domain or  
> > not.
>
> A policy may need to express whether the domain signs some or all of  
> their outbound messages.  Not very binary is it?
>
> > > 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.
>
> Policy is not normally published for inbound traffic.  SMTP  
> extensions negotiate inbound policy requirements.  However, policy  
> could be essential for outbound traffic.  A domain name might be the  
> subject of phishing attacks.  How policy is applied must ensure even  
> sub-domains are covered.
>
> A safe strategy for applying an outbound message policy is to:
>
> - check whether there is a discovery (MX) record
>
> - no discovery record, refuse the message

        If there is a "MX 0 ." record, refuse the message
 
> - check whether a policy record is adjacent to the discovery record
>
> - no policy record, there is no policy
>
> > > 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.
>
> The SPF script processing is looking for address matches, which may  
> or may not include those within the MX record.  SPF libraries might  
> not quit after hundreds of no answers.  This behavior is just one of  
> the reasons these libraries are hazardous.  Remember an outbound path  
> may not be the same as the inbound.
>
> > You don't go to SPF processing as the source address is non repliable.
>
> When the originating domain fails to offer a discovery record?   
> Section 5.1 of the updated version of 2821 allows A or AAAA when  
> there is no MX.  This allowance must become obsolete and the process  
> ends when there is no MX record.  This means one does not have to  
> wait for unmotivated domain owners to adopt the MX root strategy.   
> Instead, those wishing to have their email accepted have a powerful  
> motivation to publishing a valid MX record.  At that point, much  
> sooner than for your scheme, no MX will then mean no acceptance or  
> will indicate where policy can be found.

        There are lots of people who have "MX 0 nonexistant" today
        for domains for which they don't want email.  All of those
        break sanity checks for MX records.  Have exactly one exception,
        "." is codable.
 
> Your scheme now means that:
>   - both the MX root records must be wildcards published at every  
> existing node
>   - policy records must also be wildcards published at every existing  
> node
>   - or the recipient must walk up the domain

        No.  You don't need policy records if you treat "MX 0 ."
        as no email shall be sorced from this domain.  You want to
        block email from sites with no MX records.  "MX 0 ." is
        equivalent to having no MX records.

> Your scheme will not scale, especially when replicated by other  
> protocols.  This approach risks root and second level domains.   
> However, policy at the discovery record can scale and is much safer.

        What other protocols are unauthenticated PUSH transfers?
        Just about all the other protocols a pull transfers and / or
        authenticated. 
 
> -Doug
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews () isc org