How To retrieve DNS network information in cPanel

Super Easy Ways To Retrieve DNS Network Information in cPanel

This post shows how to use existing tools to retrieve DNS network information in cPanel, and troubleshoot DNS issues with your cPanel-hosted domain(s). This can be a game-changer in your relationship with cPanel and the web hosting support team helping you to get the best out of cPanel.

Before we discuss how to retrieve DNS network information in cPanel, let’s take a brief look at DNS and how it actually gets to your client when you make a request.

Hosting your website on the internet (and even on an intranet) requires some basic understanding of how DNS works.

Of course, you don’t have to be a system admin or a network guru to get your website online.

For most website/business owners, a basic understanding of DNS types is more than enough.

This is especially true if you are using cPanel or any other control panel ( Plesk, DirectAdmin, etc).

Web hosting control panels such as cPanel provides an easy-to-use, web-based interface that allows server owners and website owners to simplify and automate as much as possible the successful implementation of DNS.

Without tools like cPanel, you would need to have extensive DNS expertise to complete even the most basic configuration.

Having said that, if you desire to get the fullest experience that your cPanel & WHM offers, a proper understanding is needed.

So, the first question would be, what is a Domain Name System (DNS)?

The simplest and most basic explanation is that DNS converts human-readable domain names (for example, mydomain.com) to computer-readable IP addresses so browsers can load Internet resources.

Conversely, it is what made it possible for you to connect to websites using domain names instead of IP addresses.

There are several DNS types and you may already be familiar with them.

To summarize:

  • an A record provides IPv4 address destinations.
  • AAAA records provide IPv6 address destinations, with the same basic functionality as an A record.
  • a CNAME (Canonical Name) record point to the domain value of an A record, behaving like an alias.
  • NS records define your domain’s name servers.
  • an MX (Mail Exchanger) record defines your domain’s mail exchange servers.
  • a TXT record stores textual information, such as SPF record information.
  • a CAA record defines which certificate authorities are permitted to create SSL certificates for the domain.
  • a DNSSEC record protects you from various forms of attacks: spoofing or a man-in-the-middle attack, etc.
  • Time To Live (TTL) values are suggestions to caching nameservers for the amount of time to elapse before checking back in to see if a domain zone has changed.

In cPanel, you can manage most aspects of your DNS at Domains >>> Zone Editor.

cPanel’s Zone Editor makes it super-easy for you to edit, create and delete Domain Name System (DNS) zone records.

Note the word “almost” as not all available zone record types and records that cPanel & WHHM are editable via cPanel.

For example, you cannot edit your domain’s nameservers or SOA (Start of Authority).

Nameservers translate domain names into IP addresses.

They are also used to determine your mail server’s validity as part of spam prevention algorithms.

SOA is important as it keeps DNS records organized and ensures that the authoritative nameserver is known.

With these out of the way, the next question is, what routes my requests as an end user to a website or application?

DNS process often occurs “behind the scenes” that only a handful of internet users ever get to play with them directly.

Often than not, it requires no interaction from you or your computer apart from the initial request.

But it can be helpful to know how DNS routes traffic to a web application.

Let’s start with this image that shows a basic flow of the process.

DNS Query Journey and DNS Nameservers
Typical DNS Query Path
  • Root nameservers are the foundation of the internet as it is currently set up. Root nameservers contain delegation information for the top-level domains.
  • TLD nameservers contain the nameserver information collected by your domain registrar.
  • Authoritative nameservers are responsible for providing DNS zone information for your domain. It is here that your registrar stores information and passes it up to the TLD nameservers whenever needed.

Because of space, we left out DNS recursive nameservers.

A DNS recursive nameserver is the server that communicates with several other DNS servers to hunt down an IP address and return it to the client.

DNS Query Journey and DNS Nameservers

When you pull up your favorite web browser, type an address (www.example.com) in the bar, and hit Enter, this is pretty close to what happens:

  1. The request for www.example.com is routed to a DNS recursive resolver. Most of these are managed by ISPs (Internet Service Providers).
  2. The ISP DNS resolver forwards the request for www.example.com to a DNS root name server (.).
  3. The DNS resolver for the ISP forwards the request for www.example.com again, this time to one of the TLD name servers for .com domains.
  4. The name server for .com domains answers the request with the names of the name servers associated with the example.com domain.
  5. The DNS recursive resolver chooses a name server (e.g.: a.iana-servers.net) and forwards the request for example.com to that name server.
  6. The authoritative nameservers look in the example.com hosted zone for the www.example.com record, get the associated value, such as the IP address for a web server, 93.184.216.34, and return the IP address to the DNS resolver.
  7. The ISP DNS resolver now has the IP address that you need. It returns that value to your web browser and also caches (stores) the IP address for example.com for an amount of time (TTL) that the DNS administrator has specified (TTL = 38368) so that it can respond more quickly the next time you browses to example.com.
  8. Your web browser then sends a request for www.example.com to the IP address. The IP address can be described as the configured endpoint with the website content you requested.
  9. Once found, the web server at 93.184.216.34 returns the web page for www.example.com to your web browser, and the web browser displays the page.

