The paragraph you cite regarding "LOCAL has a alias and the alias is listed
in the MX records for REMOTE..." is a peripery issue which is handled by not
doing that.
"No one is saying a CNAME is not permitted in response to a MX query."
Well good then, we agree. The MX record data value can be a CNAME. That is
what BIND is complaining about, and I in turn saying should be
changed/removed.
i.e. BIND should not complain about the following, but it does. It says the
MX record is "illegal". But it is not.
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.xyz.com.
@ 300 IN MX 1 mx1.xyz.com.
The MX query for xyz.com delivers mx1.xyz.com which is a CNAME.
The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com,
1.2.3.4, and the alias (CNAME) record of "mx1.xyz.com".
*** PLEASE don't copy me on replies, I'll read them in the group ***
----- Original Message -----
From: "Mark Andrews" <mark_andr...@isc.org>
To: "Al Stu" <al_...@verizon.net>
Cc: <bind-users@lists.isc.org>
Sent: Monday, January 26, 2009 10:03 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
In message <b3ba5e37553642e28149093cdee78...@ahsnbw1>, "Al Stu" writes:
Yes, the response to an MX query, that is the subject here. And a CNAME
is
in fact permitted and specified by the RFC's to be accepted as the
response
to an MX lookup.
No one is saying a CNAME is not permitted in response to a MX
query.
"If the response does not contain an error response, and does not contain
aliases"
See there, alias is permitted. You just keep proving the my case.
We are saying that when you lookup the address of the mail
exchanger that you shouldn't get a CNAME record. MX ->
CNAME is not permitted. Others have quoted similar text
from more recent RFC's.
RFC 974
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
I am not taking it out of context. It is very explicitly stated. And
the
context is that of locating the target/remote host by first submitting an
MX
query, then submitting an A query of the MX query result.
The text you quote is ONLY talking about the MX query.
There is no "then submitting an A query of the MX query
result" at this point in the RFC.
The MX query
result is permitted to be and alias, which in turn when submitted for an
A
query results in both the A and CNAME being returned. Thus meeting the
SMTP
RFC requirements.
----- Original Message -----
From: "Mark Andrews" <mark_andr...@isc.org>
To: "Al Stu" <al_...@verizon.net>
Cc: <bind-users@lists.isc.org>
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
>
> In message <3c802402a28c4b2390b088242a91f...@ahsnbw1>, "Al Stu" writes:
>>
>> RFC 974:
>> "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."
>
> And that is talking about the response to a MX query. The section
> from which you quote starts with:
>
> Issuing a Query
>
> The first step for the mailer at LOCAL is to issue a query for MX RRs
> for REMOTE. It is strongly urged that this step be taken every time
a mailer attempts to send the message. The hope is that changes in
> the domain database will rapidly be used by mailers, and thus domain
> administrators will be able to re-route in-transit messages for
> defective hosts by simply changing their domain databases.
>
> and the paragraph after that which you quote is:
>
> If the response does not contain an error response, and does not
> contain aliases, its answer section should be a (possibly zero
> length) list of MX RRs for domain name REMOTE (or REMOTE's true
> domain name if REMOTE was a alias). The next section describes how
> this list is interpreted.
>
> So I would suggest that you stop taking text out of context.
>
> CNAME -> MX is legal
> MX -> CNAME is illegal
>
> Mark
>
>> ----- Original Message -----
>> From: "Scott Haneda" <talkli...@newgeo.com>
>> To: "Al Stu" <al_...@verizon.net>
>> Cc: <bind-users@lists.isc.org>
>> Sent: Monday, January 26, 2009 8:09 PM
>> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
>> "Illegal"
>>
>>
>> > On Jan 26, 2009, at 7:54 PM, Al Stu wrote:
>> >
>> >> If you refuse a CNAME then it is your SMTP server that is broken.
>> >> The
>> >> SMTP RFC's clearly state that SMTP servers are to accept and
>> >> lookup a
>> >> CNAME.
>> >
>> >
>> > [RFC974] explicitly states that MX records shall not point to an
>> > alias
>> > defined by a CNAME. That is what I was talking about, are you
>> > saying
>> > this is not correct? As this is what I was under the impression for
>> > quite some time.
>> > --
>> > Scott
>> >
>>
>> _______________________________________________
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
