BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

Al Stu

unread,

Jan 25, 2009, 1:11:06 AM1/25/09

to

This is a multi-part message in MIME format.

--===============2234905816926334461==
Content-type: multipart/alternative;
boundary="----=_NextPart_000_0063_01C97E70.A78A5EB0"

This is a multi-part message in MIME format.

------=_NextPart_000_0063_01C97E70.A78A5EB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

BIND 9.6 'named' throws the following message during startup claiming =
that it is illegal to use a CNAME/alias in the MX record. I beg to =
differ. There is no such standard nor requirement prohibiting the use =
of CNAME/alias in an MX record.

Message thrown at startup:

"named[3307]: zone MyDomain.com/IN: MyDomain.com/MX 'MX1.MyDomain.com' =
is a CNAME (illegal)"

Additionally in Chapter 6 - BIND Configuration Reference, Zone File, =
Discussion of MX Records states the MX records "must have an associated =
address record (A or AAAA) - CNAME is not sufficient."

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.

ISC's message that a CNAME/alias in an MX record is illegal is incorrect =
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 requirement, and =
certainly not illegal.

Al Stu

=20

------=_NextPart_000_0063_01C97E70.A78A5EB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16788" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman">BIND 9.6 =91named=92 throws =
the following=20
message during startup claiming that it is illegal to use a =
CNAME/alias in=20
the MX record.  I beg to=20
differ.  There is no such =
standard=20
nor requirement prohibiting the use of CNAME/alias in an MX=20
record.
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> 
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'">Message thrown at startup:
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'">"named[3307]:=20
zone MyDomain.com/IN: MyDomain.com/MX=20
'MX1.MyDomain.com' is a CNAME (illegal)"
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> 
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman">Additionally in Chapter 6 =96 =
BIND=20
Configuration Reference, Zone File, Discussion of MX Records states the =
MX=20
records =93must have an associated address record (A or AAAA) =96 CNAME =
is not=20
sufficient.=94
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> 
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman">Some people seem to think RFC =
974 creates a=20
standard which prohibits the use of CNAME/alias in MX records. <SPAN=20
style=3D"mso-spacerun: yes"> But very much to the =
contrary RFC=20
974 demonstrates that CNAME/alias is permitted in MX=20
records.
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> 
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman">ISC=92s message that a =
CNAME/alias in an MX=20
record is illegal is incorrect and just an attempt by ISC to get people =
to go=20
along with what is only a perceived rather than actual =
standard/requirement, and=20
should be removed so as not to further the fallacy of this perceived =
perception=20
of a standard/requirement, as it is neither a standard nor a =
requirement, and=20
certainly not illegal.
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman"> 
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman">Al =
Stu<o:p></o:p>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt; tab-stops: 36.75pt 73.5pt 110.25pt 147.0pt =
183.75pt 220.5pt 257.25pt 294.0pt 330.75pt 367.5pt 404.25pt 441.0pt =
477.75pt 514.5pt 551.25pt 588.0pt 624.75pt 661.5pt 698.25pt 735.0pt =
771.75pt 808.5pt 845.25pt 12.25in 918.75pt 955.5pt 992.25pt 1029.0pt =
1065.75pt 1102.5pt 1139.25pt 1176.0pt; mso-layout-grid-align: =
none"><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </o:p>
<DIV> </DIV></DIV></BODY></HTML>

------=_NextPart_000_0063_01C97E70.A78A5EB0--

--===============2234905816926334461==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--===============2234905816926334461==--

Frank Bulk

unread,

Jan 25, 2009, 2:11:04 AM1/25/09

to

This is a multipart message in MIME format.

--===============0947294185913229104==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0005_01C97E89.CC6D6330"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0005_01C97E89.CC6D6330
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Al:

If you read RFC 2181 section 10.3, RFC 1034 section 3.6, RFC 1912 (page 6),
the average person would understand that it's strongly discouraged. Perhaps
"illegal" is too strong a word, but the weight of the RFCs and best
practices appears to disagree with your assessment that "there is no such
standard nor requirement prohibiting the use of CNAME/alias in an MX
record.".

Frank

From: bind-user...@lists.isc.org
[mailto:bind-user...@lists.isc.org] On Behalf Of Al Stu
Sent: Sunday, January 25, 2009 12:11 AM
To: bind-...@lists.isc.org
Subject: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

BIND 9.6 'named' throws the following message during startup claiming that
it is illegal to use a CNAME/alias in the MX record. I beg to differ.
There is no such standard nor requirement prohibiting the use of CNAME/alias
in an MX record.

Message thrown at startup:

"named[3307]: zone MyDomain.com/IN: MyDomain.com/MX 'MX1.MyDomain.com' is a
CNAME (illegal)"

Additionally in Chapter 6 - BIND Configuration Reference, Zone File,

Discussion of MX Records states the MX records "must have an associated

address record (A or AAAA) - CNAME is not sufficient."

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.

ISC's message that a CNAME/alias in an MX record is illegal is incorrect 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 requirement, and

certainly not illegal.

Al Stu

------=_NextPart_000_0005_01C97E89.CC6D6330
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Al:<o:p></o:p>

<o:p> </o:p>

If you read RFC 2181 section 10.3, RFC 1034 section 3.6, =
RFC
1912 (page 6), the average person would understand that it’s =
strongly discouraged. 
Perhaps “illegal” is too strong a word, but the weight of =
the RFCs
and best practices appears to disagree with your assessment that =
“there
is no such standard nor requirement prohibiting the use of CNAME/alias =
in an MX
record.”.<o:p></o:p>

<o:p> </o:p>

Frank<o:p></o:p>

<o:p> </o:p>

<div>

From:=

bind-user...@lists.isc.org =
[mailto:bind-user...@lists.isc.org] On
Behalf Of Al Stu 
Sent: Sunday, January 25, 2009 12:11 AM 
To: bind-...@lists.isc.org 
Subject: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"<o:p></o:p>

</div>

<o:p> </o:p>

<div>

BIND 9.6 ‘named’ throws the =
following

message during startup claiming that it is illegal to use a =
CNAME/alias in

the MX record.  I beg to differ.  There is no such standard =

nor
requirement prohibiting the use of CNAME/alias in an MX =

record.<o:p></o:p>

<o:p></o:p>

Message thrown at startup:<o:p></o:p>

"named[3307]:
zone MyDomain.com/IN: MyDomain.com/MX =
'MX1.MyDomain.com' is a CNAME
(illegal)"<o:p></o:p>

<o:p></o:p>

Additionally in Chapter 6 – BIND =
Configuration
Reference, Zone File, Discussion of MX Records states the MX records
“must have an associated address record (A or AAAA) – CNAME =
is not
sufficient.”<o:p></o:p>

<o:p></o:p>

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.<o:p></o:p>

<o:p></o:p>

ISC’s message that a CNAME/alias in an MX =
record is
illegal is incorrect 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 requirement, and
certainly not illegal.<o:p></o:p>

<o:p></o:p>

Al Stu<o:p></o:p>

<o:p> </o:p>

<div>

<o:p></=
o:p>

</div>

</body>

</html>

------=_NextPart_000_0005_01C97E89.CC6D6330--

--===============0947294185913229104==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============0947294185913229104==--

Danny Thomas

unread,

Jan 25, 2009, 2:14:07 AM1/25/09

to

Al Stu wrote:
>BIND 9.6 =91named=92 throws the following message during startup claiming

>that it is illegal to use a CNAME/alias in the MX record.
>I beg to differ. There is no such standard nor requirement prohibiting
>the use of CNAME/alias in an MX record.
>

>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.
>

>ISC=92s message that a CNAME/alias in an MX record is illegal is incorrect

>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 requirement, and
>certainly not illegal.

checking RFCs published within the last 12 years might have been useful

RFC2181: Clarifications to the DNS Specification
this was published as Standards Track
it's true that many RFCs were not advanced but the DNS Extensions
Working Group is making an effort
http://www.ietf.org/html.charters/dnsext-charter.html
Jun 2007 Start of process of reviewing the following RFCs and to
move them to Draft Standard status
that not only includes rfc2181, but ones defining EDNS0, notify,
negative caching, dynamic updates, SRV records etc

10.3. MX and NS records

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. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.

Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.

Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. 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. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.

Danny

SM

unread,

Jan 25, 2009, 3:23:29 AM1/25/09

to

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 obsoleted by RFC 2821; the latter is obsoleted by RFC
5321. Quoting Section 5 of that RFC:

"When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name. That domain name, when queried, MUST return
at least one address record (e.g., A or AAAA RR) that gives the IP
address of the SMTP server to which the message should be directed.
Any other response, specifically including a value that will return a
CNAME record when queried, lies outside the scope of this Standard.
The prohibition on labels in the data that resolve to CNAMEs is
discussed in more detail in RFC 2181, Section 10.3."

>ISC's message that a CNAME/alias in an MX record is illegal is

>incorrect 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 requirement, and certainly not illegal.

Pointing to a CNAME on the right-hand side of an MX record is
incorrect and may affect mail delivery. This is not about perceived
perception of a requirement (see the MUST return at least one address
record in the quoted text).

Regards,
-sm

Al Stu

unread,

Jan 25, 2009, 3:30:47 AM1/25/09

to

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 resolved
to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME
RRs whose targets can be resolved, in turn, to MX or A RRs."

5. Address Resolution and Mail Handling
"The lookup first attempts to locate an MX record associated with the name.
If a CNAME record is found instead, the resulting name is processed as if it
were the initial name."

This is also backed up by the older 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."

So it is clear there should be no problem with using CNAME MX RR for mail
systems that conform to these RFC's, and therefore no need for enforcing the
use of only A RR, or even outputting an error/warning.

Al Stu

unread,

Jan 25, 2009, 3:44:36 AM1/25/09

to

"When a domain name associated with an MX RR is looked up and the associated
data field obtained, the data field of that response MUST contain a domain
name. That domain name, when queried, MUST return at least one address
record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to
which the message should be directed."

Correct. And when a that domain name is a CNAME pointing to an A RR the
query returns not only the alias but also the real name and the IP address
from the A RR. Thus meeting the requirements to "return at least one
address record (e.t., A or AAAA RR)". But yet ISC seems to find it
necessary to throw a message that it is "illegal", when it clearly is not.

----- Original Message -----
From: "SM" <s...@resistor.net>
To: <bind-...@lists.isc.org>
Sent: Sunday, January 25, 2009 12:23 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

SM

unread,

Jan 25, 2009, 9:46:02 AM1/25/09

to

At 00:44 25-01-2009, Al Stu wrote:
>"When a domain name associated with an MX RR is looked up and the
>associated data field obtained, the data field of that response MUST
>contain a domain name. That domain name, when queried, MUST
>return at least one address record (e.g., A or AAAA RR) that gives
>the IP address of the SMTP server to which the message should be directed."
>
>Correct. And when a that domain name is a CNAME pointing to an A RR
>the query returns not only the alias but also the real name and the
>IP address from the A RR. Thus meeting the requirements to "return
>at least one address record (e.t., A or AAAA RR)". But yet ISC
>seems to find it necessary to throw a message that it is "illegal",
>when it clearly is not.

