CodeCanyon Global DNS - WordPress Plugin

Guide to Setting Up and Using CodeCanyon Global DNS

CodeCanyon Global DNS is not meant to dress up the WordPress admin area. It is built for a specific operational task: giving a site owner, webmaster, or client a convenient form they can use to check a domain's DNS records from different servers and quickly understand where the website, email, or a specific subdomain record is pointing right now.

This guide walks through how to approach plugin installation, which server requirements to verify in advance, how to configure the list of check nodes, when to enable dark mode, how to display the checker on a page with a shortcode, and how to interpret the results without jumping to false conclusions. We will also cover a practical site migration scenario, because that is when DNS checking is usually needed not just out of curiosity, but to make an actual decision.

It is important to separate DNS checking from DNS management right away. The plugin does not replace your registrar panel, Cloudflare, Route 53, or hosting control panel. It helps you see what different check servers are returning, which makes it useful after changing A, CNAME, MX, TXT, NS, and similar records. If you need to edit the domain zone, that happens with your DNS provider. If you want to give users or staff a clear verification tool inside WordPress, that is exactly where Global DNS fits.

This material is written as a practical guide, not a rehash of the product listing. So below you will find not only the plugin's capabilities, but also preparation, limitations, a verification workflow, common mistakes, safe fixes, and a comparison with similar tools.

What Problem DNS Checking Inside WordPress Actually Solves

DNS usually only gets attention when something goes wrong: after a site migration, the site opens for one person but not another; email stops receiving messages; a new TXT record for domain verification is not visible to the service; or a client says "the record has already been changed," while the check still shows the old IP. In cases like these, you do not need a general DNS explainer. You need a fast way to compare responses from different servers and pinpoint where the mismatch is happening.

Global DNS brings that workflow into WordPress. You can place a form on a public page where the user enters a domain, selects a record type, and runs the check. In the admin panel, the administrator configures servers, colors, dark mode, and output settings. The official screenshots show that the front end is built around a domain field, a record type dropdown, a Find button, a map, and a list of servers. That matters because the product does more than run a query. It presents the result in a way that makes sense to someone who does not want to manually run dig or nslookup.

Scenarios where the plugin is especially useful:

• A web studio manages multiple client sites and wants to offer a "check DNS" page without sending users to third-party services.
• A hosting project or domain service wants to add a useful support tool to its website.
• A WordPress administrator regularly checks A, MX, NS, CNAME, TXT, and similar records after site migrations, email setup, or domain verification changes.
• A technical support team wants a fast way to show a client that different servers can temporarily return different answers.
• A developer is building an internal team tool and wants to configure the list of check servers for specific regions.

That said, do not expect magic from the plugin. DNS records do not "spread out" across the world like a file being distributed to every server. In practice, the user sees the combined effect of caches, TTL, authoritative servers, the local resolver, the ISP, and sometimes even the browser. That is why reading the result correctly matters more than seeing a nice checkmark on the map: if one node still sees the old IP, that is not always a configuration error, but it is a reason to identify which server is returning the old value and how long the cache might still remain in effect.

Who This Plugin Fits, and When Another Format Makes More Sense

Before installing it, define the tool's role on the site honestly. Global DNS works well as a user-facing DNS checker inside WordPress, but not every project needs a plugin like this in production. It performs network checks, relies on a server list, may depend on PHP server functions, and displays a public form. This is not a decorative block you can turn on and forget about.

When Global DNS Is a Good Fit

The plugin works well on sites where DNS checking is itself part of the service. A hosting company, domain reseller, WordPress support agency, technical blog, or internal knowledge base can offer visitors a tool that solves a real task. In that case, the form does not feel random. It helps the user verify configuration results and can reduce support volume.

Another strong use case is an internal team site. If developers frequently change test subdomains, verify TXT records for email services, or compare responses from regional nodes, it is more convenient to have one familiar interface in WordPress than to keep passing around links to external services. It is especially useful that the server list in the admin area can be expanded: the product listing states there is no limit on the number of servers, and the official Servers - Global DNS screenshot shows the fields Name, URL, Longitude, Latitude, and Country.

When the Plugin May Be Unnecessary

If you only need to check a domain once after a site migration, using an external DNS checker is usually easier. Installing a plugin for a single check creates extra support surface: you have to watch updates, compatibility, security, and server settings. For a small blog where DNS changes happen once every few years, a tool like this is usually unnecessary.

