BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
Al Stu
Al_Stu at Verizon.net
Tue Jan 27 06:34:00 UTC 2009
Your dig just further proves the point. smtp.secureserver.net is listed as
the MX server for secureserver.net. Yet smtp.secureserver.net is an alias
which points to the smtp.where.secureserver.net A record which has an
address of 208.109.80.149.
*** 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 6:17 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
>
> In message <0AA37CE829BA458B9BA2D199A6D96ED2 at AHSNBW1>, "Al Stu" writes:
>> How about these two?
>>
>> > nullmx.domainmanager.com
>> Non-authoritative answer:
>> Name: mta.dewile.net
>> Address: 69.59.189.80
>> Aliases: nullmx.domainmanager.com
>>
>> > smtp.secureserver.net
>> Non-authoritative answer:
>> Name: smtp.where.secureserver.net
>> Address: 208.109.80.149
>> Aliases: smtp.secureserver.net
>
> Which just goes to show you don't understand the issue.
>
> Ask the correct question and you will see a response which
> demonstates what people are talking about. If the server was
> doing what you say it does you would see the CNAME in the
> additional section.
>
> ; <<>> DiG 9.3.6-P1 <<>> mx secureserver.net @cns2.secureserver.net.
> +norec
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21506
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;secureserver.net. IN MX
>
> ;; ANSWER SECTION:
> secureserver.net. 3600 IN MX 0 smtp.secureserver.net.
>
> ;; AUTHORITY SECTION:
> secureserver.net. 3600 IN NS cns2.secureserver.net.
> secureserver.net. 3600 IN NS cns1.secureserver.net.
>
> ;; ADDITIONAL SECTION:
> cns1.secureserver.net. 3600 IN A 208.109.255.100
> cns2.secureserver.net. 3600 IN A 216.69.185.100
>
> ;; Query time: 181 msec
> ;; SERVER: 216.69.185.100#53(216.69.185.100)
> ;; WHEN: Tue Jan 27 12:54:26 2009
> ;; MSG SIZE rcvd: 125
>
>> There are two reasons it does not blow up in peoples face. 1) If it is
>> in
>> the CNAME RR points to an A record in the same zone, both the A record
>> and
>> the CNAME record are returned, thus meeting the A record requirement. 2)
>> SMTP servers are required to accept an alias and look it up. Thus there
>> is
>> no need for this.
>
>> And no it does not matter if there are multiple MX records with different
>> preferences values.
>
> Which just means you have not ever experienced the problems
> causes. MTA are not required to look up the addresses of
> all the mail exchangers in the MX RRset to process the MX
> RRset. MTA usually learn their name by gethostname() or
> similar and that name is not a CNAME or there is a
> misconfiguration.
>
> The fact that email still gets delivered in the presence
> of misconfigurations is good luck rather than good management.
>
> Mark
>
>> ----- 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 2:55 PM
>> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
>> "Illegal"
>>
>>
>> >
>> > In message <2D378CB064BA4D06880AED8ED81F3027 at AHSNBW1>, "Al Stu" writes:
>> >> "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."
>> >>
>> >> Above statement, belief, perception etc. has already been proven to be
>> >> a
>> >> fallacy (see the network trace attached to one of the previous
>> >> messages).
>> >> Both the CNAME and A record is in fact returned, unless the CNAME RR
>> >> points
>> >> to some other zone such as say smtp.googlemail.com.
>> >
>> > Please show one vendor that follows a CNAME when processing the
>> > *additional* section. AFAIK there is no vendor that does this.
>> > Named doesn't.
>> >
>> > CNAME is followed when processing the *answer* section.
>> >
>> >> So within the zone SMTP requirements are in fact met when the MX RR is
>> >> a
>> >> CNAME. So there is no need to prevent this nor to label it as
>> >> "illegal".
>> >> The MX RR CNAME check should be improved to include this case and not
>> >> throw
>> >> a message if the MX RR CNAME is resolvable within the zone.
>> >
>> > A lot of the reason why people think they can do this is
>> > that it doesn't always blow up in their faces when they do
>> > it. When there is only one MX record and that name points
>> > to a CNAME the MX records are not looked up on the mail
>> > exchanger so things don't blow up. Have multiple MX records
>> > with different preferences and point those at CNAMEs then
>> > thing start blowing up because the higher preference mail
>> > exchanger does lookup the MX RRset and does processes it.
>> > That is when things blow up. The rules are there to prevent
>> > this situation.
>> >
>> > The message is staying. If you don't want to see it turn
>> > it off in named.conf but don't log a bug report complaining
>> > that we didn't detect the misconfiguration.
>> >
>> > Mark
>> >
>> >> ----- Original Message -----
>> >> From: "Matus UHLAR - fantomas" <uhlar at fantomas.sk>
>> >> To: <bind-users at lists.isc.org>
>> >> Sent: Monday, January 26, 2009 8:18 AM
>> >> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
>> >> "Illegal"
>> >>
>> >>
>> >> > On 26.01.09 09:19, bsfinkel at anl.gov wrote:
>> >> >> If I have in DNS
>> >> >>
>> >> >> cn IN CNAME realname
>> >> >>
>> >> >> and I query for cn, the DNS resolver will return "realname".
>> >> >> BIND also returns the "A" record for realname. Is this a
>> >> >> requirement?
>> >> >> If not, then
>> >> >>
>> >> >> mx IN 10 MX cn
>> >> >>
>> >> >> will result in:
>> >> >>
>> >> >> 1) the MX query returning cn,
>> >> >>
>> >> >> 2) the cn query returning realname,
>> >> >>
>> >> >> 3) a third (and RFC-breaking) query to get the "A" for
>> >> >> realname.
>> >> >>
>> >> >> There are only two queries if the resolver returns the "A" record
>> >> >> along
>> >> >> with the realname of the CNAME record.
>> >> >
>> >> > according to RFC1035 sect. 3.3.9
>> >> >
>> >> > "MX records cause type A additional section processing for the host
>> >> > specified by EXCHANGE."
>> >> >
>> >> > according to RFC2181 sect 10.3.
>> >> >
>> >> > "The domain name used as the value of a NS resource record, or part
>> >> > of
>> >> > the
>> >> > value of a MX resource record must not be an alias."
>> >> >
>> >> > "It can also have other RRs, but never a CNAME RR."
>> >> >
>> >> > "Additional section processing does not include CNAME records"...
>> >> >
>> >> > "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."
>> >> >
>> >> >
>> >> > --
>> >> > Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
>> >> > Warning: I wish NOT to receive e-mail advertising to this address.
>> >> > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>> >> > "The box said 'Requires Windows 95 or better', so I bought a
>> >> > Macintosh".
>> >> > _______________________________________________
>> >> > 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
>>
>> _______________________________________________
>> 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
More information about the bind-users
mailing list