Discussion:
BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"
(too old to reply)
Al Stu
2009-01-25 06:11:06 UTC
Permalink
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><FONT face=3DArial size=3D2>
<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"><FONT size=3D3>BIND 9.6&nbsp;=91named=92 throws =
the following=20
message during startup claiming that it is illegal to use&nbsp;a =
CNAME/alias in=20
the MX record. <SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>I beg to=20
differ.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>There is no such =
standard=20
nor requirement prohibiting the use of CNAME/alias in an MX=20
record.</FONT></FONT></SPAN></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'"><FONT face=3D"Times =
New Roman"=20
size=3D3></FONT></SPAN>&nbsp;</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'"><FONT face=3D"Times =
New Roman"=20
size=3D3>Message thrown at startup:</FONT></SPAN></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'"><FONT =
size=3D3>"named[3307]:=20
zone <EM>MyDomain</EM>.com/IN: <EM>MyDomain</EM>.com/MX=20
'MX1.<EM>MyDomain</EM>.com' is a CNAME (illegal)"</FONT></SPAN></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'"></SPAN>&nbsp;</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'"></SPAN><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman"><FONT size=3D3>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</FONT></FONT></SPAN></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'"></SPAN>&nbsp;</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'"></SPAN><SPAN=20
style=3D"FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"><FONT=20
face=3D"Times New Roman"><FONT size=3D3>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">&nbsp;</SPAN>But very much to the =
contrary&nbsp;RFC=20
974 demonstrates that CNAME/alias is permitted in MX=20
records.</FONT></FONT></SPAN></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'"></SPAN>&nbsp;</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'"><FONT=20
face=3D"Times New Roman"><FONT size=3D3>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.</FONT></FONT></SPAN></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'"><FONT=20
face=3D"Times New Roman"><FONT size=3D3></FONT></FONT></SPAN>&nbsp;</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'"><FONT=20
face=3D"Times New Roman"><FONT size=3D3>Al =
Stu<o:p></o:p></FONT></FONT></SPAN></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>&nbsp;</FONT></o:p></SPAN></P>
<DIV>&nbsp;</DIV></FONT></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
Frank Bulk
2009-01-25 07:11:04 UTC
Permalink
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-users-***@lists.isc.org
[mailto:bind-users-***@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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>Al:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>If you read RFC 2181 section 10.3, RFC 1034 section 3.6, =
RFC
1912 (page 6), the average person would understand that it&#8217;s =
strongly discouraged.&nbsp;
Perhaps &#8220;illegal&#8221; is too strong a word, but the weight of =
the RFCs
and best practices appears to disagree with your assessment that =
&#8220;there
is no such standard nor requirement prohibiting the use of CNAME/alias =
in an MX
record.&#8221;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>Frank<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
bind-users-***@lists.isc.org =
[mailto:bind-users-***@lists.isc.org] <b>On
Behalf Of </b>Al Stu<br>
<b>Sent:</b> Sunday, January 25, 2009 12:11 AM<br>
<b>To:</b> bind-***@lists.isc.org<br>
<b>Subject:</b> BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
&quot;Illegal&quot;<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>BIND 9.6&nbsp;&#8216;named&#8217; throws the =
following
message during startup claiming that it is illegal to use&nbsp;a =
CNAME/alias in
the MX record.&nbsp; I beg to differ.&nbsp; There is no such standard =
nor
requirement prohibiting the use of CNAME/alias in an MX =
record.<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>Message thrown at startup:<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New"'>&quot;named[3307]:
zone <em><span style=3D'font-family:"Courier =
New"'>MyDomain</span></em>.com/IN: <em><span
style=3D'font-family:"Courier New"'>MyDomain</span></em>.com/MX =
'MX1.<em><span
style=3D'font-family:"Courier New"'>MyDomain</span></em>.com' is a CNAME
(illegal)&quot;</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>Additionally in Chapter 6 &#8211; BIND =
Configuration
Reference, Zone File, Discussion of MX Records states the MX records
&#8220;must have an associated address record (A or AAAA) &#8211; CNAME =
is not
sufficient.&#8221;<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>Some people seem to think RFC 974 creates a =
standard which
prohibits the use of CNAME/alias in MX records.&nbsp; But very much to =
the
contrary&nbsp;RFC 974 demonstrates that CNAME/alias is permitted in MX =
records.<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>ISC&#8217;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></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>Al Stu<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

</div>

</div>

</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
Danny Thomas
2009-01-25 07:14:07 UTC
Permalink
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
2009-01-25 08:23:29 UTC
Permalink
Post by Al Stu
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."
Post by Al Stu
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
2009-01-25 08:30:47 UTC
Permalink
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
2009-01-25 08:44:36 UTC
Permalink
"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" <***@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"
Post by Al Stu
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.
"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."
Post by Al Stu
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
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
SM
2009-01-25 14:46:02 UTC
Permalink
Post by SM
"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.

Regards,
-sm
Matthew Pounsett
2009-01-25 15:37:04 UTC
Permalink
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
Post by SM
"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
Chris Thompson
2009-01-25 17:28:12 UTC
Permalink
Post by Al Stu
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: ***@cam.ac.uk
Al Stu
2009-01-25 17:41:40 UTC
Permalink
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 ***@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
2009-01-25 17:49:04 UTC
Permalink
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
Post by Al Stu
"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
Barry Margolin
2009-01-26 04:06:24 UTC
Permalink
Post by Matthew Pounsett
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, ***@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Matthew Pounsett
2009-01-26 04:43:51 UTC
Permalink
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
Post by Barry Margolin
Post by Matthew Pounsett
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
Al Stu
2009-01-25 18:15:46 UTC
Permalink
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" <***@conundrum.com>
To: "Al Stu" <***@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
2009-01-25 18:30:34 UTC
Permalink
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)

