Can I use Linodes DNS manager without running a Linode? - server

Can I use Linodes DNS manager without running a Linode? I want to remove all of my Linodes, but use the DNS manager to point the MX Records to a different place (so the mail still continues to work). Is this possible, or will removing the Linode stop this?

You will need to keep at least one active Linode on the account for Linode's DNS hosting to remain in service. You will need to find a new DNS hosting provider if you would like to remove all of your Linodes.

Related

Changing domain to another server

In the past, the domain was hired and used on a physical server (which still exists today)
And now I need this domain to stop directing the old physical server and start redirecting to the new one (which will also be physical)
Old Server : Linux Apache
New Server : Windows (IIS?, Apache?, WAMP? is still being decided)
Can someone give me a tip? I'm in the dark here
The first thing you should do is find the nameserver addresses available on your new hosting account.
The quickest way to find your new hosting account's nameservers is to look at the information in the email your hosting service sent you the first time you purchased hosting, or from the documentation provided by your hosting service's website. If you're still confused about where to get one, contact your hosting provider and ask them for a “DNS server” or “name server” for your domain.
Nameservers are usually in the form of ns1.companyname.com, ns2.companyname.com, etc., where companyname.com is usually the name/brand of your hosting service.
Your hosting service will generally provide 2 or more nameservers that you can use. Write down all the nameservers. It would be even better if you save the email/web page that contains the nameserver info so that later you can copy and paste it directly. Later in the next step, you must enter this nameserver information into the control panel where you purchased the domain (registrar), exactly as stated.
After you get the nameserver information, go to the domain control panel at your registrar. Don't forget, this means you're logging into the system where you bought the domain and going to where the domain management section is.
Once you find the appropriate page to change your nameservers, you will usually see a form that will allow you to enter Nameserver #1 (or “Primary Name Server”), Nameserver #2 (or “Secondary Name Server”), and maybe a few others (such as the 3rd and 4th nameservers). The terms may not always be the same, but the basic meaning will still be your first nameserver, 2nd and so on.
Fill in your nameservers, usually starting with ns1, into the Nameserver #1 field. After that type your 2nd name server, usually the name starts with ns2, to Nameserver #2, and so on. A domain name has at least 2 name servers associated with it. Some web hosting services provide more than 2, some only 2.
After the nameservers are installed with details, done. You only need to wait a moment until your website can be accessed using your domain name. Usually, it only takes a few hours for the machine to work properly.
You need to log into your Registrar account and update your DNS to point the domain to the public IP address of the new server.
This is normally a fairly easy and quick change. As an example, you can check out how to make DNS updates on GoDaddy here.
Depending on which new server you chose and the server provider, there may be additional steps involved in order for the new server to receive external traffic. Additional steps may include, but not limited to, updating a firewall and configuring the server settings.

Automatically update a domain with an IP address

Over the years, I used No-IP to link a domain to my IP address, and then used No-IP's DUC (Dynamic Update Client) to update my IP, so that the domain will always point to my IP.
That's very handy for running dedicated game servers.
Is there a DUC-equivalent for Google Cloud DNS?
In essence - No - there isn't :(
Unless yo're using Google Domains for your domain hosting then yes - they support just the thing.
Cloud DNS doesn't have that functionality. There are several workarounds like reserving a public IP for your VM which in my opinion would be the best way to do it. Unless your VM get's deployed using Deployment Manager then it may require some more scripting.
Similar questions have been raised on Stackoverflow here and here which you might find helpful.
If you're running Linux here you'll find a complete script how to update DNS records after a machine startup.

How to Setup Reverse DNS On Linode for Your Instance when you use Cloudflare to Provide DNS

Hi Our site is based on Smartphone, Laptop, Gadgets Specs, Price
and we are using Linode server to get host our site but same sit opening in Linode rDNS, due to this most of our links such as https://www.pdevice.com/product/samsung-galaxy-s20-ultra-5g-price-specs opening with Linode domain address, we also contacted to them they have told us that, It looks like "pdevice.com" is your domain name but since it's pointing to CloudFlare's IP, you would need a work around in regards to setting reverse DNS. An option would be to create a subdomain and point this to your server's IP address. You may be able to get around this by having the "www" record for your domain point to your server's IP addresses rather than Cloudflare's IP addresses. and as we told we are using Cloudflare to provide CDN and DNS so how to solve this isse we can't recognize, because it shows issue while past RDNS to Subdomain.pdevice dot com, so how to do this with our server.

