In message <0aa37ce829ba458b9ba2d199a6d96...@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_andr...@isc.org>
To: "Al Stu" <al_...@verizon.net>
Cc: <bind-users@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 <2d378cb064ba4d06880aed8ed81f3...@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" <uh...@fantomas.sk>
>> To: <bind-users@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, bsfin...@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, uh...@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@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
_______________________________________________
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