That's a liberal interpretation of the specifications and it's the
opposite of the intent of the quoted paragraph. Implementors are
expected to query for an address record only. Any other behavior
such as the one described in your second paragraph is
undefined. Further reading of that section elaborates on what to do
if a CNAME is returned and there is a reference to RFC 2181 for a
discussion of the prohibition of CNAMEs on the right-end side. RFC
974 specifies the algorithm to build the list of RRs and discusses
about possible issues. It's the same algorithm in RFC 2821 and RFC 5321.

The confusion about CNAMEs in MX records stems from the
interpretation of the text about how CNAMEs on the left-hand side are
handled and that was clarified in the latest revision of the specifications.

Matthew Pounsett

unread,

Jan 25, 2009, 10:37:04 AM1/25/09

to

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8933262672065090949==
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha1; boundary="Apple-Mail-51--959929731"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-51--959929731
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 25-Jan-2009, at 03:44 , Al Stu wrote:

> "When a domain name associated with an MX RR is looked up and the
> associated data field obtained, the data field of that response MUST
> contain a domain name. That domain name, when queried, MUST
> return at least one address record (e.g., A or AAAA RR) that gives
> the IP address of the SMTP server to which the message should be
> directed."
>
> Correct. And when a that domain name is a CNAME pointing to an A RR
> the query returns not only the alias but also the real name and the
> IP address from the A RR. Thus meeting the requirements to "return
> at least one address record (e.t., A or AAAA RR)". But yet ISC
> seems to find it necessary to throw a message that it is "illegal",
> when it clearly is not.

You've added an additional step in your second paragraph that is
prohibited by the section you quoted in the first. The section from
the RFC describes a situation where A is queried for and an MX record
pointing to B is returned. When B is queried for, an address record
MUST be the answer. The situation you have described is that A is
queried for resulting in an MX record pointing to B. When B is
queried for, a CNAME pointing to C is returned, and that when C is
queried an address record is returned. Do you see the difference?

The RFCs are quite clear that CNAMEs are not permitted in the RDATA
for an MX.

--Apple-Mail-51--959929731
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkl8hyAACgkQmFeRJ0tjIxHAaACfcesscXfTDmpBqA7b/tyWT2lo
krkAoIrEjp9yaatipbyWhb9qeWQJMp38
=ijph
-----END PGP SIGNATURE-----

--Apple-Mail-51--959929731--

--===============8933262672065090949==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============8933262672065090949==--

Chris Thompson

unread,

Jan 25, 2009, 12:28:12 PM1/25/09

to

On Jan 25 2009, Al Stu wrote:

>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 resolved
>to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME
>RRs whose targets can be resolved, in turn, to MX or A RRs."
>
>5. Address Resolution and Mail Handling
>"The lookup first attempts to locate an MX record associated with the name.
>If a CNAME record is found instead, the resulting name is processed as if it
>were the initial name."

These clearly refer to the case "CNAME record points to MX record", which
no-one has any problems with, or at least BIND certainly doesn't. The
"illegal" case is "MX record points to CNAME record", and RFC 2821 gives
no sanction for that. Section 5.1 in RFC 5321 makes it even more explicit.

You can, of course, turn off this particular check in BIND by specifying
"check-mx-cname ignore;" in the options or zone statements.

--
Chris Thompson
Email: ce...@cam.ac.uk

Al Stu

unread,

Jan 25, 2009, 12:41:40 PM1/25/09

to

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 som...@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 domain name associated with an MX RR is looked up and the associated
data field obtained, the data field of that response MUST contain a domain
name."

Now an A lookup is performed for that domain name of mx.xyz.com. and
returned are the name srv1.xyz.com with it's address of 1.2.3.4, and the
alias name of mx.xyz.com is also included in the result. This is the second
sentence:

"That domain name, when queried, MUST return at least one address record
(e.g., A or AAAA RR) that gives the IP address of the SMTP server to which
the message should be directed."

@ 1800 IN A 1.2.3.4
srv1 1800 IN A 1.2.3.4
mx 1800 IN CNAME blah.xyz.com.
@ 1800 IN MX 1 mx.xyz.com.

Requirements met.

Matthew Pounsett

unread,

Jan 25, 2009, 12:49:04 PM1/25/09

to

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--===============7245477338038820741==
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha1; boundary="Apple-Mail-1--952009263"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--Apple-Mail-1--952009263

Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 25-Jan-2009, at 12:41 , Al Stu wrote:

> "That domain name, when queried, MUST return at least one address
> record (e.g., A or AAAA RR) that gives the IP address of the SMTP
> server to which the message should be directed."
>
> @ 1800 IN A 1.2.3.4
> srv1 1800 IN A 1.2.3.4
> mx 1800 IN CNAME blah.xyz.com.
> @ 1800 IN MX 1 mx.xyz.com.
>
> Requirements met.

In the example above, when I query for "IN A mx.xyz.com?" I do not get
an address record back (A, AAAA)..instead I get a CNAME record.
Requirements NOT met.

I don't see the connection to srv1. Did you mean for "mx 1800 IN
CNAME blah.xyz.com." to be "mx 1800 IN CNAME srv1.xyz.com."? That
still doesn't meet requirements, because the record returned there as
the ANSWER is a CNAME, not an A or AAAA record. I think you might be
confusing the ADDITIONAL section of a DNS message with the ANSWER
section. They are not the same thing.

--Apple-Mail-1--952009263

content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkl8phAACgkQmFeRJ0tjIxEvmwCeIND82u5Q/SAKcyPbCMeQ2PCp
uksAn0T6qiTt8BqTgBEpuno8Cye4pQte
=U78p
-----END PGP SIGNATURE-----

--Apple-Mail-1--952009263--

--===============7245477338038820741==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============7245477338038820741==--

Al Stu

unread,

Jan 25, 2009, 1:15:46 PM1/25/09

to

Yes, blah was supposed to be srv1.

I do receive both the CNAME and A records for the A mx.xyz.com query. See
attached capture file.

In the capture file three global search and replacements were performed to
match the previous example.

1) domain name was replaced with xyz
2) server name was replaced with srv1
3) server ip address was replaced with 1.2.3.4

Requirements are met.

----- Original Message -----
From: "Matthew Pounsett" <ma...@conundrum.com>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@lists.isc.org>
Sent: Sunday, January 25, 2009 9:49 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

Al Stu

unread,

Jan 25, 2009, 1:30:34 PM1/25/09

to

This is a multi-part message in MIME format.

------=_NextPart_000_0120_01C97ED7.F4735F80
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
Content-Transfer-Encoding: 7bit

Attachment (hopefully)

------=_NextPart_000_0120_01C97ED7.F4735F80
Content-Type: text/plain; format=flowed; name="MX.XYZ.COM.txt";
reply-type=response
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="MX.XYZ.COM.txt"

No. Time Source Destination Protocol =
Info
1 0.000000 192.168.1.16 192.168.1.1 DNS =
Standard query MX xyz.com

Frame 1 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: Usi_de:94:de (00:10:c6:de:94:de), Dst: =
Actionte_51:fa:72 (00:18:01:51:fa:72)
Internet Protocol, Src: 192.168.1.16 (192.168.1.16), Dst: 192.168.1.1 =
(192.168.1.1)
User Datagram Protocol, Src Port: 4482 (4482), Dst Port: domain (53)
Domain Name System (query)
[Response In: 2]
Transaction ID: 0x0002
Flags: 0x0100 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries

No. Time Source Destination Protocol =
Info
2 0.063279 192.168.1.1 192.168.1.16 DNS =
Standard query response MX 1 MX2.xyz.com MX 1 MX1.xyz.com

Frame 2 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: Actionte_51:fa:72 (00:18:01:51:fa:72), Dst: =
Usi_de:94:de (00:10:c6:de:94:de)
Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.16 =
(192.168.1.16)
User Datagram Protocol, Src Port: domain (53), Dst Port: 4482 (4482)
Domain Name System (response)
[Request In: 1]
[Time: 0.063279000 seconds]
Transaction ID: 0x0002
Flags: 0x8180 (Standard query response, No error)
Questions: 1
Answer RRs: 2
Authority RRs: 0
Additional RRs: 0
Queries
Answers
xyz.com: type MX, class IN, preference 1, mx MX2.xyz.com
Name: xyz.com
Type: MX (Mail exchange)
Class: IN (0x0001)
Time to live: 30 minutes
Data length: 8
Preference: 1
Mail exchange: MX2.xyz.com
xyz.com: type MX, class IN, preference 1, mx MX1.xyz.com
Name: xyz.com
Type: MX (Mail exchange)
Class: IN (0x0001)
Time to live: 30 minutes
Data length: 8
Preference: 1
Mail exchange: MX1.xyz.com

No. Time Source Destination Protocol =
Info
3 15.625151 192.168.1.16 192.168.1.1 DNS =
Standard query A mx1.xyz.com

Frame 3 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: Usi_de:94:de (00:10:c6:de:94:de), Dst: =
Actionte_51:fa:72 (00:18:01:51:fa:72)
Internet Protocol, Src: 192.168.1.16 (192.168.1.16), Dst: 192.168.1.1 =
(192.168.1.1)
User Datagram Protocol, Src Port: 4483 (4483), Dst Port: domain (53)
Domain Name System (query)
[Response In: 4]
Transaction ID: 0x0003
Flags: 0x0100 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries

No. Time Source Destination Protocol =
Info
4 15.718055 192.168.1.1 192.168.1.16 DNS =
Standard query response CNAME srv1.xyz.com A 1.2.3.4

Frame 4 (120 bytes on wire, 120 bytes captured)
Ethernet II, Src: Actionte_51:fa:72 (00:18:01:51:fa:72), Dst: =
Usi_de:94:de (00:10:c6:de:94:de)
Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.16 =
(192.168.1.16)
User Datagram Protocol, Src Port: domain (53), Dst Port: 4483 (4483)
Domain Name System (response)
[Request In: 3]
[Time: 0.092904000 seconds]
Transaction ID: 0x0003
Flags: 0x8180 (Standard query response, No error)
Questions: 1
Answer RRs: 2
Authority RRs: 0
Additional RRs: 0
Queries
Answers
mx1.xyz.com: type CNAME, class IN, cname srv1.xyz.com
Name: mx1.xyz.com
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 30 minutes
Data length: 14
Primary name: srv1.xyz.com
srv1.xyz.com: type A, class IN, addr 1.2.3.4
Name: srv1.xyz.com
Type: A (Host address)
Class: IN (0x0001)
Time to live: 30 minutes
Data length: 4
Addr: 1.2.3.4

------=_NextPart_000_0120_01C97ED7.F4735F80

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

------=_NextPart_000_0120_01C97ED7.F4735F80--

Matthew Pounsett

unread,

Jan 25, 2009, 1:30:21 PM1/25/09

to

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--===============0160815675472344252==
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha1; boundary="Apple-Mail-2--949532629"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--Apple-Mail-2--949532629

Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 25-Jan-2009, at 13:15 , Al Stu wrote:

> Yes, blah was supposed to be srv1.
>
> I do receive both the CNAME and A records for the A mx.xyz.com
> query. See attached capture file.
>
> In the capture file three global search and replacements were
> performed to match the previous example.
>
> 1) domain name was replaced with xyz
> 2) server name was replaced with srv1
> 3) server ip address was replaced with 1.2.3.4
>
> Requirements are met.

