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