Thank you so much people. you rock!.
I have finally gone for two A records, but thanks to all of you I now
understand the pros and cons.
I apologise if I mislead you with the 'redirect' word, I really meant
to say that I wanted both de the domain and the www host to point to
the same ip.
On Wed, Sep 28, 2011 at 04:19:41PM +0200, feralert wrote:
...
The thing is that i want users redirected to 'www.domain.com' even
when they just type the domain name 'domain.com'.
In order to do so I am not sure if its best to have one A RR for each
or have an A RR for the domain and a CNAME RR
On 28/09/2011 21:02, Mark Elkins wrote:
On Wed, 2011-09-28 at 16:19 +0200, feralert wrote:
The thing is that i want users redirected to 'www.domain.com' even
when they just type the domain name 'domain.com'.
In order to do so I am not sure if its best to have one A RR for each
or have an A
Subject: RE: CNAME or A record?
All true, but if you don't have some sort of DNS record for both
example.com and www.example.com, then all the rewrite rules in the world
won't help.
For all we know, the web server doesn't care what the URL is since it is
the only site hosted on that server
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google I am asking you guys in
this list. Sorry if anyone thinks this a dumb question or something
very obvious.
The thing is that i want users redirected to 'www.domain.com' even
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of
feralert
Sent: Wednesday, September 28, 2011 10:20 AM
To: bind-us...@isc.org
Subject: CNAME or A record?
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google
Sent: Wednesday, September 28, 2011 10:20 AM
To: bind-us...@isc.org
Subject: CNAME or A record?
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google I am asking you guys in
this list. Sorry if anyone thinks this a dumb question
this is the stuff what should be done by webserver rather than by DNS. i,e,
Apache rewrite will do that.
在 2011-9-28 下午10:29，feralert feral...@gmail.com写道：
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google I am asking you
+jlightner=water@lists.isc.org [mailto:
bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of feralert
Sent: Wednesday, September 28, 2011 10:20 AM
To: bind-us...@isc.org
Subject: CNAME or A record?
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find
@lists.isc.org] On Behalf Of
feralert
Sent: Wednesday, September 28, 2011 10:20 AM
To: bind-us...@isc.org
Subject: CNAME or A record?
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google I am asking you guys in
this list
] On Behalf Of ??
Sent: Wednesday, September 28, 2011 10:43 AM
To: feralert
Cc: bind-us...@isc.org
Subject: Re: CNAME or A record?
this is the stuff what should be done by webserver rather than by DNS. i,e,
Apache rewrite will do that.
在 2011-9-28 下午10:29，feralert
feral...@gmail.commailto:feral
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-09-28 9:36 AM, feralert wrote:
Thanks Jeff,
But I really only wrote that as an example :) . The real question
is what is best or what is recommended, two A RR (one for domain,
one for www) or a single A RR for domain and a CNAME RR for
That makes no sense.
If he didn't have a dns entry for both sites, how does the user get to site
without the dns entry to be rewritten by Apache?
-Ben Croswell
On Sep 28, 2011 10:52 AM, 风河 short...@gmail.com wrote:
this is the stuff what should be done by webserver rather than by DNS.
i,e,
: bind-us...@isc.org; bind-users@lists.isc.org; Lightner, Jeff
Subject: Re: CNAME or A record?
Either is fine. Using the cname would require a single update if your ip
changes, but prevents other records at the same level. So you couldn't attach
mx for instance at example.comhttp://example.com
use a CNAME, you only need to handle the single A record
name in the server.
No, web server setup has nothing to do with CNAME or A record types.
(Unless a web server is directed to behave differently, but I don't
know why would anyone do that).
--
Matus UHLAR - fantomas, uh...@fantomas.sk
Of
feralert
Sent: Wednesday, September 28, 2011 10:20 AM
To: bind-us...@isc.org
Subject: CNAME or A record?
Hi all,
I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google I am asking you guys in
this list. Sorry if anyone thinks this a dumb
Webserver still has to get the request, so one way or the other is
required anyway :)
28.9.2011 17:43, ?? kirjoitti:
this is the stuff what should be done by webserver rather than by DNS.
i,e, Apache rewrite will do that.
? 2011-9-28 ??10:29,feralert feral...@gmail.com
On Wed Sep 28 2011 at 16:43:17 CEST, 风河 wrote:
this is the stuff what should be done by webserver rather than by DNS. i,e,
Apache rewrite will do that.
That is incorrect. DNS is needed to find the Web server. Web server
rewriting/configuration is needed to find the site.
-JP
On Wed, 2011-09-28 at 16:19 +0200, feralert wrote:
The thing is that i want users redirected to 'www.domain.com' even
when they just type the domain name 'domain.com'.
In order to do so I am not sure if its best to have one A RR for each
or have an A RR for the domain and a CNAME RR pointing
] On Behalf
Of ??
Sent: Wednesday, September 28, 2011 10:43 AM
To: feralert
Cc: bind-us...@isc.org
Subject: Re: CNAME or A record?
this is the stuff what should be done by webserver rather than by
DNS. i,e, Apache rewrite will do that.
在 2011-9-28 下午10:29，feralert feral...@gmail.com写道：
Hi all
Hey list,
I have the following issue. A customer hosts a domain with me,
facplus.com. Her primary email account is on that domain, we'll call
it h...@facplus.com. She has also registered another name through
Dotster, meetingtoolsandjewels.com. Dotster provides her with URL
redirection and email
Bradley Caricofe wrote:
Hey list,
I have the following issue. A customer hosts a domain with me,
facplus.com. Her primary email account is on that domain, we'll call
it her at facplus.com. She has also registered another name through
Dotster, meetingtoolsandjewels.com. Dotster provides her
At 09:35 19-08-2009, Bradley Caricofe wrote:
I have the following issue. A customer hosts a domain with me,
facplus.com. Her primary email account is on that domain, we'll call
it h...@facplus.com. She has also registered another name through
Dotster, meetingtoolsandjewels.com. Dotster provides
In message 8401908190935r6f7d622am9dd697317ec5...@mail.gmail.com, Bradley
Caricofe writes:
Hey list,
I have the following issue. A customer hosts a domain with me,
facplus.com. Her primary email account is on that domain, we'll call
it h...@facplus.com. She has also registered another
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 29 Jan 2009 22:33:24 -0800, Al Stu wrote:
Analyze this.
Query MX dns.com
Response MX nullmx.domainmanager.com
Query A nullmx.domainmanager.com
Response CNAME mta.dewile.net, A 64.40.103.249
So the fact that other random folks
David Sparks wrote:
There are plenty of ways to get a mail loop that don't involve DNS
mis-configuration. As such pretty much every major MTA detects and stops mail
loops.
Not if you (accidentally) fat-finger the MTA configuration. It is
completely possible to still mis-configure a MTA to
On 30.01.09 22:55, Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
called experts, only to be vindicated once the masses and so called experts
get their head out where the sun
@lists.isc.org
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
Illegal
Al Stu wrote:
History is fraught with individuals or a few being ridiculed for
putting forth that which goes against the conventional wisdom of the
masses and so called experts, only to be vindicated once
@lists.isc.org
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records
are NOT Illegal
Analyze this.
Query MX dns.com
Response MX nullmx.domainmanager.com
Query A nullmx.domainmanager.com
Response CNAME mta.dewile.net, A 64.40.103.249
See attached network trace
You just don't get it. You are off wandering around in the weeds.
Read the tail end of Chapter 5 in the book DNS and BIND describing the
MX selection algorithm in layman's terms to (perhaps) understand why
having MX records referencing CNAMEs is bad.
It may work right now for you, but
- CNAME vs. A Record in MX Records are NOT
Illegal
You just don't get it. You are off wandering around in the weeds.
Read the tail end of Chapter 5 in the book DNS and BIND describing the
MX selection algorithm in layman's terms to (perhaps) understand why
having MX records referencing CNAMEs
On Sat, 2009-01-31 at 16:55, Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
You don't get to speak for anyone else but yourself, just because you
believe in your own trolling,
Al Stu wrote:
History is fraught with individuals or a few being ridiculed for
putting forth that which goes against the conventional wisdom of the
masses and so called experts, only to be vindicated once the masses
and so called experts get their head out where the sun is shining and
exposed
On 27.01.09 10:18, Al Stu wrote:
I not only say it, I have demonstrated it.
But you have demonstrated something different than we're discussing all the
time.
BIND is the DNS system we are discussing.
Have not looked to see if that specifically is spec'ed in an RFC.
Yes other DNS
On Jan 26, 2009, at 11:27 PM, David Ford wrote:
hand because each line isn't strictly well-formed per RFC. If every
vendor was as utterly asinine about absolutist conformance, sure, we'd
have a lot less mess out there, but we'd have a lot less forward
movement as well as a lot more fractioning
:
The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com,
1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com.
*** PLEASE don't copy me on replies, I'll read them in the group ***
- Original Message -
From: Mark Andrews mark_andr...@isc.org
To: Al Stu
is a CNAME.
2) Get Target Host Address:
The A query for mx1.xyz.com delivers the address (A) record of
srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of
mx1.xyz.com.
They are two queries. If mx1 would be an A, it would be returned in the
first query. Since it's a CNAME
: 208.109.80.149
Aliases: smtp.secureserver.net
There are two reasons it does not blow up in peoples face. 1) If it is in
the CNAME RR points to an A record in the same zone, both the A record and
the CNAME record are returned, thus meeting the A record requirement. 2)
SMTP servers are required to accept
When Section 5.1 of RFC 5321 says If a CNAME record is found, the
resulting name is processed as if it were the initial name, it is
referring to the situation where a query is sent for the MX record for
xyz.com, and instead of an MX record being returned for xyz.com, a CNAME
record is returned
Target Host:
The MX query for xyz.com delivers mx1.xyz.com which is a CNAME.
2) Get Target Host Address:
The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com,
1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com.
*** PLEASE don't copy me on replies
In article glma06$8d...@sf1.isc.org,
Mark Andrews mark_andr...@isc.org wrote:
Liberal in what you accepts means don't die on arbitary
input. You should still reject rubbish.
But MX pointing to CNAME is not rubbish. It's a violation of the
letter of the spec, but it's very clear
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
mx1.xyz.com.
1) Select Target Host:
The MX query for xyz.com delivers mx1.xyz.com which is a CNAME.
2) Get Target Host Address:
The A query for mx1.xyz.com delivers the address (A) record of
srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of
mx1.xyz.com
mx1.xyz.com which is a CNAME.
2) Get Target Host Address:
The A query for mx1.xyz.com delivers the address (A) record of
srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of
mx1.xyz.com.
In article glnemv$10n...@sf1.isc.org,
Matus UHLAR - fantomas uh
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
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
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
On Tue, 2009-01-27 at 07:43, Danny Thomas wrote:
Al Stu wrote:
So within the zone SMTP requirements are in fact met when the
MX RR is a CNAME.
you might argue the line of it being OK when additional processing
includes an A record.
In all the time its taken him to type his rants and
are continuing to proliferate the thread. Thank you!
- Original Message -
From: Noel Butler
To: Danny Thomas
Cc: bind-users@lists.isc.org
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
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
: smtp.secureserver.net
There are two reasons it does not blow up in peoples face. 1) If it is in
the CNAME RR points to an A record in the same zone, both the A record and
the CNAME record are returned, thus meeting the A record requirement. 2)
SMTP servers are required to accept an alias and look it up. Thus
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
On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote:
Which just means you have not ever experienced the problems
causes. MTA are not required to look up the addresses of
all the mail exchangers in the MX RRset to process the MX
RRset. MTA usually learn their name
-users@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
On Jan 26, 2009, at 6:17 PM, Mark Andrews wrote:
Which just means you have not ever experienced the problems
causes. MTA are not required to look up
On Jan 26, 2009, at 7:54 PM, Al Stu wrote:
If you refuse a CNAME then it is your SMTP server that is broken.
The SMTP RFC's clearly state that SMTP servers are to accept and
lookup a CNAME.
[RFC974] explicitly states that MX records shall not point to an alias
defined by a CNAME. That
...@newgeo.com
To: Al Stu al_...@verizon.net
Cc: bind-users@lists.isc.org
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
Illegal
On Jan 26, 2009, at 7:54 PM, Al Stu wrote:
If you refuse a CNAME then it is your SMTP server that is broken
@lists.isc.org
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
Illegal
On Jan 26, 2009, at 7:54 PM, Al Stu wrote:
If you refuse a CNAME then it is your SMTP server that is broken. The
SMTP RFC's clearly state that SMTP servers
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
Illegal
In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes:
RFC 974:
There is one other special case. If the response contains an answer
which
is a CNAME RR, it indicates that REMOTE is actually an alias
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
change your CNAME record. And if
the outsourcing company re-IPs their server, they change the A record.
Everyone can perform their job without having to make any of the
downstream customers adjust their records.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me
returned. Thus meeting the SMTP
RFC requirements.
- Original Message -
From: Mark Andrews mark_andr...@isc.org
To: Al Stu al_...@verizon.net
Cc: bind-users@lists.isc.org
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records
On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote:
In article gllr91$2vq...@sf1.isc.org,
Scott Haneda talkli...@newgeo.com wrote:
100% right. I refuse MX's that are cnamed, and I get emails from
customers asking what is up. What is strange, and I can not figure
it
out, is that the admins
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
.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
In message bc7c01a4-1803-4906-bd90-93037b4ae...@newgeo.com, Scott Haneda writ
es:
On Jan 26, 2009, at 10:03 PM, Barry Margolin wrote:
In article gllr91$2vq...@sf1.isc.org,
Scott Haneda talkli...@newgeo.com wrote:
100% right. I refuse MX's that are cnamed, and I get emails from
., A or 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
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
At 00:44 25-01-2009, Al Stu wrote:
When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name.That domain name, when queried, MUST
return at least one address record (e.g., A or RR) that
On 25-Jan-2009, at 03:44 , Al Stu wrote:
When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name.That domain name, when queried, MUST
return at least one address record (e.g., A or
.
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
No I do not believe an extra step was added. Take the following example for
instance.
STMP server smtp.xyz.com. needs to send a message to some...@xyz.com. An MX
lookup is performed for domain xyz.com. and the domain name of mx.xyz.com is
returned. This is the first sentence:
When a
was replaced with srv1
3) server ip address was replaced with 1.2.3.4
Requirements are met.
- Original Message -
From: Matthew Pounsett m...@conundrum.com
To: Al Stu al_...@verizon.net
Cc: bind-users@lists.isc.org
Sent: Sunday, January 25, 2009 9:49 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs
On 25-Jan-2009, at 13:15 , Al Stu wrote:
Yes, blah was supposed to be srv1.
I do receive both the CNAME and A records for the A mx.xyz.com
query. See attached capture file.
In the capture file three global search and replacements were
performed to match the previous example.
1)
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 m...@conundrum.com
To: Al Stu al_...@verizon.net
Cc
Al Stu wrote:
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
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.
On Jan 25 2009, Chris Hills wrote:
Perhaps one day MX records can be deprecated entirely in favor of SRV.
Jabber got it right, and it would solve the e-mail server autodiscovery
problem for clients in a generic non-proprietary manner.
For example:- _smtp-server._tcp for servers,
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
In article gli8nu$ja...@sf1.isc.org,
Matthew Pounsett m...@conundrum.com wrote:
In the example above, when I query for IN A mx.xyz.com? I do not get
an address record back (A, )..instead I get a CNAME record.
Requirements NOT met.
Then there's something wrong with your resolver
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 ) - CNAME is not sufficient.
Some people seem to think RFC
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 ) - CNAME
Al Stu wrote:
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.
Some people seem to think RFC 974 creates a
82 matches
Mail list logo
