BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Al Stu
Al_Stu at Verizon.net
Tue Jan 27 16:46:05 UTC 2009
So then you disagree that the following example returns a valid address
record for srv1?
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.xyz.com.
@ 300 IN MX 1 mx1.xyz.com.
1) Select Target Host:
The MX query for xyz.com delivers mx1.xyz.com which is a CNAME.
2) Get Target Host Address:
The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com,
1.2.3.4, and also delivers 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_Andrews at isc.org>
To: "Al Stu" <Al_Stu at Verizon.net>
Cc: <bind-users at lists.isc.org>
Sent: Tuesday, January 27, 2009 1:46 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
>
> In message <10B3763032C94AE2BA4900B3137D1CE6 at AHSNBW1>, "Al Stu" writes:
>>
>> 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.
>
> Them why are you complaining? The error message is only emitted
> when you add such a alias.
>
>> "No one is saying a CNAME is not permitted in response to a MX query."
>
>> Well good then, we agree.
>
> No.
>
>> The MX record data value can be a CNAME.
>
> No.
>
>> 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_Andrews at isc.org>
>> To: "Al Stu" <Al_Stu at Verizon.net>
>> Cc: <bind-users at 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 <B3BA5E37553642E28149093CDEE78476 at 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_Andrews at isc.org>
>> >> To: "Al Stu" <Al_Stu at Verizon.net>
>> >> Cc: <bind-users at 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 <3C802402A28C4B2390B088242A91FB9C at 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" <talklists at newgeo.com>
>> >> >> To: "Al Stu" <Al_Stu at Verizon.net>
>> >> >> Cc: <bind-users at 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 at 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_Andrews at isc.org
>> >>
>> >> _______________________________________________
>> >> bind-users mailing list
>> >> bind-users at 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_Andrews at isc.org
>> > _______________________________________________
>> > bind-users mailing list
>> > bind-users at lists.isc.org
>> > https://lists.isc.org/mailman/listinfo/bind-users
>>
>> _______________________________________________
>> bind-users mailing list
>> bind-users at 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_Andrews at isc.org
More information about the bind-users
mailing list