----- Original Message -----
From: "Al Stu" <***@Verizon.net>
To: <bind-***@lists.isc.org>
Sent: Sunday, January 25, 2009 10:15 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Al Stu
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 -----
Sent: Sunday, January 25, 2009 9:49 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
------=_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
Matthew Pounsett
2009-01-25 18:30:21 UTC
Permalink
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
Post by Al Stu
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
Al Stu
2009-01-25 18:47:11 UTC
Permalink
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" <***@conundrum.com>
To: "Al Stu" <***@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"
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Alan Clegg
2009-01-25 20:02:57 UTC
Permalink
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
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
Chris Hills
2009-01-25 22:43:38 UTC
Permalink
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
2009-01-25 22:52:40 UTC
Permalink
Post by Chris Hills
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: ***@cam.ac.uk
Mark Andrews
2009-01-25 23:24:41 UTC
Permalink
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: ***@isc.org
b***@anl.gov
2009-01-26 15:19:54 UTC
Permalink
I have not copied the entire thread.
Post by Matthew Pounsett
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: ***@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
Matus UHLAR - fantomas
2009-01-26 16:18:04 UTC
Permalink
Post by b***@anl.gov
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
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, ***@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
2009-01-26 17:50:45 UTC
Permalink
"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" <***@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"
Post by Matus UHLAR - fantomas
Post by b***@anl.gov
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
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."
--
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Danny Thomas
2009-01-26 21:43:24 UTC
Permalink
Post by Al Stu
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.
Post by Al Stu
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
2009-01-26 22:23:13 UTC
Permalink
--===============4925525664966038391==
Content-Type: multipart/alternative; boundary="=-2tljcVS5/krBADFDcDJK"


--=-2tljcVS5/krBADFDcDJK
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Post by Danny Thomas
Post by Al Stu
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.
Post by Danny Thomas
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><FONT COLOR="#8b6914"><I>Al Stu wrote:
&gt; So within the zone SMTP requirements are in fact met when the
&gt; MX RR is a CNAME.
you might argue the line of it being OK when additional processing
includes an A record.
</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#8b6914"><I>Possible courses of action
* disable the check-mx-cname in your config</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
</BODY>
</HTML>

--=-2tljcVS5/krBADFDcDJK--


