Tag Info

Hot answers tagged

5

This is because SANs like gateway and services are not fully qualified. In the case of services, it's actually a valid gTLD already. Others like gateway could potentially become valid at some point if ICANN decides to do so. Solution would be to fully qualify your domain names. E.g., instead of gateway, use gateway.myandy.com. Related: The tradition of ...


3

Subdomains are not affected by the main domain's SPF record. If you have a bunch of subdomains that you know will never send mail, the best thing to do is to define an SPF record of -all for each of them. That way, the internet can also know that you intend them never to send email. Edit: if there is no SPF record in place for a subdomain, recipients who ...


3

Yes it is. Your internal DNS server will be authoritative for ad.foo.com. Your external DNS server(s) will be authoritative for foo.com.


3

Unless you are going to offer Active Directory-related services to machines using public DNS resolvers (which is ill-advised, because AD's security posture wasn't designed to be exposed directly to the public Internet) you don't need to expose your AD DNS namespace to the Internet. Typically all your domain member computers (including the Domain Controller ...


3

First and foremost, it's usually recommended that you replace your "domain.com" hosting to be a permanent and visible redirect to "www.domain.com". Usually, it's done either inside your web panel or in your webserver's configuration file with something similar to that (apache2 example) : <Virtualhost *:80> ServerName domain.com RewriteEngine ...


3

The Pingdom DNS check tool does not clearly state this but from its behavior it's clear that it expects the name of a zone, not just any domain name. Ie, whatever you enter it expects that it should be a zone of its own (with delegation in place), which will not be the case in your example.


2

You are missing some configuration in your virtual host settings. As explained in Apache docs you need to specify following options for your named virtual host: ServerName www.domain.tld ServerAlias domain.tld *.domain.tld DocumentRoot /www/domain ServerAlias is optional, but usually you will want to use it. In your case you need to specify: ServerName ...


2

Yes, It's possible. For Example. website.com Has an "A" record pointing to 197.242.76.216 sub.website.com has an "A" record pointing to 87.34.55.32 You would either Contact your Host to set this, or if you have the ability to point DNS your self then do so. Just make sure that the site you want to serve on that subdomain exists on the server that it's ...


2

There's nothing wrong with your DNS: [me@risby ~]$ dig www.raotechsolutions.com [...] ;; QUESTION SECTION: ;www.raotechsolutions.com. IN A ;; ANSWER SECTION: www.raotechsolutions.com. 570 IN A 23.229.190.135 and [me@risby ~]$ dig foo.raotechsolutions.com [...] ;; QUESTION SECTION: ;foo.raotechsolutions.com. IN A ;; ...


2

If you are using a separate server for shop.example.com you will need to provide an A record that points to the server. If you put example.com and shop example.com on the same server then you can use either an A record or a CNAME record to point shop.example.com to the example.com server. You need to make the changes on the name servers for example.com.


1

Sounds like you might be able to use the (otherwise rarely seen) DNAME record. For instance, in the internal.example.com zone: foo IN DNAME foo.bar.com. A query for xx.foo.internal.example.com would then return a synthesized CNAME pointing to xx.foo.bar.com.


1

The file "beryjuorg-blog.conf" is missing a server_name directive, which means that server block will be a "catch-all" for requests with no HTTP/1.1 Host header (the domain name) or an undefined Host header. See How nginx processes requests and server blocks for more on this. Since you have a static IP address, you can make the configuration more explicit ...


1

You're correct in that the current conventional wisdom (and widely considered best practice) is to use an unused subdomain of your public domain for AD. For all intents and purposes that's where the relationship stops. Your public DNS and your AD DNS do not need to interoperate. You don't technically need to delegate the subdomain to your AD DNS servers ...


1

There's another typo in the IP address that domain resolves to. (In addition to the one created in the question when you updated 122 to 124 instead of 142) > dig +short osgwallpapers.servepics.com 114.142.222.81 > dig +short wallpapers.osgalaxy.net 144.142.222.81 The first part of the IP should be 114 instead of 144. The reverse lookup of that IP ...


1

Make sure you enable your site with a2ensite dev.mysite.com Once you do this, a symlink to the config file is placed in the sites-enabled directory, which should allow the site to be accessed assuming no other issues exist. This question gives a few more details.


1

The subdomain has it's own password policy, you need to change this as well. A password which always works for testing purposes is something like WeLcOmE123$!, try this. Also, windows can be bitchy about passwords which have anything from your username in them.



Only top voted, non community-wiki answers of a minimum length are eligible