This of course is in most cases instantaneous that you are not even aware of it.

Again, please note that an over-simplification of the DNS process.

Why Learn How To Troubleshoot DNS As A cPanel User?

The question you have been asking yourself perhaps is, “umm … why do I even need to learn how to troubleshoot DNS if I have my web hosting provider’s technical support team?”.

Let’s use an imaginary scenario.

You have completed the process of purchasing a web hosting account.

Your web hosts (e.g. Web Hosting Magic) have sent via email the information you need to log in to your cPanel and start building your website or creating email addresses.

You used our 1-lick website/app installer to install, for example, WordPress, etc.

However, when you visit the domain you installed the application on, you notice that it is either:

  • redirecting to another website or;
  • your browser is unable to load the domain or;
  • that it has no SSL/TLS certificate

Before freaking out, you pulled up your DNS ninja-fu and decide to check the IP address that the domain is hooked to:

dig A myexampledomain.com

You noticed that you have forgotten to make the needed changes at your domain registrar.

You logged in to your domain registrar’s DNS dashboard, reduced the TTL to 300 seconds, added the new IP we sent to you, cleared your browser cache, and voila … your website is up.

The same applies to your NS (nameservers).

Every domain (or subdomain) you host with us has access to a free SSL/TLS certificate

So this can also apply to a situation where the website you are hosting with us is not running under HTTPS.

Since our system requires your DNS records to be valid, it will simply refuse to uninstall an SSL/TLS certificate on the domain.

Take another scenario where you want to know if DNSSEC is enabled on your domain.

This is very useful when your domain can resolve on some networks, but not in others.

You have just remembered that your registrar supports DNSSEC but not entirely sure if this has been enabled or not.

So you made the decision to use dig to verify DNSSEC records:

% dig www.example.com +dnssec +short

or

% whois example.com | egrep -i "DNSSEC|signed"

or

dig ds example.com +short

If there is no output, this indicates that DNSSEC is not enabled.

So if you run something as simple as:

% dig A example.com @1.0.0.1

and get something like this:

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10663

it might be because of DNSEEC.

This is especially true because unlike TTL expiration (TTL are relative to the time a name server sends a response to a query), DNSSEC signatures expire at a fixed absolute time.

To verify if the SERVFAIL response is related to DNSSEC, you can “dig” with the +cd flag.

% dig A example.com @1.0.0.1 +dnssec +cd +short

The +cd option provides DNS results without any DNSSEC validation in place.

If a proper DNS response is received when using the +cd option but queries using DNSSEC return a SERVFAIL response, then there is a high probability that the domain DNSSEC is misconfigured.

A situation like the one above can develop if authoritative DNS providers are changed without updating or removing old DNSSEC records at the registrar.

With this info, you hazard a guess that this could be (among other things – elimination principle) because of DNSSEC.

So you disabled DNSSEC on the domain at the registrar (where the domain was purchased) or rotated the DNSSEC key and voila, your website comes online.

Before disabling DNSSEC, deactivate DNSSEC at your domain registrar to ensure that DNSSEC-validating resolvers can still resolve names in the zone.

The DNSSEC Hedgehog

Now, there are several tools that anyone even with the most basic command-line skill can use to acquire DNS information.

dig

Let’s start with “dig” which we have seen above.

dig stands for Domain Information Groper.

It is a network administration command-line tool to query for any type of record information in the Domain Name System (DNS).

“dig” has more functionalities than older tools such as nslookup (available as an option in macOS and Windows).

Using “dig” is easy.

For example, to lookup the IP(s) associated with a hostname (A records):

dig +short example.com

To get a detailed answer for a given domain (A records):

dig +noall +answer example.com

To query a specific DNS record type associated with a given domain name:

dig +short example.com A|MX|TXT|CNAME|NS

To get all types of records for a given domain name:

dig example.com ANY

To specify an alternate DNS server to query:

