Folks,
Do inform your DNS administrators that they better do things
correctly, or email won't work. (Nor much else..)
Some people are telling around heretic information that it is
all right to use IP(v4) address literal TEXT in places which
are intended for NAMES.
As a result, the mind-set of "address is ok here" leads to nasty
surprises with $ORIGIN append rules, etc. See below and deduce
what is missing from the original zone file. Answer at the end.
As I got today two of these goofups in bounce reports, I decided
to write a bulletin to get your attention of wrong information
being floated around:
-- Lookup of MX/A for 'cyclades.com'
-> DNSreply: len=171 rcode=0 qd=1 an=1 ns=3 ar=3
-> 84802s MX[0] p=10 '209.81.55.2.cyclades.com'
-> getaddrinfo(INET, '209.81.55.2.cyclades.com','0') -> r=-5 (no address associated with name); ai=%p
-> No addresses for '209.81.55.2.cyclades.com'[0]
-> nmx=1 maxpref=66000 realname=''
=> NONE of MXes support SMTP!
-- Lookup of MX/A for 'gsl.kralupy.cz'
-> DNSreply: len=143 rcode=0 qd=1 an=1 ns=2 ar=2
-> 85291s MX[0] p=10 '194.213.206.70.kralupy.cz'
-> getaddrinfo(INET, '194.213.206.70.kralupy.cz','0') -> r=-2 (name or service is not known); ai=%p
-> No addresses for '194.213.206.70.kralupy.cz'[0]
-> nmx=1 maxpref=66000 realname=''
=> NONE of MXes support SMTP!
% dig mx cyclades.com
......
;; ANSWER SECTION:
cyclades.com. 1D IN MX 10 209.81.55.2.cyclades.com.
;; AUTHORITY SECTION:
cyclades.com. 1D IN NS 209.81.55.2.cyclades.com.
cyclades.com. 1D IN NS 209.81.59.2.cyclades.com.
cyclades.com. 1D IN NS 209.81.9.151.cyclades.com.
cyclades.com. 1D IN NS 200.230.227.66.cyclades.com.
......
% dig mx gsl.kralupy.cz
......
;; ANSWER SECTION:
gsl.kralupy.cz. 1D IN MX 10 194.213.206.70.kralupy.cz.
;; AUTHORITY SECTION:
kralupy.cz. 1D IN NS kpy01.kralupy.cz.
kralupy.cz. 1D IN NS sa.kra.cesnet.cz.
......
In case of cyclades.com the DNS administrator has made a double
mistake by listing IP addresses also in NS pointers -- while the usual
resolver codes use gethostbyname() (or getaddrinfo()), the DNS servers
are different animals alltogether.
The IPv4 address-LIKE data in MX records works mostly due to (an unhappy)
coincidence in the usual BSD/bind resolver libraries, where gethostbyname()
has also habit of parsing address literal to binary address.
NSes and MXes must ALWAYS point to NAMEs with A/AAAA/A6 records for
them, specifically those names MUST NOT be CNAMEs. With NSes the
proper glue resolving is even more important. The DNS servers won't
work quickly if they need to go fishing pointer data far and wide.
Indeed they will abandon the search quite soon if resolving needs
very deep recursions (more than 2-3 levels) for things like "to find
the NSes for zone X one looks up zone Y NSes, learns that they are
pointing to zone Z, looks it up and is delegated to zone W, now finding
Address of DNS server of Z, asking it, finding address of NS of Y,
asking there data for zone X ...
Now you think that nobody can be that stupid.
Unfortunately that is quite common.
Therefore (the thinking goes) having IP address literals in place of
Domain Names will short the resolving path, and yield quicker convergence.
Nice, but for NS pointers it doesn't matter what you put into your own
zone, only what is on the zone ABOVE yours will matter.
Always do suspect your own (email) DNS setup, stupidities like these
above are creeping around.
How VGER sees your DNS setup situation can be asked from web-page:
http://vger.kernel.org/mxverify.html
by giving your email address there.
Answer to the self-education question above:
The NAME fields in usual BIND systems get appended the current $ORIGIN
string value when the data in the field does not end with a dot:
Wrong: IN MX 10 11.22.33.44
"Right": IN MX 10 11.22.33.44.
The second appears at DNS lookup as "IN MX 10 11.22.33.44", which
is the intention aiming to use quite common misfeatures of system
libraries. THERE IS NO GUARANTEE OF IT WORKING AT NON-UNIX SYSTEMS!
Indeed there is no guarantee of it working at UNIX systems either!
/Matti Aarnio
Hello Matti ,
On Thu, 8 Feb 2001, Matti Aarnio wrote:
...snip...
> Answer to the self-education question above:
>
> The NAME fields in usual BIND systems get appended the current $ORIGIN
> string value when the data in the field does not end with a dot:
>
> Wrong: IN MX 10 11.22.33.44
> "Right": IN MX 10 11.22.33.44.
s/"Right"/Wrong/
(in the forward file)
Right: IN MX 10 mymail.mydomain.com.
Right:mymail.mydomain.com. IN A 11.22.33.44
(in a in-addr.arpa file)
Right:44 IN PTR mymail.mydomain.com.
> The second appears at DNS lookup as "IN MX 10 11.22.33.44", which
> is the intention aiming to use quite common misfeatures of system
> libraries. THERE IS NO GUARANTEE OF IT WORKING AT NON-UNIX SYSTEMS!
> Indeed there is no guarantee of it working at UNIX systems either!
True ! . Hth , JimL
+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+
[email protected] (Matti Aarnio) writes:
>NSes and MXes must ALWAYS point to NAMEs with A/AAAA/A6 records for
>them, specifically those names MUST NOT be CNAMEs. With NSes the
NS: must not
MX: should not
...stickler for details. ;-)
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Thanklfully bind 9 barfs if you even try this sort of thing.
Gerhard
On Thu, 8 Feb 2001, Henning P. Schmiedehausen wrote:
> [email protected] (Matti Aarnio) writes:
>
> >NSes and MXes must ALWAYS point to NAMEs with A/AAAA/A6 records for
> >them, specifically those names MUST NOT be CNAMEs. With NSes the
>
> NS: must not
> MX: should not
>
> ...stickler for details. ;-)
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
Followup to: <[email protected]>
By author: Gerhard Mack <[email protected]>
In newsgroup: linux.dev.kernel
>
> Thanklfully bind 9 barfs if you even try this sort of thing.
>
Personally I find it puzzling what's wrong with MX -> CNAME at all; it
seems like a useful setup without the pitfalls that either NS -> CNAME
or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
irreducible situations; CNAME -> CNAME would require a link maximum
count which could result in obscure breakage.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Gerhard Mack <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Thanklfully bind 9 barfs if you even try this sort of thing.
> >
> Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> seems like a useful setup without the pitfalls that either NS -> CNAME
> or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> irreducible situations; CNAME -> CNAME would require a link maximum
> count which could result in obscure breakage.)
It generally forces another DNS lookup. If you do a resolve on
a name of type=ANY it returns any MX records and A records. If you then
do a resolve on the MX records, you then get a CNAME and then have to
add an additional lookup for the CNAME. If you have a lot of MX records
and not all the servers are "up" that can add up to a significant
increase in DNS traffic.
> -hpa
> --
> <[email protected]> at work, <[email protected]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
"Michael H. Warfield" wrote:
>
> On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> > Followup to: <[email protected]>
> > By author: Gerhard Mack <[email protected]>
> > In newsgroup: linux.dev.kernel
> > >
> > > Thanklfully bind 9 barfs if you even try this sort of thing.
> > >
>
> > Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> > seems like a useful setup without the pitfalls that either NS -> CNAME
> > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> > irreducible situations; CNAME -> CNAME would require a link maximum
> > count which could result in obscure breakage.)
>
> It generally forces another DNS lookup. If you do a resolve on
> a name of type=ANY it returns any MX records and A records. If you then
> do a resolve on the MX records, you then get a CNAME and then have to
> add an additional lookup for the CNAME. If you have a lot of MX records
> and not all the servers are "up" that can add up to a significant
> increase in DNS traffic.
>
Wouldn't that be true for any CNAME anyway?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote:
> "Michael H. Warfield" wrote:
> >
> > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> > > Followup to: <[email protected]>
> > > By author: Gerhard Mack <[email protected]>
> > > In newsgroup: linux.dev.kernel
> > > >
> > > > Thanklfully bind 9 barfs if you even try this sort of thing.
> > > >
> >
> > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> > > seems like a useful setup without the pitfalls that either NS -> CNAME
> > > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> > > irreducible situations; CNAME -> CNAME would require a link maximum
> > > count which could result in obscure breakage.)
> >
> > It generally forces another DNS lookup. If you do a resolve on
> > a name of type=ANY it returns any MX records and A records. If you then
> > do a resolve on the MX records, you then get a CNAME and then have to
> > add an additional lookup for the CNAME. If you have a lot of MX records
> > and not all the servers are "up" that can add up to a significant
> > increase in DNS traffic.
> >
> Wouldn't that be true for any CNAME anyway?
That's the point...
In other words, you do a lookup, you start with a primary lookup
and then possibly a second lookup to resolve an MX or CNAME. It's only
the MX that points to a CNAME that results in yet another lookup. An
MX pointing to a CNAME is almost (almost, but not quite) as bad as a
CNAME pointing to a CNAME.
> -hpa
> --
> <[email protected]> at work, <[email protected]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
>
> > Wouldn't that be true for any CNAME anyway?
>
> That's the point...
>
> In other words, you do a lookup, you start with a primary lookup
> and then possibly a second lookup to resolve an MX or CNAME. It's only
> the MX that points to a CNAME that results in yet another lookup. An
> MX pointing to a CNAME is almost (almost, but not quite) as bad as a
> CNAME pointing to a CNAME.
>
There is no reducibility problem for MX -> CNAME, unlike the CNAME ->
CNAME case.
Please explain how there is any different between an CNAME or MX pointing
to an A record in a different SOA versus an MX pointing to a CNAME
pointing to an A record where at least one pair is local (same SOA).
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote:
> > > Wouldn't that be true for any CNAME anyway?
> > That's the point...
> > In other words, you do a lookup, you start with a primary lookup
> > and then possibly a second lookup to resolve an MX or CNAME. It's only
> > the MX that points to a CNAME that results in yet another lookup. An
> > MX pointing to a CNAME is almost (almost, but not quite) as bad as a
> > CNAME pointing to a CNAME.
> There is no reducibility problem for MX -> CNAME, unlike the CNAME ->
> CNAME case.
> Please explain how there is any different between an CNAME or MX pointing
> to an A record in a different SOA versus an MX pointing to a CNAME
> pointing to an A record where at least one pair is local (same SOA).
Ah! But now you are placing conditions on it (that at least one
pair is local). That is the very fine distinction that makes up the
"not quite" in the "almost" above and the difference between the "should
not" vs the "must not" in the specifications. You basically can't qualify
it by saying "you can do this, but only if one pair is in the same SOA".
> -hpa
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
"Michael H. Warfield" wrote:
>
> > Please explain how there is any different between an CNAME or MX pointing
> > to an A record in a different SOA versus an MX pointing to a CNAME
> > pointing to an A record where at least one pair is local (same SOA).
>
> Ah! But now you are placing conditions on it (that at least one
> pair is local). That is the very fine distinction that makes up the
> "not quite" in the "almost" above and the difference between the "should
> not" vs the "must not" in the specifications. You basically can't qualify
> it by saying "you can do this, but only if one pair is in the same SOA".
>
No. My point is that potential for inefficiency is not a valid reason
for banning something outright. This should be an administrative
decision, nothing more.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote:
> "Michael H. Warfield" wrote:
> >
> > > Please explain how there is any different between an CNAME or MX pointing
> > > to an A record in a different SOA versus an MX pointing to a CNAME
> > > pointing to an A record where at least one pair is local (same SOA).
> >
> > Ah! But now you are placing conditions on it (that at least one
> > pair is local). That is the very fine distinction that makes up the
> > "not quite" in the "almost" above and the difference between the "should
> > not" vs the "must not" in the specifications. You basically can't qualify
> > it by saying "you can do this, but only if one pair is in the same SOA".
> No. My point is that potential for inefficiency is not a valid reason
> for banning something outright. This should be an administrative
> decision, nothing more.
But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME
is a "should not". The "should not" leaves it to be implimentation
dependent and not an outright ban. Sooo...
I personally have no problem with Bind 9.x prohibiting an
MX -> CNAME, but that's an implimentation issue.
In case people have tuned in late, there have been some rather
radical swings in Bind policy since Bind 4.x.
Bind 8.x decided to ENFORCE (with a vengence) the character set
policies dictated by RFC. This was (so they claimed) to protect poorly
coded programs that were prone to blowing chunks and doing Chernobyl
imitations on getting illegal characters in host names. Of course that
also caused zones with underscores in names (more common than what you
would think) to crap all over themselves when unsuspecting (i.e. failure
to read warnings) admins upgraded.
Bind 9.0 went back to the old 4.9 policy on characters (allow
what can be entered and poorly coded programs are on their own) but started
enforcing a requirement for a TTL directive and making the SOA TTL field
the true minimum TTL that it was defined as (instead of a default like
Bind 8 and 4 and previous used it as). I figured I was all set, since I,
of course, had upgraded all MY zone files already. Imagine my surprise
when 9.0 would not even load because OVER HALF of the 200+ zones I'm
responsible for or host did NOT have the $TTL directive! It was assholes
and elbows for a not so brief but really intense time while I updated those
$@$%#@ zone files!
You don't like the Bind enforcement of the DNS policy, bitch to
the ISC bunch. They can be swayed (all too often, it appears). If enough
DNS administrators really want to go against the "should not", maybe
they will make it configurable (Actually, I didn't think it really outright
prohibited it in the first place, but... Oh well...) There are lots
of other things in the DNS that need to be killed DEAD with a stake
through the heart like CNAME with other data (what is THAT suppose to
mean). I run into lookups on sites with CNAMES and A records for a host!
I suppose one can come up with a hierachial reason for doing such
byzantine things, but do you REALLY want to? In applying the KISS
principle (admitedly an oxymoron when it comes to DNS) I can see some
people wanting to ban MX -> CNAME in general if, for no other reason,
than to insure that you will do it only if you have really STRONG
reasons for doing it.
> -hpa
> --
> <[email protected]> at work, <[email protected]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Thu, Feb 08, 2001, Michael H. Warfield <[email protected]> wrote:
> But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME
> is a "should not". The "should not" leaves it to be implimentation
> dependent and not an outright ban. Sooo...
Actually, I had this conversation recently. I checked a variety of
places and I couldn't find an RFC that said CNAME -> CNAME is a "must
not". In fact I found this snippet in rfc1912 which seems to imply that
it is legal:
Also, having chained records such as CNAMEs pointing to CNAMEs may
make administration issues easier, but is known to tickle bugs in
some resolvers that fail to check loops correctly. As a result some
hosts may not be able to resolve such names.
*shrug*
JE
Michael H. Warfield <[email protected]> wrote:
> But, wait a minute. CNAME -> CNAME is a "must not".
Cite the RFC please. 1034 says
# Domain names in RRs which point at another name should always point at
# the primary name and not the alias.
and
# domain software should not fail when presented with CNAME
# chains or loops; CNAME chains should be followed and CNAME loops
# signalled as an error.
and
# - The answer to the query, possibly preface by one or more CNAME
# RRs that specify aliases encountered on the way to an answer.
and
# Multiple levels of
# aliases should be avoided due to their lack of efficiency, but should
# not be signalled as an error.
It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal.
--
Aaron Denney
-><-
On Fri, Feb 09, 2001 at 01:50:04AM +0000, Aaron Denney wrote:
> Michael H. Warfield <[email protected]> wrote:
> > But, wait a minute. CNAME -> CNAME is a "must not".
> Cite the RFC please. 1034 says
> # Domain names in RRs which point at another name should always point at
> # the primary name and not the alias.
> and
> # domain software should not fail when presented with CNAME
> # chains or loops; CNAME chains should be followed and CNAME loops
> # signalled as an error.
> and
> # - The answer to the query, possibly preface by one or more CNAME
> # RRs that specify aliases encountered on the way to an answer.
> and
> # Multiple levels of
> # aliases should be avoided due to their lack of efficiency, but should
> # not be signalled as an error.
> It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal.
Hmmm... Looks like I have had that just about backwards (par for
the course). RFC 1912 (Common DNS Errors) makes it pretty clear that
other RRs should not point at CNAMEs and that would include CNAMEs
pointing at CNAMEs. It quotes your same section, 3.6.2, of rfc 1034
for justifying that.
] Don't use CNAMEs in combination with RRs which point to other names
] like MX, CNAME, PTR and NS. (PTR is an exception if you want to
] implement classless in-addr delegation.) For example, this is
] strongly discouraged:
]
] podunk.xx. IN MX mailhost
] mailhost IN CNAME mary
] mary IN A 1.2.3.4
]
] [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
] 974] explicitly states that MX records shall not point to an alias
] defined by a CNAME. This results in unnecessary indirection in
] accessing the data, and DNS resolvers and servers need to work more
] to get the answer. If you really want to do this, you can accomplish
] the same thing by using a preprocessor such as m4 on your host files.
That pretty explicity states that MX records should not (and,
according to RFC 974, must not) point to CNAMES.
] Also, having chained records such as CNAMEs pointing to CNAMEs may
] make administration issues easier, but is known to tickle bugs in
] some resolvers that fail to check loops correctly. As a result some
] hosts may not be able to resolve such names.
That's a pretty strong recommendation to NOT point CNAMEs to
CNAMEs. It's not a "must not", but it points out a seeming ambiguity in
RFC 1034. The very passage you quote:
> # Domain names in RRs which point at another name should always point at
> # the primary name and not the alias.
Doesn't that say that a domain name in a RR should always point
at the primary name. Doesn't that imply (and thus semi contradict the
rest of that section about loops) that CNAMEs should not point to CNAMEs?
That would appear to make rfc 1034 look ambiguous. Section
3.6.2 says that RRs should always point to primary names but then
goes on to discuss CNAME loops and states that multiple levels of
aliases should not be signaled as an error.
But then we are down to semantics and the semantics of the RFCs
are defined. Should and should not are recommendations, not requirements.
Must and must not are requirements. On that point, I must cede the field
and admit that both CNAME -> MX and CNAME -> CNAME would appear to fall
under the former and not the later. But MX -> CNAME would appear to be
explicitly prohibited under RFC 974.
> --
> Aaron Denney
> -><-
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Gerhard Mack <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Thanklfully bind 9 barfs if you even try this sort of thing.
> >
>
> Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> seems like a useful setup without the pitfalls that either NS -> CNAME
> or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> irreducible situations; CNAME -> CNAME would require a link maximum
> count which could result in obscure breakage.)
>
> -hpa
There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's.
Regards
Jan Gyselinck
[email protected] (Jan Gyselinck) writes:
>There's not really something wrong with MX's pointing to CNAME's. It's just that some mailservers could (can?) not handle this. So if you want to be able to receive mail from all kinds of mailservers, don't use CNAME's for MX's.
No. It breaks a basic assumption set in stone in RFC821. It has
nothing to do with mailer software.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
[email protected] (H. Peter Anvin) writes:
>> In other words, you do a lookup, you start with a primary lookup
>> and then possibly a second lookup to resolve an MX or CNAME. It's only
>> the MX that points to a CNAME that results in yet another lookup. An
>> MX pointing to a CNAME is almost (almost, but not quite) as bad as a
>> CNAME pointing to a CNAME.
>>
>There is no reducibility problem for MX -> CNAME, unlike the CNAME ->
>CNAME case.
>Please explain how there is any different between an CNAME or MX pointing
>to an A record in a different SOA versus an MX pointing to a CNAME
>pointing to an A record where at least one pair is local (same SOA).
CNAME is the "canonical name" of a host. Not an alias. There is good
decriptions for the problem with this in the bat book. Basically it
breaks if your mailer expects one host on the other side (mail.foo.org)
and suddently the host reports as mail.bar.org). The sender is
allowed to assume that the name reported after the "220" greeting
matches the name in the MX. This is impossible with a CNAME:
mail.foo.org. IN A 1.2.3.4
mail.bar.org. IN CNAME mail.foo.org.
bar.org. IN MX 10 mail.bar.org.
% telnet mail.bar.org smtp
220 mail.foo.org ESMTP ready
^^^^^^^^^^^^
This kills loop detection. Yes, it is done this way =%-) and it breaks
if done wrong.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
"Henning P. Schmiedehausen" <[email protected]> writes:
> [email protected] (H. Peter Anvin) writes:
>
> >> In other words, you do a lookup, you start with a primary lookup
> >> and then possibly a second lookup to resolve an MX or CNAME. It's only
> >> the MX that points to a CNAME that results in yet another lookup. An
> >> MX pointing to a CNAME is almost (almost, but not quite) as bad as a
> >> CNAME pointing to a CNAME.
> >>
>
> >There is no reducibility problem for MX -> CNAME, unlike the CNAME ->
> >CNAME case.
>
> >Please explain how there is any different between an CNAME or MX pointing
> >to an A record in a different SOA versus an MX pointing to a CNAME
> >pointing to an A record where at least one pair is local (same SOA).
>
> CNAME is the "canonical name" of a host. Not an alias. There is good
> decriptions for the problem with this in the bat book. Basically it
> breaks if your mailer expects one host on the other side (mail.foo.org)
> and suddently the host reports as mail.bar.org). The sender is
> allowed to assume that the name reported after the "220" greeting
> matches the name in the MX. This is impossible with a CNAME:
>
> mail.foo.org. IN A 1.2.3.4
> mail.bar.org. IN CNAME mail.foo.org.
> bar.org. IN MX 10 mail.bar.org.
>
> % telnet mail.bar.org smtp
> 220 mail.foo.org ESMTP ready
> ^^^^^^^^^^^^
>
> This kills loop detection. Yes, it is done this way =%-) and it breaks
> if done wrong.
This is humour, yeh ?
I would be supprised if even sendmail assumed braindamage like the
above.
For instance something that is pretty common is...
foo.example.com. IN A 4.4.4.4
foo.example.com. IN MX 10 mail.example.com.
foo.example.com. IN MX 20 backup-mx1.example.com.
; This is really mail.example.org.
backup-mx1.example.com. IN A 1.2.3.4
...another is to have "farms" of mail servers (the A record for the MX
has multiple entries).
If it "broke" as you said, then a lot of mail wouldn't be being routed.
--
# James Antill -- [email protected]
:0:
* ^From: .*james@and\.org
/dev/null
[email protected] (Henning P. Schmiedehausen) wrote on 12.02.01 in <[email protected]>:
> [email protected] (Jan Gyselinck) writes:
>
> >There's not really something wrong with MX's pointing to CNAME's. It's
> >just that some mailservers could (can?) not handle this. So if you want to
> >be able to receive mail from all kinds of mailservers, don't use CNAME's
> >for MX's.
>
> No. It breaks a basic assumption set in stone in RFC821. It has
> nothing to do with mailer software.
May I point out that RFC 821 does not mention either CNAME or MX anywhere.
The successor (which is currently finished and waiting for publication as
RFC 2821) mentions both, but does not say if MX->CNAME is allowed or
forbidden. (And it says it's tightened up from RFC 974.)
Incidentally, it's also silent on the name vs. address MX question.
Looking at 974 and RFCs referenced from there might help to find
ammunition. But note that this is significantly later than 821.
So don't tell us about stuff set in stone in RFC XYZ, when it's plain
you've never looked at that RFC.
MfG Kai
[email protected] (James Antill) writes:
>"Henning P. Schmiedehausen" <[email protected]> writes:
>> % telnet mail.bar.org smtp
>> 220 mail.foo.org ESMTP ready
>> ^^^^^^^^^^^^
>>
>> This kills loop detection. Yes, it is done this way =%-) and it breaks
>> if done wrong.
> This is humour, yeh ?
No.
> I would be supprised if even sendmail assumed braindamage like the
>above.
> For instance something that is pretty common is...
>foo.example.com. IN A 4.4.4.4
>foo.example.com. IN MX 10 mail.example.com.
>foo.example.com. IN MX 20 backup-mx1.example.com.
>; This is really mail.example.org.
>backup-mx1.example.com. IN A 1.2.3.4
No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far
as I know, nothing has superseded it yet. And Section 3.7 states
clearly:
Whenever domain names are used in SMTP only the official names are
used, the use of nicknames or aliases is not allowed.
And the 220 Message is defined as
220 <domain>
On sendmail, this is enforced by the "k" flag in the mailer definition.
>...another is to have "farms" of mail servers (the A record for the MX
>has multiple entries).
> If it "broke" as you said, then a lot of mail wouldn't be being routed.
You're correct. A lot of mail isn't routed or just routed because the
mailers believe in the "be liberal in what you accept" policy. Or
plainly non-RFC-compliant.
There is a concept behind CNAMEs just like behind IP Fragmentation and
the NT domains. Noone stated that it is a _SANE_ concept but it is now
here and we have to live with it. CNAMES ARE NOT ALIASES.
A CNAME is a reference. It states "the canonical name of "xxxx" is
podunk.org". You write it as
xxx IN CNAME podunk.org.
SMTP requests that you use the canonical name in the 220 greeting,
according to RFC 821. Everything else is misconfiguration.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
[email protected] (Kai Henningsen) writes:
>[email protected] (Henning P. Schmiedehausen) wrote on 12.02.01 in <[email protected]>:
>> [email protected] (Jan Gyselinck) writes:
>>
>> >There's not really something wrong with MX's pointing to CNAME's. It's
>> >just that some mailservers could (can?) not handle this. So if you want to
>> >be able to receive mail from all kinds of mailservers, don't use CNAME's
>> >for MX's.
>>
>> No. It breaks a basic assumption set in stone in RFC821. It has
>> nothing to do with mailer software.
>May I point out that RFC 821 does not mention either CNAME or MX anywhere.
RFC 974 is about the "DOMAIN NAME SYSTEM". RFC 821 mentions DOMAINS:
3.7. DOMAINS
>So don't tell us about stuff set in stone in RFC XYZ, when it's plain
>you've never looked at that RFC.
Says who? RFC974 is a clarification of how to interpret Domain Name
System contents in a mail context. RFC821 makes a clear statement about
Domains in section 3.7:
[...]
Whenever domain names are used in SMTP only the official names are
used, the use of nicknames or aliases is not allowed.
[...]
and in RFC974 it is stated:
[...]
In addition to mail information, the servers store certain other
types of RR's which mailers may encounter or choose to use. These
are: the canonical name (CNAME) RR, which simply states that the
domain name queried for is actually an alias for another domain name,
which is the proper, or canonical, name; [...]
[...]
In my understanding (and I assume that you're familiar with both as
you've chosen to insult me by suggesting that I've not read this
stuff), this means clearly:
"YOU MUST NOT USE AN ALIAS WHENEVER DOMAINS ARE USED IN SMTP". (RFC821)
and
"THIS NAME IS AN ALIAS FOR ANOTHER DOMAIN NAME, WHICH IS THE PROPER,
CANONICAL NAME".
This boils down for me to
"YOU MUST NOT USE A CNAME ANYWHERE IN SMTP".
and "ANYWHERE" also states for me "in the 220 greeting".
Any further questions?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
"Henning P. Schmiedehausen" <[email protected]> writes:
> [email protected] (James Antill) writes:
>
> >"Henning P. Schmiedehausen" <[email protected]> writes:
>
> >> % telnet mail.bar.org smtp
> >> 220 mail.foo.org ESMTP ready
> >> ^^^^^^^^^^^^
> >>
> >> This kills loop detection. Yes, it is done this way =%-) and it breaks
> >> if done wrong.
>
> > This is humour, yeh ?
>
> No.
This was a comment on the "loop detection" claim.
[snip ... domain example]
> No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far
> as I know, nothing has superseded it yet. And Section 3.7 states
> clearly:
>
> Whenever domain names are used in SMTP only the official names are
> used, the use of nicknames or aliases is not allowed.
_In_ SMTP, that doesn't say anything about MX records to me and even
if it does it's very old and needs to change.
> And the 220 Message is defined as
>
> 220 <domain>
So... you should have the reverse for the ip address after the
220. Which most people do (but not all, mainly due to there not being
enough ips).
[snip CNAME lesson]
The question was, why can't you use CNAMEs. You said 'because of loop
detection'. I said 'But that doesn't work anyway, because you can have
to names pointing at one machine without a CNAME record ... and that
needs to, and currently does, work'.
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Let me put it this way...
tanstaafl.de. IN MX 50 mail.hometree.net.
tanstaafl.de. IN MX 10 mail.intermeta.de.
intermeta.de. IN MX 50 mail.hometree.net.
intermeta.de. IN MX 10 mail.intermeta.de.
mail.hometree.net. IN A 194.231.17.49
mail.intermeta.de. IN A 212.34.181.3
49.17.231.194.in-addr.arpa. IN PTR limes.hometree.net.
3.181.34.212.in-addr.arpa. IN PTR babsi.intermeta.de.
--
# James Antill -- [email protected]
:0:
* ^From: .*james@and\.org
/dev/null