--===============4925525664966038391==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Al Stu
2009-01-26 22:53:10 UTC
Permalink
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
Post by Al Stu
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><FONT face=3DArial size=3D2><EM><FONT face=3D"Times New Roman"=20
size=3D3></FONT></EM></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><EM><FONT face=3D"Times New Roman" =
size=3D3>"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</FONT><BR></EM><FONT size=3D3>Wow, such narrow =
mindedness.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2><EM>"<FONT face=3D"Times New Roman" =
size=3D3>I like=20
most I suspect stopped reading his rants days ago." - Noel=20
Butler</FONT></EM></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D3>And yet here you are continuing =
to=20
proliferate the thread.&nbsp; <STRONG>Thank =
you!</STRONG></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV></FONT>
<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"><B>From:</B>=20
<A title=***@ausics.net =
href=3D"mailto:***@ausics.net">Noel=20
Butler</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=***@its.uq.edu.au=20
href=3D"mailto:***@its.uq.edu.au">Danny Thomas</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <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"><B>Sent:</B> Monday, January 26, 2009 =
2:23=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: BIND 9.6 Flaw - =
CNAME vs. A=20
Record in MX Records are NOT "Illegal"</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>On Tue, 2009-01-27 =
at 07:43,=20
Danny Thomas wrote:=20
<BLOCKQUOTE TYPE=3D"CITE"><PRE><FONT color=3D#8b6914><I>Al Stu wrote:
&gt; So within the zone SMTP requirements are in fact met when the
&gt; MX RR is a CNAME.
you might argue the line of it being OK when additional processing
includes an A record.
</I></FONT></PRE></BLOCKQUOTE><BR>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.<BR><BR><BR>
<BLOCKQUOTE TYPE=3D"CITE"><PRE><FONT color=3D#8b6914><I>Possible =
courses of action
* disable the check-mx-cname in your =
config</I></FONT></PRE></BLOCKQUOTE><BR>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.<BR><BR>
<P>
<HR>

<P></P>_______________________________________________<BR>bind-users =
mailing=20
=
list<BR>bind-***@lists.isc.org<BR>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
Mark Andrews
2009-01-26 22:55:08 UTC
Permalink
Post by Matus UHLAR - fantomas
"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.
Post by Matus UHLAR - fantomas
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
Post by Matus UHLAR - fantomas
----- Original Message -----
Sent: Monday, January 26, 2009 8:18 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Matus UHLAR - fantomas
Post by b***@anl.gov
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
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."
--
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
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: ***@isc.org
Mark Andrews
2009-01-27 02:17:56 UTC
Permalink
How about these two?
nullmx.domainmanager.com
Name: mta.dewile.net
Address: 69.59.189.80
Aliases: nullmx.domainmanager.com
smtp.secureserver.net
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 -----
Sent: Monday, January 26, 2009 2:55 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Matus UHLAR - fantomas
"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.
Post by Matus UHLAR - fantomas
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
Post by Matus UHLAR - fantomas
----- Original Message -----
Sent: Monday, January 26, 2009 8:18 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Matus UHLAR - fantomas
Post by b***@anl.gov
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
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."
--
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a
Macintosh".
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
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: ***@isc.org
Scott Haneda
2009-01-27 02:24:06 UTC
Permalink
Post by Mark Andrews
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
Barry Margolin
2009-01-27 06:03:46 UTC
Permalink
Post by Scott Haneda
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, ***@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin
2009-01-27 06:11:53 UTC
Permalink
Post by Scott Haneda
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, ***@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Michael van Elst
2009-01-27 06:34:15 UTC
Permalink
Post by Barry Margolin
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: ***@serpens.de
"A potential Snark may lurk in every tree."
Barry Margolin
2009-01-28 04:48:36 UTC
Permalink
Post by Michael van Elst
Post by Barry Margolin
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, ***@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Scott Haneda
2009-01-27 06:26:03 UTC
Permalink
Post by Barry Margolin
Post by Scott Haneda
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 <b><p><i>sometext<p><b><i>

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
Scott Haneda
2009-01-27 06:30:10 UTC
Permalink
Post by Barry Margolin
Post by Scott Haneda
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.
--
Scott
David Ford
2009-01-27 07:27:09 UTC
Permalink
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.
Scott Haneda
2009-01-27 10:52:04 UTC
Permalink
Post by David Ford
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.
--
Scott
Al Stu
2009-01-27 03:54:00 UTC
Permalink
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" <***@newgeo.com>
To: "Mark Andrews" <***@isc.org>
Cc: "Al Stu" <***@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"
Post by Scott Haneda
Post by Mark Andrews
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
Scott Haneda
2009-01-27 04:09:15 UTC
Permalink
Post by Al Stu
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
Al Stu
2009-01-27 04:22:49 UTC
Permalink
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" <***@newgeo.com>
To: "Al Stu" <***@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"
Post by Scott Haneda
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
Mark Andrews
2009-01-27 04:41:02 UTC
Permalink
Post by Al Stu
"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
Post by Al Stu
----- Original Message -----
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Scott Haneda
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
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: ***@isc.org
Al Stu
2009-01-27 05:26:22 UTC
Permalink
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.


