In message <10b3763032c94ae2ba4900b3137d1...@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_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 -- 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