AM
To: bind-users@lists.isc.org
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Al Stu wrote:
History is fraught with individuals or a few being ridiculed for
putting forth that which goes against the conventional wisdom of the
masses and so called exp
2009 11:17 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and
so called experts, only to be
MX Records are NOT
"Illegal"
On Sat, 2009-01-31 at 16:55, Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
You don't get to speak for anyone else but yourself, j
same logic automobiles
should also be abolished and we should all just go back to horse and buggy.
Oh wait, those too should be abolished based on that same logic.
- Original Message -
From: "Michael Milligan"
To: "Al Stu"
Cc:
Sent: Friday, January 30, 2009 10:20 AM
Subj
of day.
Once upon a time the world was 'flat'. For some of you, apparently is still
is 'flat'.
- Original Message -
From: "Michael Milligan"
To: "Al Stu"
Cc:
Sent: Friday, January 30, 2009 10:20 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs.
Analyze this.
Query MX dns.com
Response MX nullmx.domainmanager.com
Query A nullmx.domainmanager.com
Response CNAME mta.dewile.net, A 64.40.103.249
See attached network trace.
No. TimeSourceDestination Protocol Info
1 0.00192.168.1
em in the group ***
- Original Message -
From:
To:
Sent: Tuesday, January 27, 2009 9:52 AM
Subject: e: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Al Stu" wrote:
How about these two?
nullmx.domainmanager.com
Non-authoritative answer:
Name:mta.dew
Tuesday, January 27, 2009 9:01 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
On 27.01.09 08:46, Al Stu wrote:
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.
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&q
I'll read them in the group ***
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
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 <0aa37ce829ba458b9ba2d
x27;ll read them in the group ***
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
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 , "Al Stu" write
nd 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"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND
tt Haneda"
To: "Al Stu"
Cc:
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
SM
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.
- Original Message -
From: "Scott Haneda"
To: "Mark Andrews"
Cc: "Al Stu" ;
Sent: Monday, January
there is
no need for this.
And no it does not matter if there are multiple MX records with different
preferences values.
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 2:55 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A
l"
On Tue, 2009-01-27 at 07:43, Danny Thomas wrote:
Al Stu wrote:
> So within the zone SMTP requirements are in fact met when the
> MX RR is a CNAME.
you might argue the line of it being OK when additional processing
includes an A record.
In all the time its taken him to t
"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
No it is only two steps, see the attachment (sent in previous message).
Both the CNAME and A record are returned for the mx.xyz.com DNS A request.
And this does met the RFC requirements.
- Original Message -
From: "Matthew Pounsett"
To: "Al Stu"
Cc:
Sent: Sund
Attachment (hopefully)
- Original Message -
From: "Al Stu"
To:
Sent: Sunday, January 25, 2009 10:15 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Yes, blah was supposed to be srv1.
I do receive both the CNAME and
was replaced with srv1
3) server ip address was replaced with 1.2.3.4
Requirements are met.
- Original Message -
From: "Matthew Pounsett"
To: "Al Stu"
Cc:
Sent: Sunday, January 25, 2009 9:49 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Recor
No I do not believe an extra step was added. Take the following example for
instance.
STMP server smtp.xyz.com. needs to send a message to some...@xyz.com. An MX
lookup is performed for domain xyz.com. and the domain name of mx.xyz.com is
returned. This is the first sentence:
"When a do
Records are NOT
"Illegal"
At 22:11 24-01-2009, Al Stu wrote:
Some people seem to think RFC 974 creates a standard which prohibits the
use of CNAME/alias in MX records. But very much to the contrary RFC 974
demonstrates that CNAME/alias is permitted in MX records.
RFC 974 is obs
RFC 2821 is much more recent and clearly documents in sections 3.5 and 5
that CNAME MX RR are permitted and are to be handled by SMTP MTA's.
3.6 Domains
"Only resolvable, fully-qualified, domain names (FQDNs) are permitted when
domain names are used in SMTP. In other words, names that can be r
ect and
just an attempt by ISC to get people to go along with what is only a perceived
rather than actual standard/requirement, and should be removed so as not to
further the fallacy of this perceived perception of a standard/requirement, as
it is neither a standard nor a requ
24 matches
Mail list logo
