New answers tagged

0

If you don't want to reveal your public IP you can't have any DNS recording pointing to it. Sounds like you set up an A record, which isn't required, you just needed an MX record. Suggest you remove the A record and sign up for hosted email, Google or FastMail are good options, but there are plenty. Point your MX record at the hosted email, and set up SPF as ...


0

The only requirement for incoming email is that you have an MX record that is an A record. That MX record could be any hostname, and it doesn't even have to be a subdomain of your domain. So, there's no problem with using abc.example.com. With regard to the website showing when accessed by mail.example.com, that really depends on how you have your webserver ...


0

This is really a bad idea, suppose if you want to host one subdomain a.company.com in one web server, and b.company.com in another web server, may be another ISP. What you will do ?. So wildcard DNS is not an option, it should be precise, create A record for each sub domain and points to relevant IP. Chances are there to move your web server from one ISP to ...


0

Another issue here is the SEO: if all *.domain.com showing the same content, your website will be badly referenced, at least by Google (https://support.google.com/webmasters/answer/66359).


1

No, in general you need DNS entries (at least one wildcard entry as per your comment) so that the clients know where to look when they call the domain name. Only for strictly local dev purposes, you might get away with defining entries in your hosts file on the client. This would need to be done on every client and usually don't work on mobile devices ...


2

This is not possible without a wildcard certificate or a certificate for the subdomain. You could create a cert for each of your subdomains using Let's Encrypt though (assuming cost is the issue).


0

The solution may lie in how nginx handles the default server along with how I created the config for the sites. Doing curl -I http://example.com showed some erroneous redirecting that may have made nginx look for a default server which isn't the one I wanted. My solution was to actually spell it out better for the server. I did this: server { listen ...


0

I would disable the catch-all for invalid domains. That way, attempting to access https://ww.my-domain.com in a web browser would result in a less-scary “Server not found” error which the user would be more familiar with. In the case of Firefox, it helpfully suggests that the user, Check the address for typing errors such as ww.example.com instead of www....



Top 50 recent answers are included