dig @8.8.8.8 example.com

To perform a reverse DNS lookup on an IP address (PTR record):

dig -x 8.8.8.8

To find authoritative name servers for the zone and display SOA records:

dig +nssearch example.com

To perform iterative queries and display the entire trace path to resolve a domain name:

dig +trace example.com

You can find more information on “dig” at https://manned.org/dig

Let’s look at a similar tool: nslookup.

nslookup

nslookup (name server lookup) is also a network administration command-line tool to query the Domain Name System (DNS).

To query your system’s default name server for an IP address (A record) of the domain:

nslookup example.com

To query a given name server for an NS record of the domain:

nslookup -type=NS example.com 8.8.8.8

To query for a reverse lookup (PTR record) of an IP address:

nslookup -type=PTR 54.240.162.118

To query for ANY available records using TCP protocol:

nslookup -vc -type=ANY example.com

To query a given name server for the whole zone file (zone transfer) of the domain using TCP protocol:

nslookup -vc -type=AXFR example.com name_server

To query for a mail server (MX record) of the domain, showing details of the transaction:

nslookup -type=MX -debug example.com

To query a given name server on a specific port number for a TXT record of the domain:

nslookup -port=port_number -type=TXT example.com name_server

Running nslookup on a domain by default will respond with the resolver or nameserver that delivers the response for the domain in question.

For example, if we perform a nslookup on example.com in an environment that uses Cloudflare’s open resolvers (1.1.1.1, or Google’s 8.8.4.4, etc):

% nslookup example.com

it will provide us with this response:

Server:     10.1.0.1
Address:    10.1.0.1#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

Please note that, unlike dig, nslookup does not use the operating system’s local Domain Name System resolver libraries to perform its queries.

nslookup uses its own internal resolver.

If you are on Windows and need something with better capabilities, we recommend installing Windows Subsystem for Linux to use “dig”.

You can find more information on “nslookup” at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup

There are other tools including “hosts“, “ping“, “curl”, “whois”, “iperf”, “tcpdump“, etc.

Our focus is humble though and it is how these relate to cPanel and web hosting.

Let’s look at a likely or probable scenario.

If you have gotten your cPanel username and password credentials, you can use the interface at cPanel Advanced >>> Track DNS to retrieve DNS information.

This is similar to “traceroute“.

traceroute can be used to determine the response delays and routing loops in a network pathway across packet-switched nodes.

traceroute also records the time taken for each hop the packet makes during its route to the destination.

That means that you can use it to locate any points of failure encountered while en route to a certain destination.

% traceroute $example.com

traceroute (installed by default on just about every Linux distribution and macOS) is a simple tool to show the pathway to a remote server.

If you are on a Windows system, you can:

  1. Go to the Start menu.
  2. Select Run.
  3. Type in “cmd” and then hit “OK”.
  4. Type in “tracert [hostname]” and press enter.

For example, if you are logged in to your cPanel, you can use traceroute to find networking issues on a specific TCP port.

% traceroute -T -p 25 smtp.gmail.com

Bonus: You might want to explore mtr.

mtr combines much of the functionality of ping and traceroute into one interface.

brew install mtr (requires root privileges)
sudo apt-get install mtr
dnf install mtr
yum install mtr
pacman -S mtr

Where are we at?

Ah … OK .. cPanel Track DNS.

cPanel’s Track DNS can help you retrieve network information.

Let’s say you want to view your current DNS status.

You can use visual tools such as http://leafdns.com/ or https://intodns.com/

But you know you have an inn-built cPanel you can use to do this.

When you visit the at cPanel >> Advanced and click on Track DNS, there are two options:

Domain Lookup

The Domain Lookup tool allows you to find out the IP address of any domain, as well as DNS information about that domain.

All you need to do to look up a domain is to enter the domain to look up in the Enter a domain to look up the provided text box and click Look Up.

The domain’s mail servers and IP address will display.

You can also view the domain’s DNS information under the Zone Information heading.

Trace Route

Similar to its naked incarnation we used above, you can use Trace Route to trace the route from the local machine you are accessing cPanel from, to the server your site is hosted on.

That is, you can get the number of servers and what servers your data must pass through to get to your site.

Please note that before you can use Trace Route via cPanel, the System Administrator must have the traceroute enabled.

The information provided is basic though.

So, depending on your mileage, there is always the good ‘old command-line option that no GUI can truly replicate.


We hope that you have gotten something out of this.

Thanks for reading.


Posted

in

,

by

%d bloggers like this: