Wildcard DNS - default domain
scedwar - August 10, 2008 - 12:29
| Project: | Domain Access |
| Version: | 5.x-1.6 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
My understanding of configuring Wildcard DNS allows the Domain module to handle which domains are valid. However, an invalid domain (e.g. a misspelling) results in an alias of the default domain rather than a redirect?
If so, this increases the chances of made up/bad spellings getting out into crawler land and causing your site to basically be searched "number of names" x "number of pages" times for the exact same content. Is there a way to configure domain to do a redirect to so that non-approved *.domain.com names get mapped to a "this site isn't here" page rather than being a duplicate copy of something else?
Or have I got things muddled up?
Thanks, Stephen
#1
I see, there is a difference between how we handle non-existent domains vs. 'inactive' domains.
For registered but inactive domains, it is a hard redirect, the spider should register the resulting page as the root domain, not the misspelled domain.
The code implementation is in domain_init():
// For Domain User, we check the validity of accounts, so the 'valid' flag must be TRUE.// If this check fails, we send users to the default site homepage.
if (!$_domain['valid'] && !user_access('administer domains')) {
$_domain = domain_default();
drupal_goto($_domain['path']);
}
This means the requests for inactive.example.com will be redirected to example.com, not simply masked.
But for misspellings and so forth, the logic is a silent adjustment:
// If return is -1, then the DNS didn't match anything, so use defaults.if ($_domain == -1) {
$_domain = domain_default();
}
So these two routines should probably be collapsed.
#2
I agree, this would solve the problem of duplicate content/crawlers.
However, I wonder if it might be preferable to make the redirect in the second case configurable, such that domains that don't exist return an error to the user, perhaps a 404 on the default domain, or a redirection to a particular landing page? If misspellings still successfully direct to the default domain there is no warning to a user that they have misspelt the sub domain, allowing users to create links to the site that appear to work, but don't. For example, www.mydomain.com and ww.mydomain.com and w.mydomain.com would all be valid links to your default domain.
#3
I think you should handle that at the server level. It is a limitation of wildcard DNS.
#4
Here is a patch for testing. If the domain request is not for the primary domain, and not registered, we redirect and set a message.
#5
Committed to HEAD.
#6
And to 5.x
#7
I haven't had chance to test this yet, but I'm happy if you are!
#8
A test would be nice -- I have a lot of patches that do not get proper testing, which drives me crazy.
The big issue is probably the error message, which is currently:
drupal_set_message(t('You have followed an incorrect link to this website. Please update your links and bookmarks to <a href="!url">!url</a>.', array('!url' => $request)));#9
Patch breaks the module for new installs.
See #300311: Fresh installation causing nasty problems
#10
Fixed in 5.x.1.7 and 6.x.1.1
#11
This approach has caused issues for me. On my site, users have to authenticate using SSL. The domain of the SSL cert is different from the site's default domain. So, if the site is www.example.com, and the SSL requests are redirected to secure.example.com, this new feature creates a redirect loop between www.example.com and secure.example.com, unless I were to create a domain for secure.example.com via the domain access module (which is a bit of a pain, since all the Drupal settings of www.example.com do not automatically carry over).
I just commented out the lines in the module that do this. Of course, a fix could be to obtain an SSL certificate for www.example.com. But, this type of redirecting really seems like the sort of thing that should be able to be turned on or off without adjusting the code. Anyone care to share some insight?
#12
I think you should post that in a different issue, since this patch addressed a specific use-case, which you are contradicting.
#13
Thanks for the suggestion. However, this patch directly caused the issue that I experienced, so I felt it was an appropriate post. If nothing else, admins who experience the same issue may find this thread and be able to more easily understand/correct their redirect problems.
My suggestion was that this redirect feature should be an option in Domain's admin page, rather than hard-coded. This feature will work fine for some cases, others it will not. As mentioned, it is a specific use-case and many set-ups may contradict it.
#14
Actually, re-reading the original post, I don't follow this part:
unless I were to create a domain for secure.example.com via the domain access module (which is a bit of a pain, since all the Drupal settings of www.example.com do not automatically carry over).Um, yes they do, unless you reset some of them deliberately using Domain Conf.
#15
That has not been my experience when creating new sub-domains with the Domain module. New sub-domains look like a default Drupal install, but with the node content of the original domain. No settings (mission statement, for example) carry over to the new domain. This is a big part of why the Wildcard DNS redirect is an issue for me.
#16
In #14, I am assuming that example.com is your primary domain, which is the root Drupal install from which all subsequent domains inherit their settings.
#17
Yes, example.com in #14 is the primary domain from which all subsequent domains should inherit their settings. Is there perhaps a setting somewhere that may be keeping the settings from being inherited?
#18
The only things that should interfere with settings inheritance -- and here I mean site footer, mission statement, and so on -- are:
1) Domain-specific overrides set through Domain Conf.
2) Manual $conf overrides that you placed in settings.php.
3) Having more than one settings directory.
#19
Hmm. I do not believe I am seeing expected (or at least desired) behavior with this under 1.8 etc. Posting here vs. http://drupal.org/node/304515 or separate thread.
We have a multisite install using D5.10 and several multidomain installs under it.
In some cases, these involve subdomain.example.com being a separate site, or being a multisite install shared with example2.com.
In these instances, while set up correctly under Drupal rules (folders/setting.php), and sometimes (where appropriate) domain access, subdomain.example.com will redirect to example.com-- even when domain access is not enabled for that domain/site. www.exampleN.com redirects to exampleN.com, with domain access not enabled for those sites-- a most undesired behavior since we normally redirect exampleN.com to www.exampleN.com.
I did not attempt to diagnose situations where subdomains registered in DA redirected to the main domain; reverted.
Will review code; this may be solved by simply insuring that www.exampleN.com is always registered and never exampleN.com. This, however, means chasing down all sites where DA is enabled.
A suggestion, not necessarily for here: from a security standpoint, sites directory should be parsed before any contrib hooks.
#20
"sites directory should be parsed before any contrib hooks."
I believe that it is, in all cases. There is nothing in DA that can fire before settings files are loaded. See bootstrap.inc.
Testing the Domain Alias patch would be very helpful.
#21
Automatically closed -- issue fixed for two weeks with no activity.