Forum Moderators: phranque
In setting up the IP address on the DNS servers (on the NetWork Solutions DNS server control panel), I'm given the choices of pointing the following variations of the domain name to selected IPs:
1) www.domain.com
2) @.domain.com
3) *.domain.com
I'm assuming that I should point both 1 and 2 to my IP address (and that if I omitted 2 I'd be in trouble); and then set the www version as the default in .htaccess. Is this correct?
No. 1 is the actual A record for the www.domain.com. So yeah, that should be pointed at the webserver.
No. 2 is the MX record - that should be pointed to the mail server IP (if you're running mail and web on one machine, that's cool too. but it should be the IP of the machine running a mail service)
No. 3 is a subdomain wildcard - I'd point that to the webserver too, if you ever intend to use subdomains.
Now, if you're moving a domain that's currently ranked for domain.com, and you want it to be ranked for www.domain.com, you should actually set up two different web profiles, and do a 301 redirect from domain.com to www.domain.com. Otherwise, your content will be mirrored on domain.com and www.domain.com instead of being "moved" in the SEs eyes.
Q: What are the first 3 hosts listed (www, @, *) in the table?
A: The first 3 hosts listed are the most common hosts used with domain names. The "www" host will point to the specified IP address when Internet users type in www.janesbagels.com. The "@" symbol will point to the specified IP address when someone types in just the domain name without anything before it, such as janesbagels.com. The "*" symbol points any unassociated host for a domain name to the specified IP address. This is similar to a "catch-all" feature that could be used for any misspelled host names that direct your site visitors to your Web site.
On the third one, "*", I don't understand what they mean by "unassociated host."
Now, if you're moving a domain that's currently ranked for domain.com, and you want it to be ranked for www.domain.com, you should actually set up two different web profiles, and do a 301 redirect from domain.com to www.domain.com.
Yes, I understand the perceived mirror problem and want to avoid it. This is what I referred to in my post where I planned to use mod_rewrite.
My question in part has to do with whether I could save the trouble of doing mod_rewrite and just have the site default to www, using option 1 only, or whether, if I didn't use option 2 as well, this would get me in trouble by not allowing the domain to redirect to the IP if someone left off the www.
When you use mod_rewrite (or maybe a 301 as you suggest) to make www the default, entering the domain either with or without www would take you to www.domain.com.
While we're at it, in the A record, should I put a slash at the end of .com? I'm assuming not.
The broader question, I suppose, is the interaction of the A Record and of the host server defaults.
The domain right now, incidentally, is just parked.
Remember, if a domain name (including subdomain) is not pointed to your server, then requests will never get there and mod_rewrite can have no effect.
So, you'll need at least the first two options, www- and non-www-
As bakedjake said, the third option is for wildcard subdomains. If you plan to have more subdomains in addition to "www", then select that one as well. You might want to have a "test" subdomain, for example. However, if you select this option, you will have to use the form of mod_rewrite domain redirection that catches all possible subdomains and redirects those that you aren't using to the main one - www or non-www. To be clear on that, you'd have to use the form with a negative RewriteCond pattern:
RewriteCond %{HTTP_HOST} [b]![/b]^www\.example\.com
RewriteRule (.*) http://www.example.com/$1 [R=301,L]
The other option -- If they support it, is to list out the subdomains you want to use one-by-one as A records. But from your description it sounds as if the "control panel" does not support this.
Also, because this is a "control panel" user-interface, I would not suggest adding a slash if their examples don't show it. In most manually-edited DNS zone files, you actually end the domain name with a period, but I suspect this control panel will take care of that for you, too; Just use whatever form they show in their examples.
Jim
w.yourdomain.com
ww.yourdomain.com
wwww.yourdomain.com
It's suprising how many people type the wrong amounts of 'w's when they type URLs.
Since I'll be using mod_rewrite anyway, it made sense to activate all three options and have them default to www, and I've done that (the third option takes care of any "w" typos etc before the domain). The Network Solutions tech I spoke with strongly agreed.
Re mod_rewrite, Jim says...
you'd have to use the form with a negative RewriteCond pattern:RewriteCond %{HTTP_HOST} [b]![/b]^www\.example\.com
RewriteRule (.*) http://www.example.com/$1 [R=301,L]
I see that he's bolded the exclamation point, so I will pay attention to that. ;)
I had planned to use mod_rewrite code that Jim had previously suggested elsewhere. In addition to the two lines of code before RewriteCond, I notice the lack of a space before the exclamation mark (which appears to be a WebmasterWorld auto-correction), and also ^ before (.*) and $ after. I don't know the syntax enough to understand the difference in functionality. Anyone care to elaborate?...
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST}!^www\.mydomain\.com
RewriteRule ^(.*)$ http://www.mydomain.com/$1 [R=301,L]
Also, does the "code" formatting not work in our quote tags?
^(.*)$ and (.*) standing alone as a pattern are equivalent; "*" is "greedy" and will match as many characters as possible, so the start and end anchors are not needed in this case.
Jim
I'm coming into another new area for me though... setting up subdomains and mail.domain.com, and doing so with the above scenario and the wildcard subdomain option. Please check me on this as I go through it...
...with the wildcard subdomain option selected, *any* subdomain of example.com will be pointed to your server, and it will be up to you to handle it.The other option -- If they support it, is to list out the subdomains you want to use one-by-one as A records. But from your description it sounds as if the "control panel" does not support this.
As I think I understand the above, if the subdomain is defined by an A-record, then the above code will leave it as set up. If it is not defined, the code will rewrite it to www.
The DNS control panel does give me the option to set up subdomains directly in the A records, and I gather this is the method of choice. (I don't understand C Names, and I see enough warnings on the board and on the DNS server that I think I should stay out of this area... but I gather these are another way of creating subdomains)
On the DNS control panel, the A-record entry format is:
_______.domain.com - followed by a field for the IP address.
For the mail subdomain, as I understand it, the IP address should be the mailserver IP address, and I need to point the MX Record for mail.domain.com to the mailserver IP address as well.
The Mail Server, MX Records panel gives only two fields per row... a "Priority" field, which defaults to 10, and a "Mail Server" field, clearly set up for words, not IP addresses, with Example:mail.your-domain.com. This, I assume, is what points the MX Record to the same IP as the A-Record.
There's an additional mail server option on the control panel, though, and I don't know whether it's redundant, or additional and possibly conflicting....
Next to the MailServer option, there's a link to an "add subdomain" option, which gives 3 entry fields in this format:
_______.domain.com - Priority - mailserver: mail.example.com
Is this...
a) for people who don't use the A-Record?
b) necessary in addition to the A-Record?
c) something that will possibly conflict with the A-Record if I use both?
Regarding my last post, above, I should add that it is not a safe assumption that Options +FollowSymLinks can be used just as insurance, as I posted above. That's an oversimplification, and I'll try to post the details on another thread when I have a chance.
I'll also have some questions about an ftp subdomain, as soon as I've pinned down some more details about how that might interact with the webserver hosting panel.
- On the question of whether, if the subdomain is defined by an A-record, the above mod_rewrite code will leave alone or rewrite it to "www"...
The above code will rewrite a subdomain to www.
The feedback I got tells me that "the action of the mod_rewrite code is completely separate from any action of the DNS system.... Nameservers only provide the translation of domain names to IP addresses, nothing else."
To get a subdomain to be returned with my DNS wildcard configuration and the above rewrite rule, I'm told I need to add exclusion conditions to the Rewrite, as in:
# Redirect all except www.domain.com,
RewriteCond %{HTTP_HOST}!^www\.domain\.com
# xyz.domain.com,
RewriteCond %{HTTP_HOST}!^xyz\.domain\.com
# and abc.domain.com
RewriteCond %{HTTP_HOST}!^abc\.domain\.com
RewriteRule (.*) http://www.domain.com [R=301,L] About the above code, I notice that the last line has been changed, and that /$1 no longer follows the url in the last line. I can speculate about this, but feedback would be helpful.
- On the question of whether I need to worry about whether mail.domain.com and ftp.domain.com being rewritten...
No... ".htaccess only applies to HTTP, not mail or FTP."
- With regard to what the "add subdomain" option next to the MailServer option...
I didn't get any responses that knew for sure what this option actually does... ie, whether the control panel (via the A-Record and the MX-Record in combo) will create a subdomain anyway, or whether it's a necessary additional step, or whether it's a step that will create some sort of a conflict.
This is the Network Solutions DNS control panel, just in case anyone has experience with it. I will be contacting their tech support... but my guess is I'll get an answer that is more to the point here.
That last line should be:
RewriteRule (.*) http://www.domain.com/$1 [R=301,L]
Jim
A further question about the treatment of mail.domain.com with regard to the following...
.htaccess only applies to HTTP, not mail or FTP....
...as it relates to the "add subdomain" option in the MX Records on the DNS control panel.
On another domain served by the same mailserver company, there's a "Novell Web Services" page that is served up, I assume, by the mail server (or the company that runs the mail server), when you type in the url:
http://mail.otherdomain.comI assume the http at the beginning of the url means that this page in fact accessed via HTTP. Might this in fact be the "subdomain" referred to in the "add subdomain" in the DNS control panel.
Wouldn't this effectively be a CNAME, as in the following from DNS Oversimplified: "One of the times where CNAME records can be useful is when you want a subdomain to point to a computer outside of your domain. For example, you might want "news.example.com to go to your ISP's newserver."
If so, would there need to be exclusion conditions for this subdomain in the .htaccess we've been discussing that's on the webserver?
I'm referring now to this page, which the mail server host would be expecting to appear when they type in either...
http://mail.otherdomain.comnot just to mail.otherdomain.com.
Hope this distinction is clear.
This may be at the core of what I'm not understanding about the subdomain issue. I suppose it would be ditto for ftp. Beyond the services, in other words, both serve up pages with http web addresses.
DNS and HTTP/.htaccess are two different systems which are completely different.
Lets say there is a webhost company with three machines:
alice.example.com, IP 192.168.0.1
bob.example.com, IP 192.168.0.2
charles.example.com, IP 192.168.0.3
These are fully qualified domain names (FQDNs). alice.example.com is a computer with the hostname alice in the example.com domain. Likewise, example.com can be thought of as a host called example in the com domain. Each host has one or more records in the DNS system. If there are no records for a FQDN, the DNS servers return the resource records for the wildcard host.
You purchase the domain name example.co.uk and you're using example.com's webhosting. They set up ANAME records in example.co.uk's DNS pointing www.example.co.uk at 192.168.0.1. alice.example.com also hosts tens of other peoples' web sites.
When a browser requests say, [example.co.uk...] the browser resolves www.example.co.uk to 192.168.0.1, makes an HTTP connection to that IP and sends the request. Now alice.example.com has to work out what page to return. The request the browser sent includes both the path (/about.html) and the host (www.example.co.uk). From this information, alice.example.com can send a reply. This might be a page, it might be an error message or a HTTP redirect. With .htaccess, this is the stage you control. You can point any FQDN you like (including the wildcard) at the server and configure it to respond differently to each name.
If the DNS doesn't resolve www.example.co.uk to 192.168.0.1, the configuration of the webserver on alice.example.com never comes into play. If the protocol is anything over than HTTP, it never comes into play.
alice.example.com may also run a mailserver and have the name mail.exaple.com pointing at 192.168.0.1. If you were to connect to [mail.example.com...] you would again connect to alice.example.com, since mail.example.com resolves to 192.168.0.1, and get a reply (the www in www.domain.tld is a convention, it's the http:// that says to use the HTTP protocol).
Now on to mail routing. When you sen a mail to user@example.com, where does the mail go? example.com will have a MX record in the DNS naming a mail exchanger that handles mail for that domain name. It might name mail.example.com. That name is then resolved to an IP address, and a SMTP connection made to the IP and the mail sent.
CNAMEs.
CNAMEs allow one to alias one FQDN to another. If example.com hosted their website on charles.example.com there are two ways they could make it accessible as www.example.com. One is to add a A record pointing www.example.com to 192.168.0.3. The second is using a CNAME, saying www.example.com is an alias for charles.example.com. Then charles.example.com can be resolved to the IP address.
If the webhost is hosting an anonymous FTP server for you on bob.example.com, and you wanted to call it ftp.example.co.uk, you could either add a CNAME aliasing ftp.example.co.uk to bob.example.com or an ANAME stating ftp.example.co.uk's IP address is 192.168.0.2.
In conclusion, hostnames like ftp..., www..., are conventions, nothing more. One server can have many names. HTTP allows the server to respond differently depending on what the client thinks it is called (virtual hosting).
Yes, my concern about somehow creating an http "mail" subdomain on the mail-server log-in page and thus requiring .htaccess was a pointless worry. The name points to the mail server and the webhost should never see the query. As py9jmas points out, these are simply conventions.
As for subdomains, for those whose understanding is even less perfect than mine (;)), the wildcard A-Record ( *.domain.com ) essentially enables all subdomains on the main IP if you exclude them from the rewrite.
I'm still not sure whether there's anything to be gained by also defining subdomains (as opposed to ftp and mail addresses) in the A-Records (you'd still have to use the rewrite exclusion in .htaccess), or whether that would be superfluous because of the wildcard.
A DNS wildcard could be, say, an A record pointing
*.company.comThe asterisk means that you can put anything (*) in as a subdoman and it will end up at the specified IP.
So, if you have a wildcard in your DNS, you can set up your subdomains on the server in stead. You don't need to set them up in the DNS. This is very practical, as you'll be able to set up subdomains quickly and control them on the server in stead of via the DNS system. (No propagating time, changes are immediate)
http //i.hate.the.lousy.company.com/It will show your front page, unless (1) your server config file, or (2) your .htaccess, or (3) some serverside script, or (4) a combination, is set up to return something else.
Doing this (setting up virtual hosts using .htaccess only) is only going to get the job done when the user agent "speaks"
HTTP/1.1For
HTTP/1.0HTTP_HOSTAnyway, if you can live with that, this WebmasterWorld thread has a few valuable comments (*) from andreasfriedfrich on the exact issue:
Uhm... "valuable comments" might be considered an understatement. That thread should answer it all.
I'm not quite sure how to deal with this issue. Some of these bots may have been modified to send out the right header information, but i think this is the simple reason for all the problems we constanly get reports about involving bots and redirects.
The only absolutely fool-proof solution is to get separate IPs for all your domains and subdomains too, but spiders simply have to deal with virtual hosts, so my best guess is that it will still work somehow, at least most of the time.
As I understand your post, I'd better not rely on mod_rewrite and wildcard DNS to create subdomains if I absolutely want bots to spider them. Re the thread you link to, it's mostly over my head, but conceivably doesn't affect what I'm doing.
- Will the code as posted in message #11 above, with the addition of /$1 as noted, work with the A-record setup discussed here (www, non-www, and wildcard to catch typos)? I'm willing to disregard whether the engines follow typo urls (one, two, or four "w"s) as long as the users can.
- If an A-record points to a subdomain (as with "www"), will the engines be able to follow it?
- Am I correct in assuming that the situation discussed in the "automatically routing subdomains" thread makes far more demands on mod_rewrite than the code that I'll be using, and I won't have to worry about recursion errors with the relatively simple code above?
I think you'll find that the search engines you'll want to be listed in will send the Host: header, regardless of whether they declare as HTTP/1.0 or HTTP/1.1. If this were not true, then you'd see massive problems with sites on shared-IP hosting, since the server would have no way of sorting out the requests to its various virtual servers if the user-agent did not send the Host: header. Half of the Web would be gone.
For completeness, it *is* always a good idea to write your mod_rewrite code to gracefully handle the situation where a genuine HTTP/1.0 client does not send a Host: header with the request -- For example, just steer all such requests to your "main domain" content directory structure. If a Luddite comes by using an old copy of Mosaic as a browser, you just serve the main (www) stuff. Of course, this only applies if you do have a unique IP address for your site; Otherwise, you'll never see genuine HTTP/1.0 requests anyway.
Jim
It is, don't worry. Jim's right, the important SE's knows how to handle this issue.
>> Will the code as posted in message #11 above (...) work
Yes... It says:
If domain is not equal to www.domain.comIf domain is not equal to xyx.domain.comIf domain is not equal to abc.domain.comThen rewrite to www.domain.comSo, what you have is a three-step condition: all three conditions must be met before the rule does anything. If this is what you want to do, then you're all set ;)
>> If an A-record points to a subdomain (...), will the engines be able to follow it?
I have never had any problems myself, but i can't really promise anything as i'm not a SE ;) If everything's set up properly i wouldn't worry about it.
>> Am I correct in assuming that the situation (.. ) makes far more demands on mod_rewrite
Yes. Still, mod_rewrite is very powerful. For most websites it will be no problem at all.
>> I won't have to worry about recursion errors
No, you shouldn't experience this using the code above.