Al, I'm sorry, but you're wrong. If you look closely at what you just
typed, you'll see that's three steps.. not the two steps required by
the MUST in the RFC.

Your attachment didn't make it through the list manager. I suggest
you paste in some dig output instead. If you do, you'll notice that
the IP address you're receiving is in the ADDITIONAL section of the
DNS message, which does not qualify as an ANSWER.

I'm going to stop contributing to this thread now.. if you insist on
ignoring the pointers people have given you to the text in the RFCs,
and insist on reading your own interpretation into it, we cannot stop
you.

--Apple-Mail-2--949532629

content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkl8r70ACgkQmFeRJ0tjIxEgcwCdF+T4jkR7Bez5tMapDhlimi0T
rIAAnRjXx1xWN4kozfSacKAb1+YFrtPC
=Do9X
-----END PGP SIGNATURE-----

--Apple-Mail-2--949532629--

--===============0160815675472344252==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============0160815675472344252==--

Al Stu

unread,

Jan 25, 2009, 1:47:11 PM1/25/09

to

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" <ma...@conundrum.com>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@lists.isc.org>
Sent: Sunday, January 25, 2009 10:30 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

Alan Clegg

unread,

Jan 25, 2009, 3:02:57 PM1/25/09

to

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--===============0337180230897398038==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigE6846F99483989DD557D00E4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--------------enigE6846F99483989DD557D00E4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Al Stu wrote:

> ISC=E2=80=99s message that a CNAME/alias in an MX record is illegal is =
incorrect
> 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 remove=
d

> so as not to further the fallacy of this perceived perception of a

> standard/requirement, as it is neither a standard nor a requirement, an=
d
> certainly not illegal.

If you feel this is a bug in BIND, please send an e-mail to
bind...@isc.org for consideration.

Thanks,
AlanC

--------------enigE6846F99483989DD557D00E4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl8xXMACgkQcKpYUrUDCYc2xQCfedPm4YKpDvr2KZB01OinmfBb
K0MAn1KBYeU1yI7sHp3rECyNowSM+sFk
=SCdD
-----END PGP SIGNATURE-----

--------------enigE6846F99483989DD557D00E4--

--===============0337180230897398038==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============0337180230897398038==--

Chris Hills

unread,

Jan 25, 2009, 5:43:38 PM1/25/09

to

Perhaps one day MX records can be deprecated entirely in favor of SRV.
Jabber got it right, and it would solve the e-mail server autodiscovery
problem for clients in a generic non-proprietary manner.

For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients.

Chris Thompson

unread,

Jan 25, 2009, 5:52:40 PM1/25/09

to

On Jan 25 2009, Chris Hills wrote:

>Perhaps one day MX records can be deprecated entirely in favor of SRV.
>Jabber got it right, and it would solve the e-mail server autodiscovery
>problem for clients in a generic non-proprietary manner.
>
>For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients.

But would this satisfy the OP? The RDATA of an SRV record isn't meant to
reference a CNAME any more than that of an MX record is.

--
Chris Thompson
Email: ce...@cam.ac.uk

Mark Andrews

unread,

Jan 25, 2009, 6:24:41 PM1/25/09

to

MX records are supposed to be pointed to the name the mail
exhanger knows itself as. This will correspond to a A
record. If I could work out a way to determine which A
records don't correspond to the name by which the mail
exchanger knows itself as I'd also have named issue a warning
for such A records. Unfortunately there isn't a way to
make such a determination.

When a CNAME is used you configuration errors reported from
MTA's when they try to send email to themselves. This still
happens today.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

Barry Margolin

unread,

Jan 25, 2009, 11:06:24 PM1/25/09

to

In article <gli8nu$ja7$1...@sf1.isc.org>,
Matthew Pounsett <ma...@conundrum.com> wrote:

> In the example above, when I query for "IN A mx.xyz.com?" I do not get
> an address record back (A, AAAA)..instead I get a CNAME record.
> Requirements NOT met.

Then there's something wrong with your resolver, since they're supposed
to follow CNAME records automatically, and return the requested record
type from the canonical name.

There isn't even an option in the DNS spec to tell the resolver not to
follow CNAMEs. The only way to avoid it is to query for the CNAME
explicitly.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Matthew Pounsett

unread,

Jan 25, 2009, 11:43:51 PM1/25/09

to

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--===============5749736707713963979==
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha1; boundary="Apple-Mail-6--912722739"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--Apple-Mail-6--912722739

Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 25-Jan-2009, at 23:06 , Barry Margolin wrote:

> In article <gli8nu$ja7$1...@sf1.isc.org>,
> Matthew Pounsett <ma...@conundrum.com> wrote:
>

>> In the example above, when I query for "IN A mx.xyz.com?" I do not
>> get
>> an address record back (A, AAAA)..instead I get a CNAME record.
>> Requirements NOT met.
>

> Then there's something wrong with your resolver, since they're
> supposed
> to follow CNAME records automatically, and return the requested record
> type from the canonical name.

You're right, of course. I was over simplifying my point, which was
that the answer to the question asked is not an address record. I
should probably know better than to do that. :)

--Apple-Mail-6--912722739

content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkl9P4cACgkQmFeRJ0tjIxHCpwCgjTeWp7RaR1gYO6x6kIdkdcfL
sT4AnjR5eaxfcL6tHZWT3mG8pdUk2tXt
=l6eH
-----END PGP SIGNATURE-----

--Apple-Mail-6--912722739--

--===============5749736707713963979==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============5749736707713963979==--

bsfi...@anl.gov

unread,

Jan 26, 2009, 10:19:54 AM1/26/09

to

I have not copied the entire thread.

>You've added an additional step in your second paragraph that is
>prohibited by the section you quoted in the first. The section from
>the RFC describes a situation where A is queried for and an MX record
>pointing to B is returned. When B is queried for, an address record
>MUST be the answer. The situation you have described is that A is
>queried for resulting in an MX record pointing to B. When B is
>queried for, a CNAME pointing to C is returned, and that when C is
>queried an address record is returned. Do you see the difference?
>
>The RFCs are quite clear that CNAMEs are not permitted in the RDATA
>for an MX.

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.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: BSFi...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994

Matus UHLAR - fantomas

unread,

Jan 26, 2009, 11:18:04 AM1/26/09

to

On 26.01.09 09:19, bsfi...@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".

Al Stu

unread,

Jan 26, 2009, 12:50:45 PM1/26/09

to

"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.

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.

----- Original Message -----
From: "Matus UHLAR - fantomas" <uh...@fantomas.sk>
To: <bind-...@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"

Danny Thomas

unread,

Jan 26, 2009, 4:43:24 PM1/26/09

to

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.

"Be conservative in what you send" means that fewer problems are
likely from reasonable compliance with standards and not trying
every complicated or edge case that might be read into standards.
Section 5.1 of RFC5321:

Any other response, specifically including a value that will
return a CNAME record when queried, lies outside the scope of
this Standard. The prohibition on labels in the data that
resolve to CNAMEs is discussed in more detail in RFC 2181,

Section 10.3 [38].

So if you choose to have MXs with an <exchange> field being a
CNAME, don't complain if that results in some problems
for email delivery.

> So there is no need to prevent this nor to label it as "illegal".

"not compliant with RFC5321/5.1" would have been more explicit.
Maybe the ARM could list compliance messages along with references
to relevant standards and/or examples ?

Possible courses of action
* disable the check-mx-cname in your config
* discussions about correct behaviour and standards compliance
might be better taken up on the namedroppers list
* try to prevent RFC5321 from advancing to Standard status
while CNAMEs are specifically excluded by the document

*plonk*

Noel Butler

unread,

Jan 26, 2009, 5:23:13 PM1/26/09

to

--===============4925525664966038391==
Content-Type: multipart/alternative; boundary="=-2tljcVS5/krBADFDcDJK"

--=-2tljcVS5/krBADFDcDJK
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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 type his rants and raves and have his
little dummy spit, he could have gone and changed the MX to be a real
name, and not bored the rest of us because he cant read modern RFC's.

> Possible courses of action
> * disable the check-mx-cname in your config

As was pointed out to him days ago, but yet he persists in trolling, I
like most I suspect stopped reading his rants days ago.

--=-2tljcVS5/krBADFDcDJK
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
On Tue, 2009-01-27 at 07:43, Danny Thomas wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>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.

</PRE>
</BLOCKQUOTE>
 
In all the time its taken him to type his rants and raves and have his little dummy spit, he could have gone and changed the MX to be a real name, and not bored the rest of us because he cant read modern RFC's. 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>Possible courses of action
* disable the check-mx-cname in your config</PRE>
</BLOCKQUOTE>
 
As was pointed out to him days ago, but yet he persists in trolling, I like most I suspect stopped reading his rants days ago. 
 
</BODY>
</HTML>

--=-2tljcVS5/krBADFDcDJK--

--===============4925525664966038391==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============4925525664966038391==--

Al Stu

unread,

Jan 26, 2009, 5:53:10 PM1/26/09

to

This is a multi-part message in MIME format.

--===============5896842886402803169==
Content-type: multipart/alternative;
boundary="----=_NextPart_000_00A7_01C97FC5.CEACB640"

This is a multi-part message in MIME format.

------=_NextPart_000_00A7_01C97FC5.CEACB640
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

"In all the time its taken him to type his rants and raves and have his =
little dummy spit, he could have gone and changed the MX to be a real =
name, ..." - Noel Butler
Wow, such narrow mindedness.

"I like most I suspect stopped reading his rants days ago." - Noel =
Butler
And yet here you are continuing to proliferate the thread. Thank you!

----- Original Message -----=20
From: Noel Butler=20
To: Danny Thomas=20
Cc: bind-...@lists.isc.org=20
Sent: Monday, January 26, 2009 2:23 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT =
"Illegal"

On Tue, 2009-01-27 at 07:43, Danny Thomas wrote:=20

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 type his rants and raves and have his =
little dummy spit, he could have gone and changed the MX to be a real =

name, and not bored the rest of us because he cant read modern RFC's.

Possible courses of action
* disable the check-mx-cname in your config

As was pointed out to him days ago, but yet he persists in trolling, I =

like most I suspect stopped reading his rants days ago.

-------------------------------------------------------------------------=
-----

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

------=_NextPart_000_00A7_01C97FC5.CEACB640
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; CHARSET=3DUTF-8">
<META content=3D"MSHTML 6.00.6000.16788" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV>
<DIV>"In all the=20
time its taken him to type his rants and raves and have his little dummy =
spit,=20
he could have gone and changed the MX to be a real name, ..." - Noel=20
Butler Wow, such narrow =
mindedness.</DIV>
<DIV> </DIV>
<DIV>
<DIV>"I like=20
most I suspect stopped reading his rants days ago." - Noel=20
Butler</DIV>
<DIV>And yet here you are continuing =
to=20
proliferate the thread.  Thank =
you!</DIV>
<DIV> </DIV>
<DIV> </DIV></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black">From:=20
<A title=3Dnoel...@ausics.net =
href=3D"mailto:noel....@ausics.net">Noel=20
Butler</A> </DIV>
<DIV style=3D"FONT: 10pt arial">To: <A =
title=3Dd.t...@its.uq.edu.au=20
href=3D"mailto:d.th...@its.uq.edu.au">Danny Thomas</A> </DIV>
<DIV style=3D"FONT: 10pt arial">Cc: <A =
title=3Dbind...@lists.isc.org=20
href=3D"mailto:bind-...@lists.isc.org">bind-...@lists.isc.org</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial">Sent: Monday, January 26, 2009 =
2:23=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial">Subject: Re: BIND 9.6 Flaw - =
CNAME vs. A=20
Record in MX Records are NOT "Illegal"</DIV>
<DIV> </DIV>On Tue, 2009-01-27 =
at 07:43,=20
Danny Thomas wrote:=20