DNS with Google Compute Engine

I'm using GCE as a web server for the first time. Everything is fine so far, I have installed the LAMP stack without any trouble but now is the time to set up the DNS.
My two problems are :
I can't handle email adresses with GCE (can't send emails without sendgrid). So I would like to keep the emails going to my current shared hosting. So emails should be managed by my shared hosting but access to my website should be via GCE.
I also would like my DNS to point to a specific folder of my GCE instance (not the root).
I searched a lot for the answer but I can't manage to make it happen.
Thank you for your time
I found a solution... Posting here if anyone has the same problem later...
A record to GCE : # to xxx.xxx.xxx.111
A record to shared hosting : mail.domain.com to xxx.xxx.xxx.222
MX record # to mail.domain.com
Easy. Seems to be working for me right now.

How to make Windows DNS and WINS settings persist in an Azure VM?

I have a domain controller set up in an Azure VM, and a couple of other servers also set up as VMs. When I set up the server VMs, I configured DNS and WINS to point to the IP address of the DC and joined them to the domain. However, these settings don't survive a shutdown (where the VM is deallocated). When the VM is started back up, DNS and WINS are empty, and domain authentication does not work.
I read that I should provision new VMs via PowerShell commandlets, specifically setting up domain joining. I tried that, and maybe I got something wrong, but it didn't work -- the newly provisioned VM was not joined to the domain, and did not have DNS/WINS set to point to the domain controller.
In any event, my question is: is there any way to re-configure an existing VM to retain network settings through a shutdown or is my only option to figure out how to provision a brand new VM to be married to the domain controller, and then to start from scratch?
Thanks!
You shall never use static configuration on your Azure VM! Neither for IP Addresses, nor for DNS Settings. What I recommend to use is a long story you can read here. It is tested, validated and proven to be effective. A short extract follows:
You should setup at least two sub-nets. Leave one solely for the DNS (and AD/DC if it happens to be the same server). Put all rest of the machines in the other Sub-Net. Thus, you will have 100% predictable IP Address of the DNS Server machine. Having that in mind, configure the DNS for the virtual network via the portal or via PowerShell. But explicitly configure DNS Server for that virtual network. Set IP address for the DNS - the one that you know it will have!
Please do never forget - never manually change network configuration settings for an Azure VM! Doing so is a path to failure.
The above method will help you resolve DNS issue. Now, for the WINS. I don't think you can configure WINS via Virtual Network settings. So, if your VM really loses WINS config, you can create a small powershell script that runs locally on each VM to configure WINS settings upon boot. You can either make this script more generic by looking up the DHCP assigned DNS server and use the same IP Address for WINS, or just put it static, because you know what the IP Address of DNS server will be.
Anton presents a clever and perfectly workable solution, but I wanted to understand what exactly I was doing wrong, because Microsoft guidance suggests that it should be perfectly possible to set up and maintain an Active Directory domain the in the Azure cloud without putting the DC into its own subnet.
After a lot of trial and error (mostly error), I finally figure it out. This is not well documented, so hopefully this will help someone:
In Windows Azure, cloud service is another term for application, or a set of components that scale together. A cloud service is assigned a single DNS name and a single external IP address. In the context of virtual machines, you typically have a 1:1 correspondence between a cloud service and a virtual machine. You only add additional virtual machines to an existing cloud service when you want Azure to automatically load balance and distribute requests among the VMs inside that cloud service, treating them as if they were one.
This brings me to my mistake. Not fully understanding the above, I was attempting to add a new worker virtual machine to the cloud service in which I set up my Domain Controller. That is not a supported configuration. Once I understood that, and properly configured a new VM into its own cloud service, associated with the domain controller as DNS server, everything worked perfectly.