BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Mark Andrews
Mark_Andrews at isc.org
Tue Jan 27 22:33:25 UTC 2009
In message <D53C69E1F478453A8371B49B4F04C5DC at AHSNBW1>, "Al Stu" writes:
> So then you disagree that the following example returns a valid address
> record for srv1?
The MX query won't return the A record for srv1. The
additional section processing rules say to add A / AAAA
records not CNAME records.
You fail to understand that the rule is there so that MX
processing can be done in a deterministic manner. I don't
care that when you look up mx1.xyz.com you eventually get
a address record. The damage is done long before that
lookup is performed.
Email is processed in this order:
Look up MX records.
Process the MX RRset.
Lookup address records and attempt to deliver the email.
Mark
> 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
>
> _______________________________________________
> 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