Global DNS may also be a poor fit if your hosting provider blocks the functions required for the mode you need. The official page states that WHOIS requires fsockopen and outbound TCP port 43, and that retrieving DNS records directly by DNS server IP in versions that support that feature requires shell_exec. On many shared hosting environments, shell_exec is disabled for security reasons. That does not make the plugin bad, but it does change the rollout plan: check the requirements first, install second.

Practical takeaway: use CodeCanyon Global DNS where DNS checking is part of the product, support workflow, or an internal process. For a one-off personal domain check, an external service is usually simpler and safer.

What to Verify Before Installing It on WordPress

Because the plugin works with network requests, preparation matters more here than it would for a simple shortcode block. Good preparation saves time: you understand in advance which features will be available, which ones are better left off, and why the result may differ from what external services show.

WordPress Version and Hosting Environment

The CodeCanyon attributes list WordPress versions in the 4.9.x to 5.3.x range. That does not necessarily mean the plugin will fail on newer installs, but it does mean that compatibility should be tested on a staging copy, especially if the site is running a modern version of WordPress, current PHP, and a hosting platform with a strict security policy. Do not install a network diagnostic tool directly on a critical site without testing it on a copy first.

Minimum checklist before installation:

• Create a backup of files and the database, or confirm that your host already has one.
• Check the PHP version and the list of disabled functions, especially shell_exec.
• Verify whether outbound connections to external servers are allowed if you plan to use WHOIS or remote check nodes.
• Make sure the site administrator understands where the form will be published and who will be able to use it.
• Prepare a test domain or subdomain where you can safely change records and compare the results.

WHOIS, Port 43, and Hosting Restrictions

The WHOIS feature is useful when you need to quickly retrieve registration details for a domain or IP, but it depends on network access. The PHP function fsockopen opens a socket connection, and WHOIS typically uses TCP port 43. If your hosting provider blocks that port, the form may still work for DNS records, but WHOIS may return an error or an empty response.

This is not something you should try to work around. The right approach is to ask your hosting provider whether outbound connections are allowed for that use case. If the answer is no, it is better to disable or hide the WHOIS feature in the public interface than to leave users with a button that fails all the time.

Direct DNS Server IP Mode and shell_exec

The official description mentions a separate mode: you can use a DNS server IP to retrieve DNS records directly, but that requires shell_exec. From a security perspective, this is a sensitive area. Even after fixes in current versions, the administrator should understand that running system commands on hosting always requires a careful update policy and a minimal public attack surface.

If shell_exec is disabled, do not enable a mode that depends on it. Use servers that work through URL-based nodes instead, or decide whether the plugin's standard workflow already covers your needs. If the function is enabled, keep the plugin updated and do not expose the tool without limits on a site where any visitor can generate excessive request load.

Installation and the First Check Without Risking the Live Site

Installing a commercial WordPress plugin usually means uploading a ZIP archive through the admin panel. The official WordPress documentation describes the standard path: go to Plugins - Add New, choose Upload Plugin, upload the archive, click Install Now, and activate the plugin after installation. Global DNS follows the same pattern, but after activation it is better not to rush into publishing the form immediately.

Installation Sequence

1. Install the plugin on a staging copy or test site.
2. Activate it from the Plugins screen.
3. Check whether Global DNS appears in the left-hand WordPress menu.
4. Open the plugin settings and save the basic parameters without changing any risky modes.
5. Go to the servers section and confirm that the node list displays correctly.
6. Create a test page, add the shortcode from the plugin panel, and open the page in incognito mode.
7. Check one domain with an A record, then test another record type such as MX or TXT.

If the form does not appear at this stage, do not immediately start changing PHP settings. First, make sure the shortcode was added as an actual shortcode block, that the editor did not escape it, and that it was not inserted into a field where WordPress does not process shortcodes. WordPress uses shortcodes as a safe way to add dynamic output to content without placing PHP directly into a post, so the placement matters.

How to Tell the Base Installation Worked

A successful first check looks like this: the menu item opens, the settings save properly, the server list is not empty, the test page shows the form, and after entering a domain you get a result for the selected record type. The official front-end screenshot shows a domain field, record type selector, search button, a location list, and a map. If your form is visible but no result appears, the issue is no longer the installation itself. It is in the network check, the server node, the record type, or a hosting limitation.

Quick takeaway: first get a response from a simple A record lookup for a familiar domain. Only after that should you move on to WHOIS, DMARC, SPF, blacklist, SMTP test, and other tools if they are available in your version.

Configuring Global DNS After Installation

The plugin becomes genuinely useful only after configuration. If you leave everything at its defaults and just insert the form, users will get a tool, but you will not control the appearance, the list of check servers, expectations around the result, or the actual workflow. Your setup should answer three questions: where to check from, how to present the result, and what to do when responses do not match.