<BLOCKQUOTE TYPE=3D"CITE"><PRE>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.

</PRE></BLOCKQUOTE> In all the time its taken him to type =
his=20
rants and raves and have his little dummy spit, he could have gone and =
changed=20
the MX to be a real name, and not bored the rest of us because he cant =
read=20

modern RFC's.

<BLOCKQUOTE TYPE=3D"CITE"><PRE>Possible =
courses of action
* disable the check-mx-cname in your =
config</PRE></BLOCKQUOTE> As=20
was pointed out to him days ago, but yet he persists in trolling, I =
like most=20

I suspect stopped reading his rants days ago.

<HR>

_______________________________________________ bind-users =
mailing=20
=
list bind-...@lists.isc.org https://lists.isc.org/mailman/listinf=
o/bind-users</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00A7_01C97FC5.CEACB640--

--===============5896842886402803169==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============5896842886402803169==--

Mark Andrews

unread,

Jan 26, 2009, 5:55:08 PM1/26/09

to

In message <2D378CB064BA4D06880AED8ED81F3027@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-...@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

> > _______________________________________________
> > bind-users mailing list
> > bind-...@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> bind-users mailing list
> bind-...@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_A...@isc.org

Mark Andrews

unread,

Jan 26, 2009, 9:17:56 PM1/26/09

to

In message <0AA37CE829BA458B9BA2D199A6D96ED2@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_A...@isc.org>
> To: "Al Stu" <Al_...@Verizon.net>

Scott Haneda

unread,

Jan 26, 2009, 9:24:06 PM1/26/09

to

On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote:

> 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.

100% right. I refuse MX's that are cnamed, and I get emails from
customers asking what is up. What is strange, and I can not figure it
out, is that the admins of the DNS/email server always tell me this is
the first time they have heard of it.

Despite me pointing them to RFC on the matter, since it has worked in
the past, they think it is my MTA that is wrong. I hate to budge on
it, as this is a simple thing to understand and fix, but it seems many
other email servers out there will run up and down a DNS server to
find any address they can.

In the end, they almost always refuse to change their DNS, and I and
up making a static route for them. They change the record later, and
then it breaks.

I have never got why this is such a hard thing for email admins to get
right, but it certainly causes me headaches. I personally wish
CNAME's would just go away, keep them around, but just stop talking
about them, then new to DNS users would not use them.
--
Scott

Al Stu

unread,

Jan 26, 2009, 10:54:00 PM1/26/09

to

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" <talk...@newgeo.com>
To: "Mark Andrews" <Mark_A...@isc.org>
Cc: "Al Stu" <Al_...@Verizon.net>; <bind-...@lists.isc.org>
Sent: Monday, January 26, 2009 6:24 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

Scott Haneda

unread,

Jan 26, 2009, 11:09:15 PM1/26/09

to

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.

Al Stu

unread,

Jan 26, 2009, 11:22:49 PM1/26/09

to

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."

----- Original Message -----
From: "Scott Haneda" <talk...@newgeo.com>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@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"

Mark Andrews

unread,

Jan 26, 2009, 11:41:02 PM1/26/09

to

In message <3C802402A28C4B2390B088242A91FB9C@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" <talk...@newgeo.com>
> To: "Al Stu" <Al_...@Verizon.net>
> Cc: <bind-...@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-...@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_A...@isc.org

Al Stu

unread,

Jan 27, 2009, 12:26:22 AM1/27/09

to

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.

"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.

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 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.

Mark Andrews

unread,

Jan 27, 2009, 1:03:11 AM1/27/09

to

In message <B3BA5E37553642E28149093CDEE78476@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.

Barry Margolin

unread,

Jan 27, 2009, 1:03:46 AM1/27/09

to

In article <gllr91$2vqt$1...@sf1.isc.org>,
Scott Haneda <talk...@newgeo.com> wrote:

> 100% right. I refuse MX's that are cnamed, and I get emails from
> customers asking what is up. What is strange, and I can not figure it
> out, is that the admins of the DNS/email server always tell me this is
> the first time they have heard of it.

So you're not following the "be liberal in what you accept" half of the
Interoperability Principle, which is intended specifically to avoid
problems due to such confusion.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin

unread,

Jan 27, 2009, 1:11:53 AM1/27/09

to

In article <gllr91$2vqt$1...@sf1.isc.org>,
Scott Haneda <talk...@newgeo.com> wrote:

> I have never got why this is such a hard thing for email admins to get
> right, but it certainly causes me headaches. I personally wish
> CNAME's would just go away, keep them around, but just stop talking
> about them, then new to DNS users would not use them.

Suppose you're providing an MX service, but you actually out-source the
operation to a third party. You want to give your customers an MX
record that points to a name in your domain, so they don't need to know
about the third party (and so you have the flexibility to change your
out-sourcing without requiring all customers to update their MX record).

But the third party also needs the flexibility to change the IP of the
server, load balancing, disaster recovery, changing ISPs, etc. So they
don't want you to hard-code their IPs into your domain.

CNAMEs are the simplest solution to implementing all this.

customer.com. IN MX 10 mx.yourdomain.com.
mx.yourdomain.com. IN CNAME mx.outsourcer.com.
mx.outsourcer.com. IN A ...

If the customer changes MX services, they change their MX record. If
you change outsourcing companies, you change your CNAME record. And if
the outsourcing company re-IPs their server, they change the A record.
Everyone can perform their job without having to make any of the
downstream customers adjust their records.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin

unread,

Jan 27, 2009, 1:16:26 AM1/27/09

to

In article <glm61r$5l5$1...@sf1.isc.org>, "Al Stu" <Al_...@Verizon.net>
wrote:

> 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, we're talking about the response to the A query for the name that
the MX points to. The section below is talking about the response to
the original MX query. E.g. when sending mail to f...@mail.company.com,
mail.company.com is allowed to be a CNAME. So you can have:

mail.company.com. CNAME company.com.
company.com. MX 10 mx.company.com.

but you still aren't supposed to have:

mx.company.com. CNAME mxserver.company.com.

--

Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Scott Haneda

unread,

Jan 27, 2009, 1:26:03 AM1/27/09

to

On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote:

> In article <gllr91$2vqt$1...@sf1.isc.org>,
> Scott Haneda <talk...@newgeo.com> wrote:
>

>> 100% right. I refuse MX's that are cnamed, and I get emails from
>> customers asking what is up. What is strange, and I can not figure
>> it
>> out, is that the admins of the DNS/email server always tell me this
>> is
>> the first time they have heard of it.
>

> So you're not following the "be liberal in what you accept" half of
> the
> Interoperability Principle, which is intended specifically to avoid
> problems due to such confusion.

Because that worked so well for HTML :)
I was thinking about that quote just the other day. To be honest, I
think it applies well to social issues, but not technical or
engineering/programming ones. The second you accept liberally, that
tells the submitter that it is ok.

I am hard pressed to think of one case in which liberally accepting
data is a good thing. It is that very expression that defines why we
have sometext

Just consider the ramifications of parsing that one simple string,
which is now non trivial to parse. What is C worked this way?

Just some thoughts I was having the other day.

Scott Haneda

unread,

Jan 27, 2009, 1:30:10 AM1/27/09

to

On Jan 26, 2009, at 10:11 PM, Barry Margolin wrote:

> In article <gllr91$2vqt$1...@sf1.isc.org>,
> Scott Haneda <talk...@newgeo.com> wrote:
>

>> I have never got why this is such a hard thing for email admins to
>> get
>> right, but it certainly causes me headaches. I personally wish
>> CNAME's would just go away, keep them around, but just stop talking
>> about them, then new to DNS users would not use them.
>

> Suppose you're providing an MX service, but you actually out-source
> the
> operation to a third party. You want to give your customers an MX
> record that points to a name in your domain, so they don't need to
> know
> about the third party (and so you have the flexibility to change your
> out-sourcing without requiring all customers to update their MX
> record).
>
> But the third party also needs the flexibility to change the IP of the
> server, load balancing, disaster recovery, changing ISPs, etc. So
> they
> don't want you to hard-code their IPs into your domain.
>
> CNAMEs are the simplest solution to implementing all this.
>
> customer.com. IN MX 10 mx.yourdomain.com.
> mx.yourdomain.com. IN CNAME mx.outsourcer.com.
> mx.outsourcer.com. IN A ...
>
> If the customer changes MX services, they change their MX record. If
> you change outsourcing companies, you change your CNAME record. And
> if
> the outsourcing company re-IPs their server, they change the A record.
> Everyone can perform their job without having to make any of the
> downstream customers adjust their records.

Totally valid points, I agree with them all. And it is these points
that I was talking about when I suggested CNAME's go away. Not really
go away, but the above case is clearly one in which the admin knows
that they are doing.

What my trouble is, is with the mail admins who clearly do not, and
then argue about solving it. I better example is servers that do not
support greylisting, and bounce on 450 code. This is pretty simple,
and obvious as to why you need to try in a transient error like that.

Anyway, not saying I disagree with you, I do not, but I was just
venting a little.

Al Stu

unread,

Jan 27, 2009, 1:34:00 AM1/27/09

to

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_A...@isc.org>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@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"

>

> 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_A...@isc.org>
>> To: "Al Stu" <Al_...@Verizon.net>
>> Cc: <bind-...@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"
>>
>>
>> >

>> > Mark
>> >
>> >> ----- Original Message -----

>> >> From: "Matus UHLAR - fantomas" <uh...@fantomas.sk>

>> >> To: <bind-...@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"
>> >>
>> >>

>> >> > _______________________________________________
>> >> > bind-users mailing list
>> >> > bind-...@lists.isc.org
>> >> > https://lists.isc.org/mailman/listinfo/bind-users
>> >>
>> >> _______________________________________________
>> >> bind-users mailing list
>> >> bind-...@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_A...@isc.org

>> > _______________________________________________
>> > bind-users mailing list
>> > bind-...@lists.isc.org
>> > https://lists.isc.org/mailman/listinfo/bind-users
>>
>> _______________________________________________
>> bind-users mailing list
>> bind-...@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_A...@isc.org

Mark Andrews

unread,

Jan 27, 2009, 1:35:42 AM1/27/09

to

In message <BC7C01A4-1803-4906...@newgeo.com>, Scott Haneda writ
es:

> On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote:
>
> > In article <gllr91$2vqt$1...@sf1.isc.org>,
> > Scott Haneda <talk...@newgeo.com> wrote:
> >