----- Original Message -----
From: "Mark Andrews" <***@isc.org>
To: "Al Stu" <***@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"
Post by Mark Andrews
Post by Al Stu
"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
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.
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
Post by Al Stu
----- Original Message -----
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Scott Haneda
Post by Al Stu
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
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
Barry Margolin
2009-01-27 06:16:26 UTC
Permalink
Post by Al Stu
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 ***@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.
Post by Al Stu
"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.
----- Original Message -----
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Mark Andrews
Post by Al Stu
"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
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.
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
Post by Al Stu
----- Original Message -----
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Scott Haneda
Post by Al Stu
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
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Mark Andrews
2009-01-27 06:03:11 UTC
Permalink
Post by Al Stu
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.
Post by Al Stu
"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.
Post by Al Stu
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.
Post by Al Stu
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 -----
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Mark Andrews
Post by Al Stu
"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
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
Post by Mark Andrews
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.
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
Post by Al Stu
----- Original Message -----
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Scott Haneda
Post by Al Stu
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
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
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: ***@isc.org
Al Stu
2009-01-27 06:34:00 UTC
Permalink
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" <***@isc.org>
To: "Al Stu" <***@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"
Post by Mark Andrews
How about these two?
nullmx.domainmanager.com
Name: mta.dewile.net
Address: 69.59.189.80
Aliases: nullmx.domainmanager.com
smtp.secureserver.net
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.
+norec
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21506
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;secureserver.net. IN MX
secureserver.net. 3600 IN MX 0 smtp.secureserver.net.
secureserver.net. 3600 IN NS cns2.secureserver.net.
secureserver.net. 3600 IN NS cns1.secureserver.net.
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 -----
Sent: Monday, January 26, 2009 2:55 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Matus UHLAR - fantomas
"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.
Post by Matus UHLAR - fantomas
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
Post by Matus UHLAR - fantomas
----- Original Message -----
Sent: Monday, January 26, 2009 8:18 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Matus UHLAR - fantomas
Post by b***@anl.gov
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
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."
--
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"The box said 'Requires Windows 95 or better', so I bought a
Macintosh".
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Mark Andrews
2009-01-27 06:35:42 UTC
Permalink
Post by Scott Haneda
Post by Barry Margolin
Post by Scott Haneda
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 <b><p><i>sometext<p><b><i>
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
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.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
Barry Margolin
2009-01-28 04:41:26 UTC
Permalink
Post by Mark Andrews
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, ***@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Mark Andrews
2009-01-27 09:46:00 UTC
Permalink
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 -----
Sent: Monday, January 26, 2009 10:03 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Mark Andrews
Post by Al Stu
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.
Post by Al Stu
"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.
Post by Al Stu
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.
Post by Al Stu
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 -----
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Mark Andrews
Post by Al Stu
"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
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
Post by Mark Andrews
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.
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
Post by Al Stu
----- Original Message -----
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Post by Scott Haneda
Post by Al Stu
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
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
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: ***@isc.org
Loading...