Basic Appearance Settings

The official Settings - Global DNS screenshot shows several key parameters: Primary Color, Dark Mode, Dark Mode Color, and Secret. In a typical setup, it is enough to configure the main color first and see how the form looks on the page. Do not enable dark mode just because it exists. If your site uses a light theme and the form appears inside a white content block, dark mode can feel out of place.

Recommended order:

• Start by matching Primary Color to your theme's button or link color.
• Check the form on a page with a normal background and at mobile width.
• Enable Dark Mode only if the page includes a dark section or a dedicated tool layout.
• After turning on dark mode, adjust Dark Mode Color so fields, text, and markers keep enough contrast.
• Save changes with Save Changes and check the public page, not just the admin area.

The Secret parameter in the screenshot is described as a way to authenticate the site with different servers. Change it deliberately: if you already have remote servers configured, a mismatched secret can cause the main site and the server node to stop recognizing each other. If you are not sure, first record the current value in a safe place within the project documentation, then change it and test one server.

Configuring Check Servers

The Servers section is the most product-specific part of Global DNS. This is where you define the nodes the checks run from. In the official screenshot, each server has a name, URL, longitude, latitude, and country. This is not just cosmetic reference data: the coordinates and country help display the result on the map and explain to the user why responses from different regions may differ.

When adding servers, think in terms of coverage, not quantity for its own sake. If all servers live in the same data center, your "global" check will only look global on the surface. Fewer nodes from genuinely different networks and regions are better. For an agency, it is enough to cover the main countries where clients are located. For a public service, you can widen the map, but then you need to monitor both load and availability for every node.

After adding a server, always run at least one query against a domain with a known stable record. If the server responds slowly, check whether it exceeds a reasonable timeout. The plugin changelog mentions that timeouts were added for DNS and WHOIS requests, but that does not remove the need to choose stable nodes.

Shortcodes and Placement

The CodeCanyon screenshots show that the plugin menu includes a Shortcodes section. You should take the actual shortcode from your installed version, because names and parameters may have changed. Do not copy a shortcode from someone else's article or from an old screenshot. Open the plugin section, copy the current version, and insert it into a WordPress page through a shortcode block or a plain text editor that processes shortcodes.

The best place for the form is a dedicated page with a short explanation and clearly defined expectations. Do not place a DNS checker in the footer, sidebar, or a popup: users enter a domain, wait for a network response, and compare results, so they need a calm, full-width area to work in.

How Servers, Record Types, and Results Work Together

To avoid bad conclusions, you need to understand the mechanics. The user enters a domain and chooses a record type. The plugin sends requests to the configured server nodes. Each node returns its own result, and the interface collects the responses into a list and visual display. If different nodes return different values, that does not always mean something is broken. It is a signal that some resolvers or check points see the old record, the new record, an error, or no record at all.

DNS Record Types and Real-World Scenarios

The official page says the plugin supports multiple DNS record types and mentions 10 record types. The description explicitly names A, MX, NS, CNAME, TXT, and "much more"; WP Solver also mentions CAA and SRV. In the article, it is better not to promise a full exact list for every version. Check the dropdown in your installed copy instead. But the practical logic looks like this:

• A and AAAA help you see which IPv4 or IPv6 address the site points to.
• CNAME matters for subdomains, CDNs, SaaS services, and www verification.
• MX is used when diagnosing inbound email.
• TXT is needed for SPF, DKIM, DMARC, domain verification, and many external services.
• NS helps verify which name servers are visible for the domain.
• CAA and similar technical records are worth checking if they appear in your version's list and are genuinely needed for the scenario.

A common mistake is checking the wrong record type. For example, a user changes MX but looks at the A record and concludes that "email has not propagated." Or they add a TXT record for SPF but enter the domain with an unnecessary subdomain. It is useful to place a short explanation next to the DNS checker form so users know which record type to choose for websites, email, and domain verification.

Expected Value and Match Verification

The plugin changelog mentions an "Expected" feature and fixes related to the expected value. If your version includes an expected-value field or button, use it to speed up result reading. The idea is simple: you already know which IP, domain, or TXT record should be returned, and the interface helps highlight whether it matches.

But the expected value should not replace actual DNS understanding. For TXT, order and quotation can sometimes appear differently across tools. For MX, priorities matter. For CNAME, some interfaces show a trailing dot at the end of the fully qualified domain name and others do not. So when the result is unclear, compare not just a green or red indicator, but the response text itself.

Why Different Servers Return Different Answers

