One place for hosting & domains

      The Website Owner’s Guide to DNS Propagation


      Unless you’re in the information technology field, it’s possible to go your whole life (blissfully) without hearing the words “DNS propagation”.

      That is, unless you migrate your website to a new web hosting service. Only then do you learn that the lightning-fast internet you’re accustomed to has this thing called propagation, and it moves like a turtle.

      The good news is that it’s really not that slow. DNS propagation isn’t instantaneous, but it has a lot of ground to cover. By understanding what’s involved in DNS and how propagation works, you’ll be able to use this knowledge to better secure your site and offer stronger performance for website visitors.

      In this article, we’ll explain what DNS is, how it works, and most importantly, what it means for your website. We’ll also offer some tips to help you ensure DNS security for your site. Let’s get to it!

      What Is DNS?

      DNS is an acronym for Domain Name System. It’s the directory of every domain name used to access websites across the internet. DreamHost.com, YouTube.com, Wikipedia.org, and your own website’s URL are all stored in the Domain Name System.

      It’s called a system because it involves a hierarchy of nameservers that work together. They ensure that when you type “dreamhost.com” in your browser, you’re served the content from our site and not from any other of the millions of websites out there.

      When you type a domain name in your browser, DNS gets to work. It facilitates communication between your computer (or another connected device) and the server where the website is hosted. How does this happen? DNS matches domain names with IP addresses. Let’s take a closer look at that process.

      Your Great Idea Starts with a Domain Name

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

      How DNS and IP Addresses Work Together

      Each device connected to the internet has a unique Internet Protocol (IP) address, expressed as a numerical value. IP addresses help to route information requests over the internet. Queries (like typing a website’s name into a browser) are returned to the sending IP address – the device you’re using.

      IP addresses are assigned by an Internet Service Provider (ISP) for each network device. IP addresses can be updated or changed too, so this makes keeping up with them an ongoing process.

      For example, if you use your laptop at home, it’s assigned an IP address by your internet provider. If you take that same laptop to work and join the network there, your laptop will be assigned a different IP address by your employer’s internet provider.

      Websites have IP addresses too, since they also are stored on computers connected to the internet. When you type in a domain name, it doesn’t know where the website is located. What you really need is the IP address for the site. Then you can send and receive information.

      Rather than having to remember numeric strings (IPs) to designate website addresses (the servers where websites are stored), we use domain names. This makes it much easier to visit the many websites that we frequent. The process is similar to looking up a contact on your phone.

      Instead of memorizing all the phone numbers listed in your contacts, you can use a series of lookups. Let’s say you wanted to find Joe’s number. To call him, you might:

      • Open your contacts.
      • Tap the letter “J” for Joe.
      • Scroll through all the “J” contacts until you find Joe.
      • Tap Joe’s name to open his contact card.
      • Tap the phone icon to call Joe.

      DNS progresses through a series of lookups as well, until it finds the one unique number (IP address) for the website you’re looking for. In other words, DNS translates every domain name into its assigned IP address through a series of queries and servers.

      DNS Lookup in Action

      DNS lookup happens behind the scenes when you type a domain name into a web browser. The request is sent through a series of queries and servers. Namely:

      • DNS recursor (recursive resolver)
      • Root nameservers
      • Top-Level Domain (TLD) nameservers
      • Authoritative nameservers

      The DNS Recursor (recursive resolver) handles the initial DNS query from the web browser. This is similar to tapping your contacts app to start your search for Joe’s phone number. You have a name, but you need a number.

      For example, the nameservers for all of the domains managed by DreamHost, including ‘dreamhost.com’, are set up using the following:

      • ns1.dreamhost.com 162.159.26.24
      • ns2.dreamhost.com 162.159.27.142
      • ns3.dreamhost.com 162.159.27.84

      Back to our phone example, if Joe’s name is saved in your Favorites, the search is over. You have his number in hand, and you don’t need to look it up in your contacts listing. The DNS resolver acts similarly.

      Before your query is sent out to servers across the web, your DNS resolver checks for a “hosts” file on your computer, an index that isn’t often used now. Next, it will search your computer’s DNS cache to see if the IP address is stored in your browser.

      When the DNS resolver exhausts its search through your computer, router cache, and internet provider’s nameservers, the query is then sent along to the appropriate root nameserver. There are 13 root zones for the global internet. Each of them has a root DNS server.

      These root servers answer queries for the records contained in their zones. The root nameserver looks up the authoritative DNS server that contains the IP address for the domain name being queried. The root server knows where to send the query based on the Top Level Domain (TLD), such as .com, .org, or .net.

      Authoritative nameservers index domain names based on TLDs. The root domain (the website name, plus the .com or other TLD extension) is located on the authoritative nameserver. Its corresponding IP address is returned to the sending IP address, your computer. Finally, you have Joe’s number.

      What DNS Propagation Means (And How Long It Really Takes)

      DNS propagation refers to the amount of time it takes for a DNS change to update across the internet. For instance, if you move your website to another host, your DNS settings will change because you’ll have a new IP address.

      Your website has several different DNS records that might be updated, and you should be aware of these records and what they do:

      • A record: lists your website’s IP address
      • CNAME records: lists your subdomain or other aliases (can be used to point one domain to another)
      • MX records: specifies which mail server will handle your domain’s email
      • TXT records: attaches information to your domain, such as verification records

      When a DNS change is made, propagation can take up to 72 hours. However, it usually takes less than a few hours. Some obstacles may delay complete propagation. Let’s look at a few of the most common factors involved.

      • Internet Service Providers (ISPs). Internet providers keep DNS information cached so they can provide faster page loads for their customers. Sometimes, they may ignore TTL settings and keep DNS information for several days.
      • Domain Name Registries. When you update your DNS information, the update is sent to your domain registrar. It then publishes your nameserver records to its root zone. Some domain registrars don’t publish DNS updates immediately.
      • Time to Live (TTL) settings. This setting determines how long DNS information is allowed to “live” on a computer or DNS server. A higher TTL saves lookup time by keeping the information cached. This helps deliver faster results to the user. The downside is that a higher TTL setting prevents the DNS resolver from getting the most up-to-date DNS information.

      If you update your DNS records, a delay in propagation means that website visitors may be getting outdated information. You can check DNS propagation progress using an online tool, such as Google Admin Toolbox or DNS Checker.

      How to Flush Your DNS Cache

      Your DNS cache speeds requests by caching information locally, rather than relaying the requests through the DNS every time. When changes are made to a website’s DNS settings, your cache is not immediately updated, so your information may be outdated.

      To solve this, you can flush your DNS cache by following the directions for your particular operating system below. If you’re using Chrome for browsing, check out these instructions to clear your cache.

      Windows 8 & 10

      Click on Start, and when the Run box appears, type in Cmd and hit Enter. At the command prompt, enter ipconfig /flushdns as shown below.

      Flushing the DNS cache in Windows.

      After the command runs and returns the prompt, type Exit and press the Enter key to close the window. Instructions are also available for earlier versions of Windows.

      MacOS X 12 (Sierra) and Later

      First, navigate to Launchpad > Terminal, then type the following:

      sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache

      Flushing the DNS cache in MacOS.

      That’s all you need to do!

      OS X 11 (El Capitan)

      You can start by going to Launchpad > Terminal. Then enter:

      macbook$ sudo killall -HUP mDNSResponder

      Alternately, you can find directions online for older versions of MacOS.

      Linux

      Linux currently doesn’t cache the same way as Windows and MacOS, so you’ll need to find out how your particular machine should be flushed.

      What to Know About DNS Security

      The Domain Name System is constantly assaulted by Distributed Denial of Service (DDoS) attacks. These target DNS servers and try to disrupt the system so that domain requests are denied.

      There are several steps you can take to minimize your risk from these DDoS attacks. First, use a secure web host. This is your first line of defense, and your website host should proactively ensure tightened security.

      Multi-Factor Authentication (MFA) significantly reduces the risk of unauthorized access to your site’s files by adding an extra layer of security. The first layer is using your secure username and password to log in. The second layer is provided by an authentication application, such as Google Authenticator. Many users also use YubiKey, a hardware authentication device.

      You can also use a third-party security service like Cloudflare, a Content Delivery Network (CDN) that helps protect against malicious traffic and attacks. Cloudflare also speeds up your website. You can enable it through your DreamHost panel by going to Manage Domains.

      A web application firewall.

      Finally, a Web Application Firewall (WAF) like Cloudflare’s can add additional security by monitoring website traffic between applications and the internet.

      Next-Generation DNS

      DNS security is a growing concern, as DDoS attacks are on the rise. Many businesses use free DNS services for their websites. Not all of these free services have the resources to enhance security. Alternatively, premium services can offer:

      • Better security measures, pointing your domain to more secure nameservers
      • DNS failover, to keep your site accessible in case of a system disruption
      • Better performance due to faster resolution times

      The Domain Name System is key to keeping internet traffic safe, secure, and accurate. As hackers and other bad actors continue their assaults against DNS, businesses and individual website owners may consider how they can help ensure security and stability for their sites.

      Next-generation domain services play an essential role in developing products and services to ensure DNS security and keep the internet safe and accessible.

      Stay in the Know

      Join our monthly newsletter for tips and tricks to build your dream website!

      Domain Registration, Demystified

      DNS propagation ensures up-to-date information throughout the internet so that when someone sits down at a computer and types in your domain name, they’re routed to your website. All of this happens behind the scenes through the Domain Name System’s queries and servers.

      You can ensure that your DNS is accurate and up to date by managing your domain names with DreamHost’s domain services. Find your new domain name and get competitive pricing on registrations. Plus, you can stay secure with free Domain Privacy Protection and optional domain locking.

      If you registered your domain name somewhere else, we’ve got you covered too. You can transfer your domains to us and manage them all in one place, right from your DreamHost panel!



      Source link

      How To Acquire a Let’s Encrypt Certificate Using DNS Validation with certbot-dns-digitalocean on Ubuntu 20.04


      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      The majority of Let’s Encrypt certificates are issued using HTTP validation, which allows for the installation of certificates on a single server. However, HTTP validation is not always suitable for issuing certificates for use on load-balanced websites, nor can you use this validation to issue wildcard certificates.

      DNS validation allows for certificate issuance requests to be verified using DNS records, rather than by serving content over HTTP. This means that certificates can be issued simultaneously for a cluster of web servers running behind a load balancer, or for a system that isn’t directly accessible over the internet.

      In this tutorial, you will use the certbot-dns-digitalocean hook for Certbot to issue a Let’s Encrypt certificate using DNS validation via the DigitalOcean API.

      You can use the certbot-dns-digitalocean tool to integrate Certbot with DigitalOcean’s DNS management API, allowing the certificate validation records to be automatically configured on-the-fly when you request a certificate.

      Another key benefit of certbot-dns-digitalocean is that you can use it to issue certificates for individual servers that may be running behind a load balancer, or are otherwise not directly accessible over HTTP. In these cases, you can’t use traditional HTTP certificate validation, unless you set the validation files on each and every server, which can be inconvenient. The certbot-dns-digitalocean tool is also useful if you want to issue a certificate for a server that isn’t accessible over the internet, for example an internal system or staging environment.

      certbot-dns-digitalocean also fully supports wildcard certificates, which can only be issued using DNS validation.

      Prerequisites

      To complete this tutorial, you will need:

      • An Ubuntu 20.04 server set up by following the Initial Server Setup with Ubuntu 20.04, including a sudo non-root user.

      • A domain name managed via your DigitalOcean account—that is, for managing DNS records. In this particular example, we will use your_domain and subdomain.your_domain, as well as *.your_domain for a wildcard certificate, however you can adjust this for other domains or subdomains if required.

      • A DigitalOcean API key (Personal Access Token) with read and write permissions. To create one, visit How to Create a Personal Access Token.

      Once you have these ready, log in to your server as your non-root user to begin.

      Step 1 — Installing Certbot

      In this step, you will install Certbot, which is a program to issue and manage Let’s Encrypt certificates.

      Certbot is available within the official Ubuntu Apt repositories, so you can install it using the default system package manager:

      • sudo apt update
      • sudo apt install certbot

      Once the installation has completed, you can check with the following command:

      This will output something similar to the following:

      Output

      certbot 0.40.0

      In this step you installed Certbot. Next, you will download and install the acme-dns-certbot hook.

      Step 2 — Installing and Configuring certbot-dns-digitalocean

      Now that you’ve installed the base Certbot program, you can download and install certbot-dns-digitalocean, which will allow Certbot to operate in DNS validation mode using the DigitalOcean DNS management API.

      Like Certbot itself, which you installed in Step 1, the certbot-dns-digitalocean utility is available within Ubuntu’s default repositories. However, the Certbot repository contains a more reliably updated version, so it is always recommended to use this where possible.

      Continue by installing the package for certbot-dns-digitalocean:

      • sudo apt install python3-certbot-dns-digitalocean

      Once the installation has completed, you need to set up a configuration file containing the DigitalOcean API key/Personal Access Token that you generated as part of the prerequisites.

      Begin by creating the creds.ini file in a private location:

      • touch ~/certbot-creds.ini

      Next, restrict the permissions on the file in order to make sure no other user on your server can read it:

      • chmod go-rwx ~/certbot-creds.ini

      Finally, open the file using your text editor and add your DigitalOcean access token:

      The content of the file will be as follows:

      ~/certbot-creds.ini

      dns_digitalocean_token = your_digitalocean_access_token
      

      Once done, save and close the file.

      Warning: Your DigitalOcean access token grants access to your DigitalOcean account, so you must protect it as you would a password. Do not share it with anyone or check it into a public code repository.

      In this step, you downloaded and installed the certbot-dns-digitalocean utility and created a configuration file containing your API credentials.

      Step 3 — Issuing a Certificate

      In this step, you’ll issue a certificate using Certbot and the DigitalOcean API.

      To issue your first certificate, run Certbot using the following arguments, making sure to specify the correct path to your credentials file as well as your domains:

      • sudo certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/certbot-creds.ini -d your_domain -d subdomain.your_domain

      Note: If you see an unsafe permissions on credentials configuration file warning, this indicates that the file permissions have not been correctly restricted, thus allowing other users on your server to access your token. Please double-check with the chmod command in Step 2.

      Certbot will take a few seconds to request the certificate; you will then receive a message confirming that it has issued your certificate:

      Output

      ... Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem ...

      In the event that the certificate issuance fails, this may be because there wasn’t sufficient time for the DNS changes to propagate. You can optionally increase the DNS propagation delay to give more time for the verification DNS records to propagate and be picked up by Let’s Encrypt. The delay is 10 seconds by default, but you can increase this using the --dns-digitalocean-propagation-seconds argument:

      • sudo certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/certbot-creds.ini --dns-digitalocean-propagation-seconds 30 -d your_domain -d subdomain.your_domain

      Finally, you can also use certbot-dns-digitalocean to issue wildcard certificates for your domain:

      • sudo certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/certbot-creds.ini -d *.your_domain

      Note: In some cases, requesting multiple certificates for the same hostnames in a short time period can cause issuance to begin failing. This is due to rate limits and the DNS time-to-live (TTL) value, which can sometimes cause delays in new DNS changes being propagated.

      To mitigate this, you may wish to wait out the duration of the TTL, or consider adjusting the --dns-digitalocean-propagation-seconds option that was detailed earlier in this step.

      In this step, you used Certbot with certbot-dns-digitalocean for the first time and issued your initial certificates.

      Step 4 — Renewing Certificates

      In this final step, you will renew certificates using Certbot with certbot-dns-digitalocean.

      Once your certificates are nearing expiry, Certbot is able to automatically renew them for you:

      The renewal process can run start-to-finish without user interaction. It will also remember the configuration options that you specified during the initial setup.

      By default, Certbot will run this as an automatic scheduled system task, meaning that no further maintenance is needed for your certificates. You can check that the scheduled task has been correctly installed by printing out the status of the associated system service, which is certbot.timer:

      • sudo systemctl status certbot.timer

      This will output something similar to the following, which shows the loaded task scheduled to run twice per day:

      Output

      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sun 2020-11-22 18:18:40 UTC; 2 weeks 6 days ago Trigger: Sun 2020-12-13 7:17:57 UTC; 11h left Nov 22 18:18:40 droplet1 systemd[1]: Started Run certbot twice daily.

      However, to test that this is working without having to wait until nearer the expiry date of your certificate(s), you can trigger a ‘dry run’. This will simulate the renewal process without making any actual changes to your configuration.

      You can trigger a dry run using the standard renew command, but with the --dry-run argument:

      • sudo certbot renew --dry-run

      This will output something similar to the following, which will provide assurance that the renewal process is functioning correctly:

      Output

      ... Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator dns-digitalocean, Installer None Renewing an existing certificate Performing the following challenges: dns-01 challenge for your_domain dns-01 challenge for subdomain.your_domain Waiting 10 seconds for DNS changes to propagate Waiting for verification... Cleaning up challenges ...

      In this final step, you tested the automatic renewal process within Certbot.

      Conclusion

      In this tutorial, you set up Certbot with certbot-dns-digitalocean to issue certificates using DNS validation with the DigitalOcean DNS management API.

      If you’re interested in learning more about certbot-dns-digitalocean, you may wish to review the official documentation for the utility:

      Alternatively, if you aren’t using DigitalOcean to manage your DNS records, you may wish to check out How to Acquire a Let’s Encrypt Certificate using DNS Validation with acme-dns-certbot on Ubuntu 18.04, which is a provider-agnostic alternative to certbot-dns-digitalocean.

      Finally, if you would like some further technical reading, you could dig into the details of ACME DNS validation by reviewing the relevant section of the official RFC document, which outlines how the process works:



      Source link

      Troubleshooting DNS Records


      Updated by Linode

      Written by Linode

      Having problems with your DNS records? This guide to help get your DNS settings back on track. Follow these tips to troubleshoot DNS issues.

      Before You Begin

      The Domains section of the Linode Cloud Manager is a comprehensive DNS management interface that allows you to add DNS records for all of your domain names. For an introduction to DNS Manager including setting up DNS records, see the DNS Manager guide.

      Note

      Linode’s DNS service employs Cloudflare to provide denial of service (DDoS) mitigation, load balancing, and increased geographic distribution for our name servers. These factors make our service reliable, fast, and a great choice for your DNS needs.

      Note

      To use the Linode DNS Manager to serve your domains, you must have an active Linode on your account. If you remove all active Linodes, your domains will no longer be served.

      Wait for Propagation

      DNS updates will take effect, or propagate, within the time period set by your zone file’s TTL. If you’ve just made a DNS change and aren’t seeing it reflected yet, the new information may not be available for up to 48 hours.

      While you can’t control DNS caching at every point on the Internet, you do have control over your web browser. Try holding down the Shift key or the Control key (depending on your browser) while you refresh the page to bypass your browser’s cache of the old DNS data. You can also try bringing up your site in an alternate browser or editing your hosts file to preview your website without DNS.

      Set the Time To Live or TTL

      In the context of DNS, Time to Live (TTL) tells internet servers how long to cache particular DNS entries. The default TTL for Linode domain zone files is 24 hours. This is fine for most situations because most people don’t update their IP addresses often.

      However, there are times when you’ll want the TTL to be as low as possible. For instance, when you make a DNS change, you’ll want that change to propagate quickly. Otherwise, some people will see the new site right away, and others (who had the old data cached) will still be visiting the website at your old server. Long caching times can be even more problematic when it comes to email, because some messages will be sent to the new server and some to the old one.

      The solution is to lower your TTL before making a DNS change. You’ll want to lower the TTL first, before making any other DNS changes. Here’s a general overview of what should happen during a smooth DNS update:

      Note

      TTL is always written out in seconds, so 24 hours = 86400 seconds.

      1. Check the TTL value for the DNS record you will be updating. Typically, this will be 24 or 48 hours.
      2. Update the relevant DNS records 48 to 96 hours in advance (for a 24-48 hour record), taking into account any intermediate DNS servers. Lower the TTL to five minutes (300 seconds, or the lowest allowed value). Do not make any other changes at this time.
      3. Wait out the original 48 to 96 hours.
      4. Visit your domain’s DNS records in the Linode Cloud Manager again to update your IP address and anything else needed.
      5. The DNS changes should propagate within 30 minutes.

      Find Current DNS Information

      Sometimes you may need to find the current DNS information for a domain. There are two great tools for doing this:

      • dig: Look up individual DNS entries. For example, you can find the IP address where your domain resolves.

      • whois: Find your registrar and nameserver information for your domain.

      If you’re using a computer that runs macOS or Linux, you can use these tools from the command line. To find your domain’s IP (the primary A record), run:

      dig example.com
      

      Look in the answer section of the output to locate your IP address. You can also query for other types of records. For example, to see the mail records for a domain, run:

      dig mx example.com
      

      This returns all of your domain’s MX records.

      To find your domain’s registrar and nameserver information, run:

      whois example.com
      

      This generates a large amount of information about the domain. The basic information you need will be near the top of the output, so you might have to scroll back to see it.

      For a web-based tool, you can also use kloth.net for dig requests and whois.net for WHOIS requests. Note that since you’re running these lookups from a third-party website, the information they find is not necessarily what your local computer has cached. There should be a difference only if you’ve made recent changes to your DNS information.

      For more information and examples on how to use dig, see our Use dig to Perform Manual DNS Queries guide.

      Name Resolution Failures

      If you have DNSSEC enabled at your domain’s registrar it will cause name resolution failures such as NXDOMAIN when an attempt is made to access the DNS. This is because the Linode DNS Manager does not support DNSSEC at this time.

      This guide is published under a CC BY-ND 4.0 license.



      Source link