North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Discovering policy

  • From: Douglas Otis
  • Date: Wed Aug 15 22:44:34 2007



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?


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".


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.


SPF is optional. MX processing is NOT optional.

MX records should not optional, but they are.


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

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


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


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.

-Doug