On Jun 15, 2007, at 6:55 AM, Charles Lindsey wrote:
On Jun 13, 2007, at 3:47 AM, Charles Lindsey wrote:
And those querying MX records to see if a 'conventional' address
such as 'nomail.invalid' is present do not then need to try to
retrieve its IP address.
Spam is often highly distributed, perhaps to millions of servers.
When such spam induces DNS resolution of bogus names, negative
responses might be cached for a few minutes, and in some cases not
at all. RFC2308 'suggests' using the SOA minimum field, which is
often 1 day at the root.
Yes, the root server I looked at had one day, which means that the
non-existence of the 'invalid' TLD should be cached for that long.
The "invalid" TLD might be cached, not should be cached. Of course
might should be a should.
There is _no_ assurance negative caching is implemented.
It seems to be required by RFC2308. I should think it is now
implemented on most resolvers worldwide.
Sorry, but no. There are many problematic implementations where
negative caching has been disabled to facilitate faster recovery.
This happens fairly often in "corporate" environments using
admittedly problematic network handling.
Negative caching is NOT required by RFC2308. Here is a section that
makes this clear.
----
2.2.1 - Special Handling of No Data
...
3 - Negative Answers from Authoritative Servers
Name servers authoritative for a zone MUST include the SOA record of
the zone in the authority section of the response when reporting an
NXDOMAIN or indicating that no data of the requested type exists.
This is required so that the response _may_ be cached. The TTL
of this
record is set from the minimum of the MINIMUM field of the SOA
record
and the TTL of the SOA itself, and indicates how long a resolver
_may_
cache the negative answer. The TTL SIG record associated with the
SOA record should also be trimmed in line with the SOA's TTL.
----
To safely thwart spammers without hammering roots, point targets
within the MX records to 192.0.2.0/24 address space. See RFC3330.
Yes, an MX record pointing to some 'conventional' address in that
space would serve our purpose, but I think MX records are supposed
to point to domains rather than IPs.
Yes. Within _your_ domain of "<example.com>", you could have
"invalid.<example.com>" as a target in the MX record which then
points to 192.0.2.2.
In the case of MX records, it is code, not people, that see
"nomail.invalid". A well considered scheme will not induce
automated use of bogus names which might then pound root severs.
Perhaps a TLD of "invalid" could be established.
It IS established (see RFC 2606), and if you stare at the ICANN
website for long enough you will find they have agreed never to
allocate it. But registering it on the root servers with a huge TTL
would indeed help.
These damains are established to prevent conflicts with test code
that might be inadvertently found in the wild. Indeed when there is
a chance a human might see the domain name, "???.invalid" would make
it clear to the human. It would not be clear to code that will use
this domain in an automated fashion.
But, as has been pointed out to you, that "deprecation of A
records" is just not going to happen. I am just trying to point
out an alternative that might work instead.
This is _not_ about deprecating A records. It is about
deprecating their use for discovery.
I don't believe that is going to happen either.
Do you use MX records to locate your SMTP servers? What percentage
do not?
Could MX records be a requirement for email-domain _acceptance_ in
some cases?
The small percentage of email-domains might then feel obligated to
publish an MX record. These MX records will be _valid_ and point to
_valid_ host names.
The alternative you recommend is that the entire name space be filled
with bogus wildcard and non-wildcard MX records pointing to bogus
host names?
You envision massive publishing of bogus MX records pointing to bogus
host names, rather than publishing a few appropriate MX records
pointing to valid host names?
What a mess. One must hope others don't share this view. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html