Cloudflare explains in its TTL documentation that TTL controls how long a record is cached, and longer TTL values make repeated DNS responses faster at the cost of slower change rollout. Google Public DNS also offers a separate cache flush tool, which shows that some mismatches are directly tied to caching. That is why a useful interpretation of Global DNS results usually looks like this:

• If all servers return the new value, you can move on to checking the site or email service.
• If some servers still return the old value, wait for the TTL to expire and check again.
• If all servers still return the old value, verify that the record was actually published by the authoritative DNS provider.
• If one server regularly fails or comes back empty, check the node itself, not just the domain.
• If the result differs only in formatting, compare the record manually and do not rush to conclusions.

Practical Scenario: Checking a Site Migration to a New IP

Let us look at the situation that most often leads to questions like "why does my site still open the old way." The site is being moved to a new host, the root domain's A record and the CNAME for www have been updated at the DNS provider, and now you need to know whether different check nodes can already see the new value and whether it is safe to ask the client to test the site.

Goal

You need to confirm that the domain is gradually starting to return the new IP, and that any differences between servers are explained by cache rather than by a record error. The end result should be a clear report: which nodes already see the new value, which ones do not yet, and what to do next.

Preparation

Before you begin, record three values: the old IP, the new IP, and the domain you are checking. If there is a www subdomain, check the root domain and www separately, because those may be different records. If you lowered TTL in advance, note the old and new values in your working notes, but do not promise the client an exact rollout time down to the minute.

Verification Steps

1. Open the page with the Global DNS form in a separate browser window.
2. Enter the root domain without https:// if your version of the interface does not require the full URL.
3. Select the A record type and run the check with Find.
4. Compare server responses against the new IP and the old IP.
5. If expected-value checking is available, enter the new IP as the target value.
6. Repeat the check for www and the CNAME or A record type, depending on your setup.
7. Save the result in your working report: not just a screenshot for appearance, but a list of nodes that are still returning the old value.

Verifying the Result

A good result means most servers are returning the new IP, and the remaining ones gradually catch up after their cache expires. A suspicious result is when all servers still return the old IP after you have already confirmed that the record was saved at the DNS provider. In that case, check the authoritative NS records, the exact domain being tested, and whether there is proxying or a hidden zone on the provider side.

A Detail That Often Gets in the Way

Do not mix up DNS verification with website verification. DNS may already be returning the new IP, while the site on the new server still shows old content because of cache, an incorrect virtual host, the SSL certificate, or WordPress settings. After the DNS check, open the site in a browser and verify SSL, headers, and the actual server response. Global DNS answers the question "where does this record point," but it does not validate the entire website stack.

Useful Settings for a Public DNS Checker Page

If the form will be available to visitors, it needs to be designed not just technically, but editorially as well. Users should understand what to enter, which record type to choose, and why the result may differ temporarily. That matters even more for audiences seeing A, MX, or TXT in one list for the first time.

Tool Page

Create a dedicated page with a short introduction, the form, and a block of explanations. At the top, you can write: "Enter the domain without extra parameters, choose a record type, and compare the server responses." Below the form, add five or six short notes about record types. Do not turn the page into a DNS encyclopedia, but give the user enough context so they do not just check everything at random.

If your site is focused on hosting or support, you can also add common tasks next to the form:

• Check an A record after a site migration.
• Check MX records after setting up email.
• Check a TXT record for SPF, DKIM, DMARC, or domain verification.
• Check NS records after changing DNS providers.

Limiting Load and User Behavior

A public DNS form can create load: every user request triggers checks across multiple servers. If traffic is low, that is not a problem. If the site is busy, add simple limits at the page, cache, request-throttling, or server-rule level. Do not promise users "instant" results under all conditions: network requests may slow down because of a remote node, a timeout, or hosting restrictions.

If the site has a caching or optimization plugin installed, check whether it breaks the form's scripts and styles. The DNS checker needs to work dynamically, so aggressive JavaScript bundling or deferred loading can cause the button to stop triggering the check. Start diagnosis by disabling optimization only for the tool page, not for the entire site.

A Small CSS Tweak for the Tool Page

If the form visually clashes with the theme, it is better to start with Primary Color and Dark Mode Color. Only add CSS for the page container where you can clearly see your theme's classes. The example below is a safe wrapper: it does not touch plugin files and simply adds spacing around the shortcode block on a specific page. Add the dns-tool-page class to the page container through the editor or theme template if your theme supports that.

.dns-tool-page .entry-content {
  max-width: 1120px;
  margin-left: auto;
  margin-right: auto;
}

