One place for hosting & domains

      GratITude: Going Above and Beyond Prevents a COVID-19 Outbreak


      Today, we’re continuing our GratITude Series, highlighting the hard-working members of our data center and IT teams in essential roles powering a connected world. Their dedication enables our thousands of global customers to successfully operate their businesses in good times and in times of immense challenge. None of us could do what we do without them, and here we’ll share their stories.

      Agility and adaptability have been the name of the game for data center operators when it comes to keeping up business as usual during the pandemic. As restrictions start to lift in the U.S. and a semblance of normalcy returns, we’d be remiss in not recognizing the hard work of INAP’s dedicated data center ops teams to keep our customers online while staying safe and healthy. Policies were put in place to keep both staff and customers safe, but when an unknowingly COVID-19 positive customer entered INAP’s flagship Phoenix data center, a dedicated supervisor stepped up to keep his team safe from exposure. Read on to learn how INAP handled the situation to keep our data center and customers operating at peak performance.

      A Typical Day in the Data Center

      Lawrence Welsch
      Lawrence Welsch, Data Center Operations Supervisor at INAP’s flagship Phoenix data center.

      Data Center Operations Supervisor Lawrence Welsch joined INAP three years ago, just as the company was opening our flagship Phoenix data center. He began his work life as a cable technician at just 11 years old, when he began helping his dad in the field. At 20, he became a foreman at an install company that worked on builds for companies like Walmart and Staples. Welsch made his way to INAP after spending 13 years working for Acuative, a third-party Sysco vendor.

      Welsch brought those years of experience to the Phoenix data center. On a typical day, he covers various aspects of data center operations, everything from shipping and receiving t

      o cleaning. When he arrives on site, Welsch runs a pass down with his team, ensuring everything is in order and checking in on the work orders submitted by customers.

      Much of his time is spent quoting jobs and building out drawings for potential customer space, working with customers off-site at INAP’s remote areas throughout the market and working with INAP’s vendors for the site. And, as with most jobs, he spends time answering a lot of emails.

      There’s no end to the work, especially to keep customers online and performing at the highest level. But throughout the pandemic, and especially for a 24 hour+ period in January 2020, the workday was anything but typical.

      Preventing a COVID Outbreak

      Setting strong COVID-19 policies to keep staff and visitors safe in the data center was not a cut and dry process. In the initial weeks of the pandemic, the news on the virus and the local regulations around it continued to shift. INAP management worked with any incoming regulations and adapted and tweaked policies as needed with the input of the teams on the ground in the data centers.

      “We had a good amount of support from upper management,” said Welsch. “They worked with us to try to eliminate potential threats from entering the facility and put out notifications accordingly.”

      INAP locked down all biometric readers and disabled them, beefing up security for a visual and a verbal login to prevent the virus from being spread via touch. There was a mask mandate and the number of people coming to visit the site was limited. The INAP team onsite helped prevent unnecessary customer visits, but small groups of visitors were allowed on site for essential work.

      Even with the strictest policies in place, an unknowingly positive customer came to work in the data center, exposing on site staff members to the virus. The news of this exposure came in the middle of Welsch’s shift.

      “We made sure that anyone who was near this employee got sent home,” Welsch recalls. “We locked down the facility and I cleaned it head to toe myself. Security went through and cleaned all the areas that might’ve been potentially infected outside of the containment zone. We even called up an in-house cleaning company to come in and do a sterilization spray throughout the facility.”

      Welsch then called his wife to bring him an overnight bag and a blow-up mattress. He ended up staying onsite for about 29 hours straight to ensure his team did not have to come in and risk exposure. “The longer the wait, the better,” he said.

      These actions eliminated much of the threat. The unexposed team members stayed secure in the bullpen, or office, where they could monitor the building’s systems and answer phone calls and emails as needed.

      Welsch never ended up contracting the COVID-19.

      Above and Beyond at INAP’s Flagship Phoenix Data Center

      This isn’t the first time that Welsch has gone above and beyond in his role at INAP.

      “He continually steps up to work additional hours outside of his normal schedule to cover extra shifts, including weekends where we have to have an engineer on site 24/7,” said Greg Cash, Senior Director, Data Center Operations. “This is a 24/7 market and when we have a limited amount of data center engineers available for shift coverage, his willingness to go above and beyond is incredible.”

      Cash notes that Welsch covers the Phoenix market for all the other partner locations INAP supports Welsch has also consistently supported one of INAP’s largest customers and has been instrumental in helping the site stay in compliance.

      INAP Phoenix data centers

      “Lawrence has become a real go-to and has shown that he takes his site supervisor role very seriously and cares about the facility and the staff,” said Cash. “He puts in the extra hours and leads by example.”

      It’s because of hardworking and dedicated team members like Lawrence Welsch that INAP can ensure our customers’ needs are met and exceeded. We could not succeed without employees who are willing to go above and beyond to allow our customers to meet their goals and continue to innovate, even in unusual and challenging times.

      Laura Vietmeyer


      READ MORE



      Source link

      How To Develop a Docker Application on Windows using WSL, Visual Studio Code, and Docker Desktop


      Introduction

      The advent of the Windows Subsystem for Linux 2 (WSL 2 or WSL for short) has simplified Linux-based development on Windows. The WSL 2 allows for direct integration with Docker Desktop and has plugins for direct development using Visual Studio Code.

      In this tutorial you’ll set up a development environment on Windows using Visual Studio Code, the WSL, and Docker Desktop. You’ll build a Python Flask web service in Docker to demonstrate the development functionality of these tools.

      Prerequisites

      In order to follow along with this guide, you’ll need:

      • Personal Computer with Windows 10 and the WSL 2 installed: You’ll want to ensure that the WSL is installed correctly and that you have Ubuntu 20.04 installed into the WSL. You can follow the tutorial How To Install the Windows Subsystem for Linux 2 on Microsoft Windows 10 to set this up.

      • VSCode Installed: You can download and install VSCode from its official website. You do not need to worry about installing plugins. The required plugins will be discussed in this tutorial.

      Step 1 — Installing Docker Desktop and Connecting to the WSL

      Docker is a common development tool used by developers to deploy applications. Docker Desktop has the advantage of also being able to run and integrate with your WSL Linux environments.

      Set up Docker by downloading Docker Desktop from Docker’s website and clicking the Get Docker button to start the download.

      Go to Docker's website and download Docker Desktop

      Run the executable once you get it downloaded and allow it to make changes.

      Run the executable and let Docker make changes

      During the installation make sure that Install required Windows components for WSL 2 is checked. Whether or not you want a Desktop icon is up to you.

      Make sure that

      After the installation process is done you’ll be prompted to log out and back in for your changes to take effect. Click on the Close button and then make sure to log out and back in so that the changes take effect.

      Once Docker is done installing you'll need to logout and log back in for changes to take effect

      Log back in and launch Docker Desktop from the Start menu.

      Launch Docker Desktop from the start menu

      Warning: When you first launch Docker it will prompt you with a Docker tutorial.

      Docker Tutorial Launched

      If you are unfamiliar with Docker it may be worth your time to do the Docker tutorial, but it is not required for this current tutorial. Once you have either done the tutorial or skipped it, continue on.

      The Docker dashboard will show up. This is where any running containers will appear as well as settings and status of Docker. If you see the logo is green in the bottom left corner that means that Docker is running. If it is yellow then Docker Desktop is still starting; give it a minute or so to finish. If the indicator is red, then Docker is unable to start.

      The Docker dashboard will open. If the logo in the bottom left is green it means Docker is running

      Next you’ll need to expose Docker to the WSL so you can run Docker on your Ubuntu environment. Click on the Gear icon in the top right corner to open Settings. From there you’ll click the Resource tab and then click WSL Integration. You’ll see your Ubuntu environment there, but toggled off, along with any other WSL environments you may have installed.

      Go to Settings, select Resources, and select WSL Integration. You'll see your WSL Ubuntu there, not selected

      Enable Docker in your Ubuntu environment by clicking on the slider to turn it on, and then click Apply & Restart. Once the restart is done your Ubuntu environment will have access to Docker.

      Select your WSL Ubuntu and click Apply & Restart

      Now you can test your Docker connectivity with the WSL. Open a terminal to the operating system you enabled Docker in, Ubuntu in this case, and run the Docker hello world command:

      Your Ubuntu environment should download and run the hello world container and display its output.

      Test Docker by running Docker run hello-world in your WSL Ubuntu

      Now that you have Docker connected to the WSL you’ll learn how to develop within the WSL directly using Visual Studio Code and the Remote Development Extension.

      Step 2 — Using Visual Studio Code’s Remote Extension to Develop within the WSL

      You can integrate your WSL Ubuntu environment with your Visual Studio Code, henceforth known as VSCode, to be able to develop directly in a Linux environment.

      First, open VSCode. Go to the Extensions tab on the left hand side of the window. Search for Remote - WSL and the Remote - WSL extension will appear. Click on it and click Install to install it.

      Open VSCode, go to Extensions and search for Remote. Install the Remote - WSL Extension

      Once the installation is completed, press CTRL + Shift + P to open the VSCode command dialog. Type Remote-WSL and you’ll see a few options appear. You can open a new WSL environment, open an existing folder, etc. Select Remote-WSL: New WSL Window. This will open a new VSCode window connected to the Ubuntu WSL environment.

      Press CTRL + Shift + P to open the VSCode command dialog and type Remote. You'll see WSL there. Select Remote-WSL: New WSL Window

      Now that you’re in this new window you can press CTRL + Shift + ` or by clicking on Terminal -> New Terminal in the navigation bar to open up a new terminal and you’ll be dropped into the WSL terminal. Any file you create will be stored in the WSL filesystem as well.

      If you open a new terminal you'll open your Ubuntu terminal and be able to develop using VSCode directly in the WSL

      Now that you have your development environment set up, you’ll build a Python microservice using the Flask framework that creates a 301 redirect to a site that you specify as an environment variable and package it within a Docker container.

      Step 3 — Setting Up Your Developer Environment

      First you’ll want to set up a development environment so you can develop your code using Visual Studio Code. Navigate to the sidebar on the left hand side and click on the topmost icon that looks like a sheet of paper. You will be prompted to either Open a Folder or Clone a Repository.

      File explorer dialog box open

      From here select Open a Folder. The default location will be your home directory. Select this option and click OK.

      Open home directory

      You may be prompted by Visual Studio Code asking if you trust the authors of this folder. This is a security measure to ensure that no automatically executed code can harm your PC. In this case, everything is good so select Yes, I trust the authors.

      Author Trust Dialog box

      Now you should see your home directory in the file explorer panel to the left. Next, create a directory to store your project. Navigate to the folder icon with a plus symbol. When you hover over the icon a popup should appear saying New Folder. Click on this icon to create a new folder and name it my-app. A new empty directory should appear in the explorer to the right.

      New Folder Icon
      You now have your developer environment set up and ready to build your Python microservice in the next step.

      Step 4 — Creating a Python Virtual Environment for Your Project

      Before you get started coding, you need to set up your Python developer environment. In this step, you will install and activate your Python requirements within a virtual environment for easier management.

      You can do all of this from within the terminal in Visual Studio Code. Press the CTRL + Shift + ` key combo to open a new terminal or click on New Terminal under the Terminal section in the top navigation bar. Once you’ve done this you should see a new terminal appear at the bottom of the Visual Studio Code window.

      New terminal in Visual Studio Code

      From this terminal navigate into the directory you created for you code, my-app.

      Next, install the python3-venv Ubuntu package so you can create Python virtual environments.

      • sudo apt update && sudo apt install python3-venv

      Now create your virtual environment using Python:

      This will create a directory called myapp in your current directory. Inside, it will install a local version of Python and a local version of pip, the package manager for Python. You can use this to install and configure an isolated Python environment for your project.

      Before you install your project’s Python requirements, activate the virtual environment:

      • source myapp/bin/activate

      Your prompt should change to indicate that you are now operating within a Python virtual environment. It will look something like this: (myapp)user@host:~/my-app$.

      With your virtual environment active, install flask and gunicorn with the local instance of pip:

      • pip install flask gunicorn

      Note: Once you have activate your virtual environment (when your prompt has (myapp) preceding it), use pip instead of pip3, even if you are using Python 3. The virtual environment’s copy of the tool is always named pip, regardless of the Python version.

      Now that you have the packages installed, you will need to save this requirement and its dependencies. This is good practice so you can recreate your developer environment as needed and will aid in installing the correct packages into your Dockerfile in a later step.

      Use pip to save your environment’s information to a requirements.txt file:

      • pip freeze > requirements.txt

      Now that you have a working virtual environment for development, let’s build the microservice.

      Step 5 — Building a Python Microservice to Redirect Traffic

      The first thing you’ll need to do is create a Python file named app.py and a Dockerfile to specify your Docker requirements. You can create files via the terminal with the touch command and then refreshing the explorer:

      You can also use the file explorer to create a new file by clicking on your my-app folder, then clicking on the New File icon that looks like a piece of paper with a plus sign, then typing out the full name and extension of the file.

      Create your app.py

      Use either method to create app.py and Dockerfile.

      Once you’ve done this, open app.py. The microservice you are going to write today will have only one endpoint, as defined by the @app.route("/") decorator. This endpoint will use the redirect method within the Flask library to perform a 301 redirect to a site that is specified in an environment variable. If no environment variable is set, the app will redirect to DigitalOcean’s website by default.

      Open app.py by clicking on it and add the following lines of code.

      Add an import statement to import the os package, which will enable the microservice to read the environment variable you’ll define later:

      import os
      

      Next, import the Flask class and redirect function from the flask library. You’ll use these to set up your web framework and to redirect traffic to another site.

      from flask import Flask,redirect
      

      Next, create a Flask object that can be acted upon within the code. This is the instance of your web app that you will register routes to.

      app = Flask(__name__)
      

      Create a single method at the / route. You’ll use your Flask instance to decorate the function to specify the route. Within the function, you will use the Flask redirect function to perform a 301 redirect to another site that will be read from an environment variable. If the environment variable is not found, your app will default redirect to DigitalOcean’s home page. This is to ensure your app doesn’t crash if you forget to set an environment variable.

      @app.route('/')
      def hello():
          # Attempt to read REDIRECT_TO from the environment. If nothing is set
          # perform a 301 redirect to DigitalOcean's website
          return redirect(os.environ.get("REDIRECT_TO", "https://www.digitalocean.com"), code=301)
      

      Finally, create a main function that runs your Flask app externally on port 8080. The address 0.0.0.0 is used to designate that you want your app to run on the externally facing network interface of your device, not the local loopback device, also known as localhost.

      if __name__ == '__main__':
          app.run(host="0.0.0.0", port=8080)
      

      The finished app.py can be found below:

      # Import the os package to read the environment variable
      import os
      
      # Import the Flask class and redirect function from the flask library
      from flask import Flask,redirect
      
      
      # Create a Flask object to be acted upon
      app = Flask(__name__)
      
      # Python decorator that specifies the web route that will execute the code below
      @app.route('/')
      def hello():
          # Attempt to read REDIRECT_TO from the environment. If nothing is set
          # perform a 301 redirect to DigitalOcean's website
          return redirect(os.environ.get("REDIRECT_TO", "https://www.digitalocean.com"), code=301)
      
      # Main function that executes the Flask app
      if __name__ == '__main__':
          app.run(host="0.0.0.0", port=8080)
      

      Once you are done, save the file as app.py.

      Now that your app is written, let’s test it.

      Step 6 — Testing Your Microservice

      Now that your app is written, it is time to test it. In the terminal you opened in Visual Studio Code with the activated virtual environment, run the command:

      You should see Flask output that looks similar to this:

      Output

      * Serving Flask app 'app' (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead * Debug mode: off * Running on all addresses. * WARNING: This is a development server. Do not use it in a production deployment. * Running on https://256.333.112.1:8080/ (Press CTRL+C to quit)

      This means that your Flask app is running. Open a browser and navigate to localhost:8080. When you do you should see output happen in your terminal and be redirected to DigitalOcean’s website. This is because you have not specified anywhere for your Flask app to redirect to, so it is using the default.

      To stop your Flask app, click in the Visual Studio Code window to ensure it is active and then press CTRL+C. You’ll see the prompt stop and you’ll be presented with your terminal again.

      Next, run the following command to set your redirect to something else.

      • REDIRECT_TO="https://digitalocean.com/community/tutorials"

      Run your Flask app again using the command

      Go to your browser again and navigate to localhost:8080. You should then be directed to the DigitalOcean tutorials page.

      Note: If you plan on testing multiples redirects with the same container, you may want to use a form of incognito mode. Most modern browsers will cache a 301 redirect, so if you change the environment variable, you may end up at the same site and not see your changes reflected. Using an incognito window or clearing your cache will help with this.

      With this, your app is done and is ready to be built into a Docker image.

      Step 7 — Building and Running Your Microservice in Docker

      In this final step you’re going to package your Python app as a microservice using Docker and a Dockerfile. A Dockerfile is a list of build commands that Docker uses to create your image. These can be commands to install packages, copy files, and more.

      Open the Dockerfile you created in a previous step so you can edit it. In this file you’re going to specify the base image, tell Docker where you want the code to run, create an environment variable that holds the redirect target, copy over all the necessary files to the Docker image, install the necessary Python packages, and finally add the command that will be executed when the container is run.

      Add the following code to Dockerfile to do this.

      First, you need to specify the base image you want to use. The python base image will contain the latest version of Python.

      FROM python 
      

      Next, set your working directory. This is the default directory that Docker will run commands in and drop you into if you connect with ssh.

      WORKDIR /var/www/
      

      Set the REDIRECT_TO environment variable to the default location you want to redirect to. Here I’m setting it to DigitalOcean’s Community Tutorial site. This can be changed when you run the image via the command line.

      ENV REDIRECT_TO=https://digitalocean.com/community/tutorials
      

      Copy your app.py and requirements.txt into your Docker container, using fully qualified paths for the destination.

      COPY ./app.py /var/www/app.py
      COPY ./requirements.txt /var/www/requirements.txt
      

      Run the necessary command to install the Python library requirements within your Docker image.

      RUN pip install -r /var/www/requirements.txt
      

      Finally, set the image run command to run your app. This is the command that is run whenever anyone tries to run your Docker container.

      CMD python3 app.py
      

      The complete Dockerfile is listed below.

      # Choose your base image
      FROM python 
      
      # Set your working directory
      WORKDIR /var/www/
      
      # Set environment variable for redirect. Can be overwritten by Docker run command
      ENV REDIRECT_TO=https://digitalocean.com/community/tutorials
      
      # Copy the necessary files
      COPY ./app.py /var/www/app.py
      COPY ./requirements.txt /var/www/requirements.txt
      
      # Install the necessary packages
      RUN pip install -r /var/www/requirements.txt
      
      # Run the app
      CMD python3 app.py
      

      When you are done, save the file.

      Now you can build the Docker image locally for testing. Run the following command to build your image and tag it with the name myapp. The -t option applies the tag to the Docker image:

      Finally, it’s time to test your Docker image. In your Dockerfile above you set an environment variable REDIRECT_TO to point at a website. This will overwrite the default value in your code so when you run this container, whatever site you specified in the Dockerfile will be your new location.

      Note: If you are prompted by windows to grant permission to Docker to access the network, click Allow.

      To test your image, run the following command:

      • docker run -p 8080:8080 myapp

      While your image is running, navigate to a browser and type localhost:8080 in the navigation bar and you should be redirected to the site listed in the Dockerfile.

      Warning: Sometimes the WSL terminal doesn’t recognize CTRL + C as a way to stop your Docker image. In this instance you’ll need to open another terminal and search for your running Docker image using the command:

      This will show an output similar to this:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3f081712283e myapp "/bin/sh -c 'python3…" About a minute ago Up About a minute 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp reverent_saha

      Take the container id, which in this example is 3f081712283e and use the docker kill command to stop it.

      Finally, let’s test changing the environment variable of the redirect in the docker run command.

      Type the following command to change the environment variable to the DigitalOcean cloud console page, https://cloud.digitalocean.com.

      • docker run -p 8080:8080 -e REDIRECT_TO=https://cloud.digitalocean.com myapp

      Now if you go to a browser and browse to localhost:8080 you will be redirected to the site specified on the command line.

      Conclusion

      You have successfully set up a developer environment on Windows using the WSL, Visual Studio Code, and Docker Desktop. You’ve demonstrated how to build, test, and package code on Windows, allowing you to have more options when it comes to developer environments.



      Source link

      Nameservers vs. DNS: A Complete Guide


      If you’re thinking about migrating your site to a new hosting provider, you may be wondering what it will mean for your domain registration. Perhaps you’re worried visitors will be unable to access your content if you switch web hosts.

      This is why it’s important to understand what nameservers and the Domain Name System (DNS) are and how they work. This understanding can help you manage your migration more efficiently.

      In this post, we’ll take a closer look at nameservers and DNS records. We’ll also show you how you can access these essential components of your site. Let’s get started!

      Nameservers vs. DNS Records: What They Are and How They Work

      A nameserver connects your domain name with the Internet Protocol (IP) address of the server that hosts your website. Thanks to nameservers, browsers like Google Chrome and Mozilla Firefox can direct users to the right page when they type in a site address.

      Typing a site address into Google.

      For example, if you type “myblog.com” into Google, the nameserver tells the browser where that domain is located (i.e., the address of your web host). Without this information, the browser wouldn’t be able to display the site.

      Nameservers form part of an online database known as the Domain Name System (DNS). This system is part of the  Transmission Control Protocol (TCP) and the Internet Protocol (IP), which defines how computers communicate via the internet and private networks.

      DNS plays an important role, as it aids the conversion of simple domain names (e.g., myblog.com) into an IP address (e.g., 12.34.56.78), which computers then use to identify one another on the network. Effectively, DNS functions like a phone directory. It contains records of web devices, such as computers and servers, and their associated IP addresses.

      Every domain has its own DNS records, which include the nameserver. These are generated when you register your domain name with a hosting provider or a domain registrar. Therefore, your nameserver points your domain name to the IP address of your host or registrar.

      Your Great Idea Starts with a Great Domain

      Don’t let someone else register your URL. Search DreamHost’s 400+ TLDs to find the perfect fit for your website.

      How the Browser Finds Your Website

      Everything that is connected to the internet has an IP address, including websites and servers. There are millions of IPs in use all over the world, and they are all unique. Your site will have its own IP address, which your host provides.

      However, your domain name needs to be able to connect with your site’s IP address. For example, when you enter a site’s URL into an address bar, your browser will try to access the corresponding page. To do this, it will go through some steps that the user doesn’t see.

      First, the browser connects to the target site’s domain registrar. Then the registrar points the browser to the target site’s hosting provider (e.g., dreamhost.com). Once the browser arrives at the web host, it will look for the correct nameserver (e.g., ns1.dreamhost.com).

      The process is practically instantaneous, so as users, we don’t fully appreciate the additional steps. However, should you decide to change your hosting provider, you’ll need to point your domain name to your new host. This is a vital step. Otherwise, users will not be able to find or access your site.

      How to Use Nameservers and DNS Records

      Knowing how to access your domain’s DNS records, including your nameservers, can help you arrange a smoother transition to your new host. Let’s take a look at the different ways you can locate and manage these important records.

      Locating and Managing Your Nameservers

      Your domain’s nameservers can be found in your web hosting account. These might also be available on the hosting company’s documentation page.

      The nameservers for domains managed by DreamHost are:

      • ns1.dreamhost.com
      • ns2.dreamhost.com
      • ns3.dreamhost.com

      If you’re a DreamHost client, you can also log in to your hosting account to view your nameservers. To start, navigate to Websites > Manage Websites in the side menu.

      Managing your websites in DreamHost.

      Next, find the domain you wish to edit and click on the DNS tab on the right side of the screen. This will bring up a page with your nameservers.

      Locating your nameservers in DreamHost.

      Note that if your domain is registered with a different company, you won’t be able to update your nameservers from your DreamHost account. To manage your nameservers, you’ll need to log in to your account with the company that manages your domain.

      If your domain is registered with DreamHost, you’ll be able to edit your nameservers. For instance, if you wish to replace your current nameservers, you can simply erase them from the box and type in your new ones.

      You can also manage your domain from the Registrations page in your account. For more information about this, you can read our complete instructions for editing your nameservers on DreamHost.

      Alternatively, you can find out what a website’s nameservers are by performing a WHOIS lookup. Nameservers are public records, so it is possible to find this information by using a third-party tool.

      Several sites offer this service, including lookup.icann.org.

      Running a WHOIS search.

      You can type the domain into the search bar, and a list of records will appear. For example, here are the nameservers for google.com:

      Viewing nameservers in a WHOIS search.

      Note that a WHOIS search can also show the personal details of the domain’s owner, including their name and email address. Some hosting providers and domain registrars offer WHOIS privacy, which protects the identity of the user.

      Locating and Managing Your DNS Records

      Your DNS records are just as easy to locate and manage. You can log in to your hosting account to view your records and make changes to them. If your domain is managed by a third party, such as a domain name registrar, you’ll need to log in to your account with that company.

      If you have a DreamHost account, your DNS records can be found on the same page as your nameservers.

      Viewing your DNS records in DreamHost.

      You can add a new DNS record to your domain by clicking on the blue Add Record button. As you may notice, there are different types of records you can create. Let’s take a closer look at the most common ones.

      A Record

      The address record is the most basic type of DNS record. It is used to point a domain (or subdomain) to an IP address.

      CNAME Record

      The canonical name record points a domain to another domain, as opposed to an IP address. This is used when a site has subdomains, such as shop.myblog.com or donations.myblog.com.

      Adding a CNAME record in DreamHost.

      These are subdomains of myblog.com. Let’s say that each of these subdomains has a CNAME record containing the value “myblog.com.” Since the DNS is looking for an IP address, when the CNAME record is accessed, a further lookup is carried out at myblog.com (as this is the value contained in the CNAME file).

      It will then return the IP address stored in myblog.com’s “A” record. This means that these subdomains are aliases of the main domain, and the canonical name (or “true name”) of these subdomains is actually “myblog.com.”

      MX Record

      A mail exchange record is used to direct emails to an address registered on your domain (e.g., hello@myblog.com) per the Simple Mail Transfer Protocol (SMTP), the standard protocol for email.

      It is important to ensure that your MX records point to the right mail server. If not, emails won’t be delivered to your account. We also recommend that you back up your emails before switching to a different host.

      Adding an MX record in DreamHost.

      NS Record

      As mentioned previously, this is the nameserver record. You can use this setting to change your nameservers so that they point to your new hosting provider.

      TXT (Text) Record

      This one allows you to insert text into your DNS records. Originally, the TXT record was designed for human notes, such as site descriptions or development details. However, it is possible to include machine-readable data.

      Adding a TXT record in DreamHost.

      This record can help you to protect your site against spam. It also enables you to verify your domain, such as by adding a Google Site Verification record. It is very common to have multiple TXT records for a single website.

      Monitoring Your DNS Records

      When updating your nameservers and other domain records, you’ll need to take DNS propagation into account. This is the time it takes for your DNS records to update across the internet. For example, when you modify your nameserver to point to your new hosting company, this change can take up to 72 hours to come into effect.

      At DreamHost, we offer a DNS propagation checker to help you monitor your records. To access this tool, simply click on DNS checker on your Records page.

      Accessing the DNS Checker in your DreamHost account.

      On the next page, you can check your website’s current IP address and DNS record information. Our interactive maps show you the status of your records across nameservers in different locations.

      Using the DNS checker to view the status of your records.

      The green checkmarks on the map indicate that your DNS is up-to-date in the specified locations. Meanwhile, a single red cross suggests there might be a problem with the DNS server in that location.

      If you see multiple red crosses, it may mean that you haven’t configured your DNS at the company where you registered your domain. However, this could also be a sign that your new DNS settings haven’t yet finished updating.

      DNS Management Made Easy

      Whether you need help identifying a domain’s nameservers, understanding a DNS query, or choosing a web host, we can help! Subscribe to our monthly newsletter so you never miss an article.

      Nameservers vs. DNS in a Nutshell

      Understanding how nameservers and DNS Records work can ensure a smooth transition when migrating your site to a new host. It is imperative that your domain name points to the correct nameserver. Otherwise, site visitors will be unable to access your pages.

      At DreamHost, we make your life easier by managing the entire transition process, including your domain transfers. We also enable you to manage your own domains and DNS from your hosting account, and our service comes with free privacy protection for your domain.



      Source link