> >> 100% right. I refuse MX's that are cnamed, and I get emails from
> >> customers asking what is up. What is strange, and I can not figure
> >> it
> >> out, is that the admins of the DNS/email server always tell me this
> >> is
> >> the first time they have heard of it.
> >
> > So you're not following the "be liberal in what you accept" half of
> > the
> > Interoperability Principle, which is intended specifically to avoid
> > problems due to such confusion.
>
>
> Because that worked so well for HTML :)
> I was thinking about that quote just the other day. To be honest, I
> think it applies well to social issues, but not technical or
> engineering/programming ones. The second you accept liberally, that
> tells the submitter that it is ok.
>
> I am hard pressed to think of one case in which liberally accepting
> data is a good thing. It is that very expression that defines why we
> have sometext
>
> Just consider the ramifications of parsing that one simple string,
> which is now non trivial to parse. What is C worked this way?
>
> Just some thoughts I was having the other day.
> --
> Scott
>

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Liberal in what you accepts means don't die on arbitary
input. You should still reject rubbish.

David Ford

unread,

Jan 27, 2009, 2:27:09 AM1/27/09

to

Naive users messing up using CNAMEs is really neither here nor there
because they are just as likely to mess up any other type of DNS
record. The fact that CNAME MX records has not destroyed the internet
belittles the staunch firestorm that CNAME MX records will destroy the
internet. I've never had a problem dealing with it on my mail servers.
The only time I notice it is by chance when I'm idly browsing through
DNS records of whomever for whatever reason. 20 years ago we didn't
have the spam issues we do now, nor the technological changes. One
machine, one IP, one hostname, one PTR. Now we have mass distributed
virtual hosting for websites and numerous other services. We used to
have no impetus to use much security involving DNS, nor was TCP used
much. UDP was ubiquitous for port 53. Virtual SSL is all the rage now
and load balanced mail servers listen to multiple ports and protocols as
a default instead of just plain tcp/25. DNS itself has become far more
evolved.

A mailserver of yester-year did far few DNS lookups in a hugely
different scale. I would not be surprised to see the common mail server
fetching every which type of DNS record and analyzing it from every
which angle as part and parcel of anti-spam measures. I do not thing it
is any significant burden to push the need for every MTA to fully
resolve an MX record which happens to be a CNAME as standard procedure.
It appears that many if not most, do so already. Especially those that
intentionally discriminate against incoming CNAME MX emails. That's
rather the cutting off of the nose to spite the face. You're going out
of your way to verify the reverse path of an incoming email. It is not
necessary for delivery so why do it?

What some people consider rubbish for input is desired for another.
Some people foam at the mouth should anyone bring up an editor other
than vi, or rich text email. Yet I'm amused that a person chooses to
spend 10 hours writing up something in vi and fighting with formatting
instead of using a GUI editor. I'm aghast at most ASCII rendition
attempts by someone, when a simple rich text markup would make it
instantly clear and require a miniscule amount of time trying to decode
and understand the horrible ASCII. There's a reason we have 96dpi 16m
color screens instead of a row of nixie tubes for display output. I'm
sure punch card bandits scoffed at the nixie tube users. Some people
just don't like change, or an idea that came from someone else, or
challenges their personal opinion how things ought to be.

Consider the "rubbish" email which a certain MTA vendor rejects out of
hand because each line isn't strictly well-formed per RFC. If every
vendor was as utterly asinine about absolutist conformance, sure, we'd
have a lot less mess out there, but we'd have a lot less forward
movement as well as a lot more fractioning of software packages. Since
everyone wants to do the protocol their own way, we'd just have a
multitude of protocol variations rather than more flexible interoperability.

The majority of the internet seems to run on "just enough clue" to make
things work and surprisingly, the amount of clue needed to move stuff
about the 'tubes isn't very much. In that regard, the internet seems to
work well enough even with some oddball CNAME MX records out there and
usually the only people noticing it are the elitist, and it isn't
necessarily due to email breakage.

Mark Andrews

unread,

Jan 27, 2009, 4:46:00 AM1/27/09

to

In message <10B3763032C94AE2BA4900B3137D1CE6@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_A...@isc.org>
> To: "Al Stu" <Al_...@Verizon.net>
> Cc: <bind-...@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@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_A...@isc.org>
> >> To: "Al Stu" <Al_...@Verizon.net>
> >> Cc: <bind-...@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"
> >>
> >>
> >> >

> >> > Mark
> >> >
> >> >> ----- Original Message -----
> >> >> From: "Scott Haneda" <talk...@newgeo.com>
> >> >> To: "Al Stu" <Al_...@Verizon.net>
> >> >> Cc: <bind-...@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-...@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_A...@isc.org
> >>

> >> _______________________________________________
> >> bind-users mailing list
> >> bind-...@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_A...@isc.org

> > _______________________________________________
> > bind-users mailing list
> > bind-...@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> bind-users mailing list
> bind-...@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_A...@isc.org

Scott Haneda

unread,

Jan 27, 2009, 5:52:04 AM1/27/09

to

On Jan 26, 2009, at 11:27 PM, David Ford wrote:

> hand because each line isn't strictly well-formed per RFC. If every
> vendor was as utterly asinine about absolutist conformance, sure, we'd
> have a lot less mess out there, but we'd have a lot less forward
> movement as well as a lot more fractioning of software packages.
> Since
> everyone wants to do the protocol their own way, we'd just have a
> multitude of protocol variations rather than more flexible
> interoperability.

it could be argued, that if there was absolutist conformance to
standards, we could move forward even faster. There is literally a
20% developer tax on debugging css and html to make it work with most
browsers. Many compromises made to satisfy the lack of strictness. I
am not totally disagreeing with you, I am not known to make ascii art
in emails :) but I do think we would have a better systems if
standards were more adhered to.

Michael van Elst

unread,

Jan 27, 2009, 1:34:15 AM1/27/09

to

Barry Margolin <bar...@alum.mit.edu> writes:

>customer.com. IN MX 10 mx.yourdomain.com.
>mx.yourdomain.com. IN CNAME mx.outsourcer.com.
>mx.outsourcer.com. IN A ...

That's just the same as

| customer.com. IN MX 10 mx.outsourcer.com.
| mx.outsourcer.com. IN A ...

except to people with half-a-knowledge about DNS queries.

--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."

Mark Andrews

unread,

Jan 27, 2009, 8:03:31 AM1/27/09

to

In message <glm9t7$p39$1...@serpens.de>, Michael van Elst writes:
> Barry Margolin <bar...@alum.mit.edu> writes:
>
> >customer.com. IN MX 10 mx.yourdomain.com.
> >mx.yourdomain.com. IN CNAME mx.outsourcer.com.
> >mx.outsourcer.com. IN A ...
>
> That's just the same as
>
> | customer.com. IN MX 10 mx.outsourcer.com.
> | mx.outsourcer.com. IN A ...
>
> except to people with half-a-knowledge about DNS queries.

Actually they are very different. If you don't understand
why they are different then you really have not had to run
a substantial MTA. Been there, done that, have the battle
scars.

Mark

> _______________________________________________
> bind-users mailing list
> bind-...@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_A...@isc.org

Al Stu

unread,

Jan 27, 2009, 11:46:05 AM1/27/09

to

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.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".

Matus UHLAR - fantomas

unread,

Jan 27, 2009, 12:01:54 PM1/27/09

to

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.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".

They are two queries. If mx1 would be an A, it would be returned in the
first query. Since it's a CNAME, the IP is not returned in the MX query.

--
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.

It's now safe to throw off your computer.

Al Stu

unread,

Jan 27, 2009, 1:13:07 PM1/27/09

to

"They are two queries. If mx1 would be an A, it would be returned in the
first query. Since it's a CNAME, the IP is not returned in the MX query."

So. RFC 5321 5.1, Locating the Target Host, says the CNAME is to be
processed.

"The lookup first attempts to locate an MX record associated with the name.
If a CNAME record is found, the resulting name is processed as if it were
the initial name."

*** PLEASE don't copy me on replies, I'll read them in the group ***

----- Original Message -----
From: "Matus UHLAR - fantomas" <uh...@fantomas.sk>

To: <bind-...@lists.isc.org>
Sent: Tuesday, January 27, 2009 9:01 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

Al Stu

unread,

Jan 27, 2009, 1:18:15 PM1/27/09

to

I not only say it, I have demonstrated it.
BIND is the DNS system we are discussing.
Have not looked to see if that specifically is spec'ed in an RFC.
Yes other DNS implementations do return both the A and CNAME.

*** PLEASE don't copy me on replies, I'll read them in the group ***

----- Original Message -----
From: <bsfi...@anl.gov>
To: <bind-...@lists.isc.org>
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" <Al_...@Verizon.net> wrote:
>
>>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
>>

>>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.
>

> You say, "both the A record and the CNAME record are returned."
> We know that BIND does this. Is this part of the RFC? Do other DNS
> implementation return both the "A" and the CNAME?
> ----------------------------------------------------------------------
> Barry S. Finkel
> Computing and Information Systems Division
> Argonne National Laboratory Phone: +1 (630) 252-7277
> 9700 South Cass Avenue Facsimile:+1 (630) 252-4601
> Building 222, Room D209 Internet: BSFi...@anl.gov
> Argonne, IL 60439-4828 IBMMAIL: I1004994

sth...@nethelp.no

unread,

Jan 27, 2009, 1:33:39 PM1/27/09

to

> >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
> >
> >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.
>
> You say, "both the A record and the CNAME record are returned."
> We know that BIND does this.

No, not all BIND versions do this. I'm running BIND 9.5, and when
asking about the MX for nullmx.domainmanager.com I'm getting

Answer: nullmx.domainmanager.com. CNAME mta.dewile.net.
Authority: dewile.net. SOA ...

Even if my BIND 9.5 name server has the A record for mta.dewile.net
in the cache, it is not returned.

> Is this part of the RFC? Do other DNS implementation return both
> the "A" and the CNAME?

My ISP's Nominum CNS name server does the same - returns the CNAME
in the answer section, and the SOA for dewile.net in the authority
section. No A record for dewile.net is returned.

However, this whole debate is rather pointless. We clearly have one
person who doesn't want to be convinced. That's okay - but he can't
expect ISC (and Nominum, etc) to change their software just because
he has a different interpretation of the RFCs than the rest of the
DNS world.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Ben Bridges

unread,

Jan 27, 2009, 1:59:16 PM1/27/09

to

