-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Julian Mehnle wrote:
They also should refer to the exact RFC clauses in question.
| Section 10.3 of RFC 2181 points out that pointing an MX RR at a
| hostname which is actually a CNAME RR is invalid, and such hosts are
| also listed.
RFC 974 (MX records), section "Issuing a Query", says:
| There is one other special case. If the response contains an answer
| which is a CNAME RR, it indicates that REMOTE is actually an alias
| for some other domain name. The query should be repeated with the
| canonical domain name.
This indicates that it was well within the intent of MX records to support
CNAMEs.
RFC 2181, section 10.3, "MX and NS records", gives the following reasoning:
| Searching for either NS or MX records causes "additional section
| processing" in which address records associated with the value of the
| record sought are appended to the answer. This helps avoid needless
| extra queries that are easily anticipated when the first was made.
|
| Additional section processing does not include CNAME records, let
| alone the address records that may be associated with the canonical
| name derived from the alias. Thus, if an alias is used as the value
| of an NS or MX record, no address will be returned with the NS or MX
| value. This can cause extra queries, and extra network burden, on
| every query. It is trivial for the DNS administrator to avoid this
| by resolving the alias and placing the canonical name directly in the
| affected record just once when it is updated or installed. In some
| particular hard cases the lack of the additional section address
| records in the results of a NS lookup can cause the request to fail.
Like Meng's "RFC 1912 is wrong" essay (which also handles RFC 2181's
argument), I cannot follow the "additional section processing does not
include CNAME records" argument.
In fact, I searched RFC 1034 for indications that not doing additional
section "processing" implies that CNAME pointers should not be resolved by
the DNS server, but I could not find any such indications.
So, basically RFC 2181 says that MX->CNAME is disallowed _because_ it can
cause extra queries and extra network burden. Going by that rationale,
the use of CNAME could be considered to be generally forbidden.
I don't think that is a useful interpretation of all those RFCs.
You could also ask the RFCI admins WTF is going on, they have a trouble
ticket system and answer queries within a day.
The thing is, I currently don't have the time to help others debug their
flawed (or at least over-zealous) blacklisting policies. I'm sure the
RFCI people are convinced of what they're doing, and trying to convince
them otherwise is really not what I would like to use my rare time for
right now.
I CC'ed their contact address, <admin(_at_)rfc-ignorant(_dot_)org>, on this
message,
but you are free to also bring it up on their mailing list if you think my
argument bears weight.
The way it is now, I don't think they can be taken seriously, at least
not as far as the bogusmx list is concerned.
Apparently the Chair of the SPF Council disagrees with your belief. Dito
Wiliam, me, and many other supporters of RFCI.
Tough luck, I guess.
it is within their full right to publish bogus blacklists.
No. You confuse this with BLARS or SORBS 127.0.0.6. The RFCI friends
are adamant about "the same rules for everybody".
If they were really convinced of _that_, they'd refrain from trying to
enforce a rule whose interpretation has proven to be highly controversial.
In that case, they'd better spend their time trying to build consensus on
how to fix the inconsistent rules regarding MX->CNAME.
If someone brings up _convincing_ arguments why MX->CNAME is technically
invalid, I will interrupt whatever I'm doing and find a better way to
structure my DNS entries ASAP. Until then, this will be my last message
on this subject.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCpdy+wL7PKlBZWjsRAp0FAJ4yee1fHREnqS+lkgCI+7MOS1ngEQCfayg+
4Cf2zLUxiyGEQeV01W1wt5g=
=w82H
-----END PGP SIGNATURE-----