.dns-tool-page .entry-content form {
  margin-top: 24px;
  margin-bottom: 24px;
}

.dns-tool-page .entry-content input,
.dns-tool-page .entry-content select,
.dns-tool-page .entry-content button {
  min-height: 42px;
}

The check is simple: add the CSS in a child theme or the Additional CSS section, clear the page cache, and open the form at desktop and mobile widths. If the fields become too large or your theme already applies its own styling, remove the snippet and go back to the plugin settings. Do not edit the plugin's own files: those changes will be lost during an update.

Checking the Result After Configuration

After installation and setup, it is important to verify more than just whether the form appears on the page. You need to walk through the full user flow: entering a domain, selecting a record type, waiting for the result, reading the server list, checking the map, repeating the query, and seeing how the interface behaves when an error occurs.

Functional Checklist

• The form opens for a guest, not just for the administrator.
• The domain field accepts a domain without a protocol and does not break if the user pastes a full URL.
• The dropdown shows the record types you actually need for your use case.
• The search button starts the request and shows a waiting state.
• The result appears for multiple servers, not just one.
• The map and the location list match the server settings.
• An invalid domain or unsupported record type does not break the page.
• A repeat query does not require a page reload, if that is how your interface version is designed.

Checking Different User Roles

Open the page as an administrator, editor, and logged-out visitor. If the form is only available to logged-in users, check the theme settings, page restrictions, membership or access-control plugins, and cache behavior. If the page is public, make sure it does not expose internal secrets, internal node addresses, or details that visitors do not need to see.

Security Review After an Update

This is especially important for Global DNS. Public security sources document a remote code execution vulnerability in versions prior to the fixed 3.1.1 release, and the CodeCanyon changelog also lists fixes for DNS lookup, DMARC, SPF, WHOIS, shortcode templates, IP lookup, and blacklist checker API. So after installation or an update, verify that you are using the fixed version and that the public form is not still running from an old archive in production.

You do not need to frighten users with technical terms on the tool page, but the administrator must keep this in the operational checklist. Network tools that accept user input require regular updates, validation, and the removal of unnecessary features.

Security, Updates, and the Limits of a Network Tool

Global DNS has one characteristic that should not be glossed over: the product works with domain names, IPs, network requests, WHOIS, and user input. That is useful, but it also requires discipline. Public security sources report that the remote code execution issue was fixed in version 3.1.1, and the official changelog after that includes several entries about validation and vulnerability fixes in related APIs. In practical terms, that does not mean "do not install the plugin." It means "install it only with updates and verification."

Minimum security policy:

• Do not use an old archive if a fixed version is available.
• Do not enable modes that require shell_exec unless your scenario truly needs them.
• Do not place the public form on a high-traffic page without request rate limits.
• Do not expose technical secrets, internal server URLs, or debug messages to visitors.
• Do not roll the plugin back to an old version just to fix a CSS conflict.
• Check the error log after updates, especially if you use WHOIS, SPF, DMARC, blacklist, or SMTP test.

One important detail: a commercial CodeCanyon plugin may not update through the standard WordPress.org directory unless the author provides a separate update mechanism. That means the administrator needs to track the changelog and the archive source manually. If you maintain a client site, add Global DNS to the list of components reviewed during regular technical maintenance.

Do not treat a network tool as something you can install and forget. That is especially risky for a DNS checker: the public form accepts input, and some features may interact with external servers or PHP system capabilities.

When CodeCanyon Global DNS Is Worth Using

CodeCanyon Global DNS is a strong choice if you need a DNS record verification tool built into WordPress, are prepared to configure check servers thoughtfully, can explain the results to users, and are willing to keep the plugin up to date. It is especially appropriate for hosting projects, agencies, technical portals, and internal support dashboards where DNS checks happen regularly.

Before deployment, verify your hosting requirements, test WHOIS and any modes that depend on system functions, configure servers deliberately, and do not base conclusions on a single checkmark. Good use of the plugin is not just a form on a page. It is a clear workflow: the user enters a domain, selects the needed record type, sees responses from different servers, and understands what to do next.

If, after reviewing everything, you decide the product fits your scenario, you can get the CodeCanyon Global DNS file and deploy it on a test copy of the site first. That approach is safer than installing it directly in production: you can verify compatibility, server functions, the shortcode page, the appearance, and the update path without risking the live visitor experience.

If instead you only need a one-time DNS lookup, do not want the overhead of maintaining a separate plugin, or your hosting environment blocks key functions, use external services and keep WordPress simpler. The right choice here is defined not by the number of features, but by whether the tool will genuinely help users solve DNS-related tasks faster and more clearly.