When Section 5.1 of RFC 5321 says "If a CNAME record is found, the
resulting name is processed as if it were the initial name", it is
referring to the situation where a query is sent for the MX record for
xyz.com, and instead of an MX record being returned for xyz.com, a CNAME
record is returned for xyz.com (e.g., "xyz.com. IN CNAME
abc.com."). In that case, the client is then expected to start the
whole process over by querying for the MX record for abc.com. It is not
referring to the case where a query is sent for the MX record for
xyz.com and an MX record is returned for xyz.com having a CNAME for the
RDATA (such as, "XYZ IN MX 10 cn.xyz.com", where cn.xyz.com is a
CNAME for srv1.xyz.com.) In fact, Section 5.1 of RFC 5321 goes on to
discuss having CNAMEs returned in the RDATA of MX records and refers the
reader to Section 10.3 of RFC 2181, which explicity forbids CNAMEs in
the RDATA of either NS or MX records ("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.").

> -----Original Message-----
> From: bind-user...@lists.isc.org
> [mailto:bind-user...@lists.isc.org] On Behalf Of Al Stu
> Sent: Tuesday, January 27, 2009 12:13 PM
> To: bind-...@lists.isc.org
> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records
> are NOT "Illegal"
>

> "They are two queries. If mx1 would be an A, it would be
> returned in the first query. Since it's a CNAME, the IP is
> not returned in the MX query."
>
> So. RFC 5321 5.1, Locating the Target Host, says the CNAME
> is to be processed.
>
> "The lookup first attempts to locate an MX record associated
> with the name.
> If a CNAME record is found, the resulting name is processed
> as if it were the initial name."
>
>

> *** PLEASE don't copy me on replies, I'll read them in the group ***
>
>
> ----- Original Message -----

> From: "Matus UHLAR - fantomas" <uh...@fantomas.sk>

> To: <bind-...@lists.isc.org>
> Sent: 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.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".
> >
> > They are two queries. If mx1 would be an A, it would be
> returned in the
> > first query. Since it's a CNAME, the IP is not returned in
> the MX query.
> >
> > --
> > 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.
> > It's now safe to throw off your computer.

Mark Andrews

unread,

Jan 27, 2009, 5:33:25 PM1/27/09

to

In message <D53C69E1F478453A8371B49B4F04C5DC@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_A...@isc.org>
> To: "Al Stu" <Al_...@Verizon.net>

> Cc: <bind-...@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@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_A...@isc.org>
> >> To: "Al Stu" <Al_...@Verizon.net>
> >> Cc: <bind-...@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"
> >>
> >>
> >> >

> >> >> ----- Original Message -----
> >> >> From: "Mark Andrews" <Mark_A...@isc.org>
> >> >> To: "Al Stu" <Al_...@Verizon.net>
> >> >> Cc: <bind-...@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"
> >> >>
> >> >>
> >> >> >

> >> >> >> ----- Original Message -----
> >> >> >> From: "Scott Haneda" <talk...@newgeo.com>
> >> >> >> To: "Al Stu" <Al_...@Verizon.net>
> >> >> >> Cc: <bind-...@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-...@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_A...@isc.org
> >> >>

> >> >> _______________________________________________
> >> >> bind-users mailing list
> >> >> bind-...@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_A...@isc.org

> >> > _______________________________________________
> >> > bind-users mailing list
> >> > bind-...@lists.isc.org
> >> > https://lists.isc.org/mailman/listinfo/bind-users
> >>
> >> _______________________________________________
> >> bind-users mailing list
> >> bind-...@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_A...@isc.org
>

> _______________________________________________
> bind-users mailing list
> bind-...@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_A...@isc.org

Barry Margolin

unread,

Jan 27, 2009, 11:41:26 PM1/27/09

to

In article <glma06$8dd$1...@sf1.isc.org>,
Mark Andrews <Mark_A...@isc.org> wrote:

> Liberal in what you accepts means don't die on arbitary
> input. You should still reject rubbish.

But MX pointing to CNAME is not "rubbish". It's a violation of the
letter of the spec, but it's very clear what is intended.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA

*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin

unread,

Jan 27, 2009, 11:48:36 PM1/27/09

to

In article <glmqqb$jvv$1...@sf1.isc.org>,

mle...@serpens.de (Michael van Elst) wrote:

> Barry Margolin <bar...@alum.mit.edu> writes:
>
> >customer.com. IN MX 10 mx.yourdomain.com.
> >mx.yourdomain.com. IN CNAME mx.outsourcer.com.
> >mx.outsourcer.com. IN A ...
>
> That's just the same as
>
> | customer.com. IN MX 10 mx.outsourcer.com.
> | mx.outsourcer.com. IN A ...
>
> except to people with half-a-knowledge about DNS queries.

It's the same in layer 7, but not in layer 8. If you decide to change
outsourcing companies, you have to get hundreds of customers to change
their MX records, instead of just changing one CNAME record.

I used to work at an ISP, and we provided slave DNS for many customers.
At various times we had to change the names and/or addresses of our
servers, as the business grew (e.g. when we acquired other companies,
and wanted to migrate the domains they were hosting to our servers). We
frequently saw obsolete glue records in our customers' domains years
after these changes, and they often found their way into caches so they
interfered with other domains we hosted as well.

So anything you can do to avoid depending on customers to make changes
at their end makes operating a business easier.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin

unread,

Jan 27, 2009, 11:51:37 PM1/27/09

to

In article <glnemv$10nf$1...@sf1.isc.org>,

Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

> 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.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".
>
> They are two queries. If mx1 would be an A, it would be returned in the
> first query. Since it's a CNAME, the IP is not returned in the MX query.

So what? If the IP isn't in the additional section, the client will do
its own A query.

There's no requirement that the response to the MX record include the A
record. It's nice if it does, since it saves a query, but this is just
an optimization.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Matus UHLAR - fantomas

unread,

Jan 28, 2009, 2:56:49 AM1/28/09

to

> > 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.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".

> In article <glnemv$10nf$1...@sf1.isc.org>,

> Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

> > They are two queries. If mx1 would be an A, it would be returned in the
> > first query. Since it's a CNAME, the IP is not returned in the MX query.

On 27.01.09 23:51, Barry Margolin wrote:
> So what? If the IP isn't in the additional section, the client will do
> its own A query.

so the client has to do an A query, because A is not returned in the MX
query.

> There's no requirement that the response to the MX record include the A

> record. It's nice if it does, since it saves a query, but this is just
> an optimization.

exactly. That's what I was trying to explain.

--
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.

Windows 2000: 640 MB ought to be enough for anybody

Matus UHLAR - fantomas

unread,

Jan 28, 2009, 3:02:49 AM1/28/09

to

> > You say, "both the A record and the CNAME record are returned."
> > We know that BIND does this.

On 27.01.09 19:33, sth...@nethelp.no wrote:
> No, not all BIND versions do this. I'm running BIND 9.5, and when
> asking about the MX for nullmx.domainmanager.com I'm getting
>
> Answer: nullmx.domainmanager.com. CNAME mta.dewile.net.
> Authority: dewile.net. SOA ...
>
> Even if my BIND 9.5 name server has the A record for mta.dewile.net
> in the cache, it is not returned.

What was te question? If it was "any" or "cname", the bind won't return
that. If the question was "A", it should be returned, unless you have
allow-recursion or allow-query-cache turned off

--
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.

"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."

Matus UHLAR - fantomas

unread,

Jan 28, 2009, 3:04:26 AM1/28/09

to

On 27.01.09 10:18, Al Stu wrote:
> I not only say it, I have demonstrated it.

But you have demonstrated something different than we're discussing all the
time.

> BIND is the DNS system we are discussing.
> Have not looked to see if that specifically is spec'ed in an RFC.

> Yes other DNS implementations do return both the A and CNAME.

It depends on the query sent.

--
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.

Fighting for peace is like fucking for virginity...

Al Stu

unread,

Jan 30, 2009, 1:33:24 AM1/30/09

to

This is a multi-part message in MIME format.

------=_NextPart_000_01E3_01C98261.98CFBEC0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
Content-Transfer-Encoding: 7bit

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.

------=_NextPart_000_01E3_01C98261.98CFBEC0
Content-Type: text/plain; format=flowed; name="DNS_MX.txt"; reply-type=response
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="DNS_MX.txt"

No. Time Source Destination Protocol =
Info
1 0.000000 192.168.1.16 64.40.103.249 DNS =
Standard query MX dns.com

Frame 1 (67 bytes on wire, 67 bytes captured)
Ethernet II, Src: Usi_de:94:de (00:10:c6:de:94:de), Dst: =
Actionte_51:fa:72 (00:18:01:51:fa:72)
Internet Protocol, Src: 192.168.1.16 (192.168.1.16), Dst: 64.40.103.249 =
(64.40.103.249)
User Datagram Protocol, Src Port: ltp (4044), Dst Port: domain (53)
Domain Name System (query)
[Response In: 2]
Transaction ID: 0x0008
Flags: 0x0100 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
dns.com: type MX, class IN
Name: dns.com
Type: MX (Mail exchange)
Class: IN (0x0001)

No. Time Source Destination Protocol =
Info
2 0.016776 64.40.103.249 192.168.1.16 DNS =
Standard query response MX 0 nullmx.domainmanager.com

Frame 2 (104 bytes on wire, 104 bytes captured)
Ethernet II, Src: Actionte_51:fa:72 (00:18:01:51:fa:72), Dst: =
Usi_de:94:de (00:10:c6:de:94:de)
Internet Protocol, Src: 64.40.103.249 (64.40.103.249), Dst: 192.168.1.16 =
(192.168.1.16)
User Datagram Protocol, Src Port: domain (53), Dst Port: ltp (4044)
Domain Name System (response)
[Request In: 1]
[Time: 0.016776000 seconds]
Transaction ID: 0x0008
Flags: 0x8500 (Standard query response, No error)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
dns.com: type MX, class IN
Name: dns.com
Type: MX (Mail exchange)
Class: IN (0x0001)
Answers
dns.com: type MX, class IN, preference 0, mx =
nullmx.domainmanager.com
Name: dns.com
Type: MX (Mail exchange)
Class: IN (0x0001)
Time to live: 1 hour
Data length: 25
Preference: 0
Mail exchange: nullmx.domainmanager.com

No. Time Source Destination Protocol =
Info
3 2.478114 192.168.1.16 64.40.103.249 DNS =
Standard query A nullmx.domainmanager.com

Frame 3 (84 bytes on wire, 84 bytes captured)
Ethernet II, Src: Usi_de:94:de (00:10:c6:de:94:de), Dst: =
Actionte_51:fa:72 (00:18:01:51:fa:72)
Internet Protocol, Src: 192.168.1.16 (192.168.1.16), Dst: 64.40.103.249 =
(64.40.103.249)
User Datagram Protocol, Src Port: acp-proto (4046), Dst Port: domain =
(53)
Domain Name System (query)
[Response In: 4]
Transaction ID: 0x0006
Flags: 0x0100 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
nullmx.domainmanager.com: type A, class IN
Name: nullmx.domainmanager.com
Type: A (Host address)
Class: IN (0x0001)

No. Time Source Destination Protocol =
Info
4 0.016820 64.40.103.249 192.168.1.16 DNS =
Standard query response CNAME mta.dewile.net A 64.40.103.249

Frame 4 (128 bytes on wire, 128 bytes captured)
Ethernet II, Src: Actionte_51:fa:72 (00:18:01:51:fa:72), Dst: =
Usi_de:94:de (00:10:c6:de:94:de)
Internet Protocol, Src: 64.40.103.249 (64.40.103.249), Dst: 192.168.1.16 =
(192.168.1.16)
User Datagram Protocol, Src Port: domain (53), Dst Port: acp-proto =
(4046)
Domain Name System (response)
[Request In: 3]
[Time: 0.016820000 seconds]
Transaction ID: 0x0006
Flags: 0x8500 (Standard query response, No error)
Questions: 1
Answer RRs: 2
Authority RRs: 0
Additional RRs: 0
Queries
nullmx.domainmanager.com: type A, class IN
Name: nullmx.domainmanager.com
Type: A (Host address)
Class: IN (0x0001)
Answers
nullmx.domainmanager.com: type CNAME, class IN, cname =
mta.dewile.net
Name: nullmx.domainmanager.com
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 1 minute
Data length: 16
Primary name: mta.dewile.net
mta.dewile.net: type A, class IN, addr 64.40.103.249
Name: mta.dewile.net
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 hour
Data length: 4
Addr: 64.40.103.249

------=_NextPart_000_01E3_01C98261.98CFBEC0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

------=_NextPart_000_01E3_01C98261.98CFBEC0--

Matus UHLAR - fantomas

unread,

Jan 30, 2009, 2:56:34 AM1/30/09

to

On 29.01.09 22:33, Al Stu wrote:
> Analyze this.

Why?

> Query MX dns.com
>
> Response MX nullmx.domainmanager.com
>
>
>
> Query A nullmx.domainmanager.com
>
> Response CNAME mta.dewile.net, A 64.40.103.249

--

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.

- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

Ben Bridges

unread,

Jan 30, 2009, 9:23:00 AM1/30/09

to

The authoritative name servers for nullmx.domainmanager.com are
ns1.domainmanager.com and ns2.domainmanager.com. They are domain
parking name servers. They return 64.40.103.249 (or at least something
close to that) to the query for any A record. The real address of
mta.dewile.net is 69.59.189.80 (as supplied by ns1.alices-registry.com,
one of the authoritative name servers for "dewile.net").

> -----Original Message-----
> From: bind-user...@lists.isc.org
> [mailto:bind-user...@lists.isc.org] On Behalf Of Al Stu

> Sent: Friday, January 30, 2009 12:33 AM
> To: bind-...@lists.isc.org
> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records
> are NOT "Illegal"
>

> 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.

Michael Milligan

unread,

Jan 30, 2009, 1:20:27 PM1/30/09

to

You just don't get it. You are off wandering around in the weeds.

Read the tail end of Chapter 5 in the book "DNS and BIND" describing the
MX selection algorithm in layman's terms to (perhaps) understand why
having MX records referencing CNAMEs is bad.

It may work right now for you, but referencing CNAMEs in MX records
eventually _will_ cause delivery loops the next time you accidentally
fat-finger a config. If you continue to be hard-headed about this and
not listen to the 100s of years of collective wisdom dispensed, then go
ahead and leave yourself set up for a potential DoS against yourself,
we're not going to stop you... and we're not going to feel sorry for
you either.

FIN

Regards,
Mike

Al Stu wrote:
> 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
>

_______________________________________________

David Sparks

unread,

Jan 30, 2009, 9:12:02 PM1/30/09

to

Michael Milligan wrote:
> You just don't get it. You are off wandering around in the weeds.
>
> Read the tail end of Chapter 5 in the book "DNS and BIND" describing the
> MX selection algorithm in layman's terms to (perhaps) understand why
> having MX records referencing CNAMEs is bad.
>
> It may work right now for you, but referencing CNAMEs in MX records
> eventually _will_ cause delivery loops the next time you accidentally
> fat-finger a config. If you continue to be hard-headed about this and
> not listen to the 100s of years of collective wisdom dispensed, then go
> ahead and leave yourself set up for a potential DoS against yourself,
> we're not going to stop you... and we're not going to feel sorry for
> you either.

There are plenty of ways to get a mail loop that don't involve DNS
mis-configuration. As such pretty much every major MTA detects and stops mail
loops.

So mail loops are a non-issue ... next?

ds

> FIN
>
> Regards,
> Mike
>
> Al Stu wrote:
>> 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
>>
>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Environmental thought: print this email in triplicate!
(ygolohcysp esrever)

Al Stu

unread,

Jan 31, 2009, 1:55:58 AM1/31/09

to

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 vindicated once the masses and so called experts
get their head out where the sun is shining and exposed to the light of day.

Once upon a time the world was 'flat'. For some of you, apparently is still
is 'flat'.

----- Original Message -----
From: "Michael Milligan" <mi...@acmeps.com>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@lists.isc.org>

Sent: Friday, January 30, 2009 10:20 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

> You just don't get it. You are off wandering around in the weeds.
>
> Read the tail end of Chapter 5 in the book "DNS and BIND" describing the
> MX selection algorithm in layman's terms to (perhaps) understand why
> having MX records referencing CNAMEs is bad.
>
> It may work right now for you, but referencing CNAMEs in MX records
> eventually _will_ cause delivery loops the next time you accidentally
> fat-finger a config. If you continue to be hard-headed about this and
> not listen to the 100s of years of collective wisdom dispensed, then go
> ahead and leave yourself set up for a potential DoS against yourself,
> we're not going to stop you... and we're not going to feel sorry for
> you either.
>

Noel Butler

unread,

Jan 31, 2009, 2:12:17 AM1/31/09

to

--===============2014548611128320955==
Content-Type: multipart/alternative; boundary="=-aNHgT03h/Y3xWX6AGz5R"

--=-aNHgT03h/Y3xWX6AGz5R
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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, just because you
believe in your own trolling, don't assume agree with you, let alone
"masses" of others

--=-aNHgT03h/Y3xWX6AGz5R
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
On Sat, 2009-01-31 at 16:55, Al Stu wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>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 </PRE>
</BLOCKQUOTE>
 
You don't get to speak for anyone else but yourself,  just because you believe in your own trolling, don't assume agree with you, let alone "masses" of others
<PRE><A HREF="https://lists.isc.org/mailman/listinfo/bind-users"></A></PRE>
</BODY>
</HTML>

--=-aNHgT03h/Y3xWX6AGz5R--

--===============2014548611128320955==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============2014548611128320955==--

Danny Thomas

unread,

Jan 31, 2009, 2:17:57 AM1/31/09

to

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 vindicated once the masses
> and so called experts get their head out where the sun is shining and
> exposed to the light of day.
>
> Once upon a time the world was 'flat'. For some of you, apparently is
> still is 'flat'.

and for every Einstein, Columbus, etc, there have been untold people whose
beliefs were not accepted. So whenever I see this line of argument
advanced in a
simplistic way, particularly with a hint of an heroic struggle against
orthodoxy,
I can't help thinking that the odds of "heretical views" being
vindicated is pretty low.
One belief yet to be accepted is the existence of Martian sand whales.

*really plonk*

Jeff Lightner

unread,

Jan 31, 2009, 10:05:52 AM1/31/09

to

What?!

And all this time I just assumed it was the Martian Sand variety that
was being spoken of on all the "save the whales" bumper stickers.

Maybe Al will end up winning the Darwin Award for another one of his
avante garde ideas. He'll decide that the conventional wisdom that
exhausting his engine through a tail pipe instead of into the cabin is
the cause of global warming and modify his car...

-----Original Message-----
From: bind-user...@lists.isc.org
[mailto:bind-user...@lists.isc.org] On Behalf Of Danny Thomas
Sent: Saturday, January 31, 2009 2:18 AM
To: bind-...@lists.isc.org
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

*really plonk*

Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

Al Stu

unread,

Jan 31, 2009, 1:05:20 PM1/31/09

to

The basic argument that because it can be misused, abused, criminally
exploited, etc., it should be abolished, not permitted, and deemed "illegal"
by a group of people who should not have that authority, even though it has
practical and beneficial uses is absurd. By that 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" <mi...@acmeps.com>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@lists.isc.org>
Sent: Friday, January 30, 2009 10:20 AM

Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

> You just don't get it. You are off wandering around in the weeds.
>
> Read the tail end of Chapter 5 in the book "DNS and BIND" describing the
> MX selection algorithm in layman's terms to (perhaps) understand why
> having MX records referencing CNAMEs is bad.
>
> It may work right now for you, but referencing CNAMEs in MX records
> eventually _will_ cause delivery loops the next time you accidentally
> fat-finger a config. If you continue to be hard-headed about this and
> not listen to the 100s of years of collective wisdom dispensed, then go
> ahead and leave yourself set up for a potential DoS against yourself,
> we're not going to stop you... and we're not going to feel sorry for
> you either.
>
> FIN
>
> Regards,
> Mike
>
> Al Stu wrote:
>> 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
>>
>

_______________________________________________

Al Stu

unread,

Jan 31, 2009, 1:08:36 PM1/31/09

to

This is a multi-part message in MIME format.

--===============1326788655728705971==
Content-type: multipart/alternative;
boundary="----=_NextPart_000_02CB_01C9838B.E1720A90"

This is a multi-part message in MIME format.

------=_NextPart_000_02CB_01C9838B.E1720A90
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I am trolling, that would make you a sucker/trash fish. Was the bait =
tasty?

That sentence does not make sense.

----- Original Message -----=20
From: Noel Butler=20
To: bind-...@lists.isc.org=20
Sent: Friday, January 30, 2009 11:12 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT =
"Illegal"

On Sat, 2009-01-31 at 16:55, Al Stu wrote:=20
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=20
You don't get to speak for anyone else but yourself, just because you =
believe in your own trolling, don't assume agree with you, let alone =
"masses" of others=20

-------------------------------------------------------------------------=
-----

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

------=_NextPart_000_02CB_01C9838B.E1720A90
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; CHARSET=3DUTF-8">
<META content=3D"MSHTML 6.00.6000.16788" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>If I am trolling, that would make you a =

sucker/trash fish.  Was the bait tasty?</DIV>
<DIV> </DIV>
<DIV>That sentence does not make =
sense.</DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black">From:=20
<A title=3Dnoel...@ausics.net =
href=3D"mailto:noel....@ausics.net">Noel=20
Butler</A> </DIV>
<DIV style=3D"FONT: 10pt arial">To: <A =
title=3Dbind...@lists.isc.org=20
href=3D"mailto:bind-...@lists.isc.org">bind-...@lists.isc.org</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial">Sent: Friday, January 30, 2009 =
11:12=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial">Subject: Re: BIND 9.6 Flaw - =
CNAME vs. A=20
Record in MX Records are NOT "Illegal"</DIV>
<DIV> </DIV>On Sat, 2009-01-31 at 16:55, Al Stu wrote:=20
<BLOCKQUOTE TYPE=3D"CITE"><PRE>History is =
fraught with individuals or a few being ridiculed for putting=20
forth that which goes against the conventional wisdom of the masses and =
so </PRE></BLOCKQUOTE> You=20
don't get to speak for anyone else but yourself,  just because =
you=20
believe in your own trolling, don't assume agree with you, let alone =
"masses"=20
of others <PRE><A =
href=3D"https://lists.isc.org/mailman/listinfo/bind-users"></A></PRE>

<HR>

_______________________________________________ bind-users =
mailing=20
=
list bind-...@lists.isc.org https://lists.isc.org/mailman/listinf=
o/bind-users</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_02CB_01C9838B.E1720A90--

--===============1326788655728705971==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============1326788655728705971==--

Al Stu

unread,

Jan 31, 2009, 1:11:09 PM1/31/09

to

And you would be one of those going to your grave still insisting that the
world is still flat. I sure there where many who thought similarly with it
was being presented that the world was not flat.

----- Original Message -----
From: "Danny Thomas" <d.th...@its.uq.edu.au>
To: <bind-...@lists.isc.org>
Sent: Friday, January 30, 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 vindicated once the masses and so called
>> experts get their head out where the sun is shining and exposed to the
>> light of day.
>>
>> Once upon a time the world was 'flat'. For some of you, apparently is
>> still is 'flat'.
> and for every Einstein, Columbus, etc, there have been untold people whose
> beliefs were not accepted. So whenever I see this line of argument
> advanced in a
> simplistic way, particularly with a hint of an heroic struggle against
> orthodoxy,
> I can't help thinking that the odds of "heretical views" being vindicated
> is pretty low.
> One belief yet to be accepted is the existence of Martian sand whales.
>
> *really plonk*
>
>

Al Stu

unread,

Jan 31, 2009, 1:18:40 PM1/31/09

to

And what business of yours would it be if I did? That is pretty much the
point here. What business is it of yours, ISC, or anyone else if I chose to
run my DNS with MX's pointing to CNAMES? If it is a "bad" practice, fine so
be it. But it has practical and beneficial uses. For ISC to deem it
"illegal" is a fallacy and inappropriate..

----- Original Message -----
From: "Jeff Lightner" <jlig...@water.com>
To: "Danny Thomas" <d.th...@its.uq.edu.au>; <bind-...@lists.isc.org>
Sent: Saturday, January 31, 2009 7:05 AM
Subject: RE: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"

> What?!
>
> And all this time I just assumed it was the Martian Sand variety that
> was being spoken of on all the "save the whales" bumper stickers.
>
> Maybe Al will end up winning the Darwin Award for another one of his
> avante garde ideas. He'll decide that the conventional wisdom that
> exhausting his engine through a tail pipe instead of into the cabin is
> the cause of global warming and modify his car...
>
> -----Original Message-----
> From: bind-user...@lists.isc.org
> [mailto:bind-user...@lists.isc.org] On Behalf Of Danny Thomas
> Sent: Saturday, January 31, 2009 2:18 AM
> To: bind-...@lists.isc.org

> Please consider our environment before printing this e-mail or
> attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
> information and is for the sole use of the intended recipient(s). If you
> are not the intended recipient, any disclosure, copying, distribution, or
> use of the contents of this information is prohibited and may be unlawful.
> If you have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
> ----------------------------------

Matthew Pounsett

unread,

Jan 31, 2009, 1:26:16 PM1/31/09

to

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6394990837899581544==
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-sha1; boundary="Apple-Mail-35--431377642"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-35--431377642
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 31-Jan-2009, at 13:18, Al Stu wrote:

>
> And what business of yours would it be if I did? That is pretty
> much the point here. What business is it of yours, ISC, or anyone
> else if I chose to run my DNS with MX's pointing to CNAMES? If it
> is a "bad" practice, fine so be it. But it has practical and
> beneficial uses. For ISC to deem it "illegal" is a fallacy and
> inappropriate..

ISC did not deem it illegal. The IETF working group that designed the
protocol deemed it illegal. If you have a problem with it, take it up
with the DNSEXT working group.

You have been presented with the means to turn off the behaviour. Use
that or don't; it's up to you. Please stop whining about it.

*plonk*

--Apple-Mail-35--431377642
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEUEARECAAYFAkmEl8gACgkQmFeRJ0tjIxE6mwCWNJRGb9N+xnvW7sNy46LQ4lmz
oQCfdKYlcnhv5CZrFIePusVPRUfdQn0=
=G3px
-----END PGP SIGNATURE-----

--Apple-Mail-35--431377642--

--===============6394990837899581544==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============6394990837899581544==--

Noel Butler

unread,

Jan 31, 2009, 5:38:00 PM1/31/09

to

--===============0553564684699197193==
Content-Type: multipart/alternative; boundary="=-6Czo35W7u08sqsg/feRj"

--=-6Czo35W7u08sqsg/feRj
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Sun, 2009-02-01 at 04:08, Al Stu wrote:

>

> If I am trolling, that would make you a sucker/trash fish. Was the

> bait tasty?

>
> That sentence does not make sense.
>

it does, i love to go fishing when i'm bored, and are so full of it
you're everywhere in the lil pond.

I have not read your shit for over a week since I was busy, but you'll
never learn, IOW go cry to someone who might actually give a flying F.
you can not be that thick, the fact you are still trolling about it
indicates that exactly is what you are

> ----- Original Message -----
> From: Noel Butler
> To: bind-...@lists.isc.org

> Sent: Friday, January 30, 2009 11:12 PM
> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in 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, just

> because you believe in your own trolling, don't assume agree
> with you, let alone "masses" of others
>
>
> ______________________________________________________________

>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>

> ______________________________________________________________________

>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--=-6Czo35W7u08sqsg/feRj

Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>

On Sun, 2009-02-01 at 04:08, Al Stu wrote:
<BLOCKQUOTE TYPE=CITE>

If I am trolling, that would make you a sucker/trash fish.  Was the bait tasty? 
  
That sentence does not make sense. 
 
</BLOCKQUOTE>
 
it does, i love to go fishing when i'm bored, and are so full of it you're everywhere in the lil pond. 
 
I have not read your shit for over a week since I was busy, but you'll never learn, IOW go cry to someone who might actually give a flying F.  you can not be that thick, the fact you are still trolling about it indicates that exactly is what you are 
 
 
 
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
----- Original Message ----- 
From: <A HREF="mailto:noel....@ausics.net">Noel Butler</A> 
To: <A HREF="mailto:bind-...@lists.isc.org">bind-...@lists.isc.org</A> 
Sent: Friday, January 30, 2009 11:12 PM 
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

On Sat, 2009-01-31 at 16:55, Al Stu wrote:

<BLOCKQUOTE TYPE=CITE>
<PRE>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 </PRE>
</BLOCKQUOTE>
 
You don't get to speak for anyone else but yourself,  just because you believe in your own trolling, don't assume agree with you, let alone "masses" of others 
 

<HR>
 
 
_______________________________________________ 
bind-users mailing list 
bind-...@lists.isc.org 
https://lists.isc.org/mailman/listinfo/bind-users
</BLOCKQUOTE>
 

<HR>

<PRE>_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
<A HREF="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</A></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-6Czo35W7u08sqsg/feRj--

--===============0553564684699197193==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============0553564684699197193==--

Noel Butler

unread,

Jan 31, 2009, 5:39:45 PM1/31/09

to

--===============6506615226664191170==
Content-Type: multipart/alternative; boundary="=-k8HfpgGSqeCb11BAt3Im"

--=-k8HfpgGSqeCb11BAt3Im
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Sun, 2009-02-01 at 04:05, Al Stu wrote:

> The basic argument that because it can be misused, abused, criminally
> exploited, etc., it should be abolished, not permitted, and deemed "illegal"
> by a group of people who should not have that authority, even though it has
> practical and beneficial uses is absurd. By that 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.
>
>

FFS.. piss off

> ----- Original Message -----
> From: "Michael Milligan" <mi...@acmeps.com>
> To: "Al Stu" <Al_...@Verizon.net>

> Cc: <bind-...@lists.isc.org>
> Sent: Friday, January 30, 2009 10:20 AM
> Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
> "Illegal"
>
>

> > You just don't get it. You are off wandering around in the weeds.
> >
> > Read the tail end of Chapter 5 in the book "DNS and BIND" describing the
> > MX selection algorithm in layman's terms to (perhaps) understand why
> > having MX records referencing CNAMEs is bad.
> >
> > It may work right now for you, but referencing CNAMEs in MX records
> > eventually _will_ cause delivery loops the next time you accidentally
> > fat-finger a config. If you continue to be hard-headed about this and
> > not listen to the 100s of years of collective wisdom dispensed, then go
> > ahead and leave yourself set up for a potential DoS against yourself,
> > we're not going to stop you... and we're not going to feel sorry for
> > you either.
> >
> > FIN
> >
> > Regards,
> > Mike
> >
> > Al Stu wrote:
> >> 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
> >>
> >
>

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--=-k8HfpgGSqeCb11BAt3Im

Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>

On Sun, 2009-02-01 at 04:05, Al Stu wrote:
<BLOCKQUOTE TYPE=CITE>

<PRE>The basic argument that because it can be misused, abused, criminally
exploited, etc., it should be abolished, not permitted, and deemed "illegal"

by a group of people who should not have that authority, even though it has
practical and beneficial uses is absurd. By that 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.

</PRE>
</BLOCKQUOTE>
 
FFS.. piss off 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>----- Original Message -----
From: "Michael Milligan" <mi...@acmeps.com>
To: "Al Stu" <Al_...@Verizon.net>
Cc: <bind-...@lists.isc.org>
Sent: Friday, January 30, 2009 10:20 AM

Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT

"Illegal"

> You just don't get it. You are off wandering around in the weeds.
>
> Read the tail end of Chapter 5 in the book "DNS and BIND" describing the
> MX selection algorithm in layman's terms to (perhaps) understand why
> having MX records referencing CNAMEs is bad.
>
> It may work right now for you, but referencing CNAMEs in MX records
> eventually _will_ cause delivery loops the next time you accidentally
> fat-finger a config. If you continue to be hard-headed about this and
> not listen to the 100s of years of collective wisdom dispensed, then go
> ahead and leave yourself set up for a potential DoS against yourself,
> we're not going to stop you... and we're not going to feel sorry for
> you either.
>
> FIN
>
> Regards,
> Mike
>
> Al Stu wrote:
>> 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
>>
>

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
<A HREF="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</A></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-k8HfpgGSqeCb11BAt3Im--

--===============6506615226664191170==

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--===============6506615226664191170==--

Matus UHLAR - fantomas

unread,

Feb 1, 2009, 10:00:42 AM2/1/09

to

On 30.01.09 22: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

> called experts, only to be vindicated once the masses and so called experts
> get their head out where the sun is shining and exposed to the light of day.
>
> Once upon a time the world was 'flat'. For some of you, apparently is
> still is 'flat'.

Don Quijote

--
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.

Christian Science Programming: "Let God Debug It!".

Carl Byington

unread,

Jan 30, 2009, 12:08:21 PM1/30/09

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 29 Jan 2009 22:33:24 -0800, Al Stu wrote:

> 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

So the fact that other random folks make errors in their dns is suprising,
or do you wish to use the existence of those errors to justify making those
same errors yourself?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFJgzPXL6j7milTFsERAmK2AKCHBKTudsFFbdekhR0pmCN0EAv+LwCfarkK
PTfobRXHugzLPmLdb1UQCMI=
=YQjr
-----END PGP SIGNATURE-----

Michael Milligan

unread,

Feb 2, 2009, 2:20:40 PM2/2/09

to

David Sparks wrote:
>
> There are plenty of ways to get a mail loop that don't involve DNS
> mis-configuration. As such pretty much every major MTA detects and stops mail
> loops.

Not if you (accidentally) fat-finger the MTA configuration. It is
completely possible to still mis-configure a MTA to deliver to itself as
fast as possible. A DNS configuration with CNAMEs in the mix
short-circuits delivery loop detection at the MX level and just sets up
more potential for a loop.

>
> So mail loops are a non-issue ... next?
>

That is the _entire_ issue here.

Regards,
Mike