One place for hosting & domains


      Advanced Troubleshooting DNS Problems

      The most common DNS error is a simple typo, whether it’s from the client or the server. Typos and other incorrect DNS data cause many problems. Even when data is correct, DNS can still be a difficult protocol to troubleshoot.

      The DNS process starts at the client, which queries a specified upstream DNS server. The upstream DNS server could already have the answer in its cache. In which case, an IP address is answered and the query is resolved. If not, it queries further upstream until a successive answer is given, which is authoritative for the query. The Top Level Domain (TLD), such as a .com, .net, or org, may be the root authority for a query. Authoritative servers on a local network may also be the correct resolver.

      Possible causes of unsatisfied queries include:

      • No network circuit path from the client to the specified DNS server.
      • The specified DNS server might not have the query credentials needed.
      • The cached information on the specified DNS server could be out of date.
      • The specified DNS server may have no upstream path to a TLD server.

      Fortunately, there are a variety of tools available for Windows, macOS, and Linux used to troubleshoot DNS problems. Most DNS troubleshooting tools focus on tracing the circuits to a DNS resolver or querying DNS servers for a correct response.

      Tracing the Resolver Network Circuit

      Clients must be able to reach the DNS server with a query. The most common failure is an interruption in the network circuit between the client app and the desired DNS server.

      Each client declares a default DNS server for DNS queries. If the address of the default DNS server is incorrect, or points to an unavailable resource, there can be no resolution to the request. In this case, the requesting application receives an error, or simply hangs. The IP address of the default DNS server must be known to troubleshoot further.

      The IP address of the default DNS server is found in the properties of the network adapter in use. To find yours, follow the instructions below for your operating system:


      1. Right-click the network icon in the Notification Area of the Taskbar.

      2. Choose Network and Internet Settings.

      3. Select your network adapter.

      4. Scroll down to reveal the settings for that network adapter.


      1. Click the network icon in the Menu Bar.

      2. Click Network Preferences.

      3. Select your network adapter.

      4. Click Advanced.

      5. Click DNS to reveal the settings for that adapter.


      In Linux, the location of the desired DNS server depends on the values set in the resolver configuration file located at /etc/resolve.conf.

      To find these values via the command line, enter:

      cat /etc/resolve.conf

      To find these values via the GUI in Ubuntu 22.04 LTS:

      1. Click network icon in the GNOME Panel.

      2. Select your network adapter.

      3. Click <adapter/connection/device> Settings.

      4. Click the gear icon next to your chosen adapter/connection/device

      Knowing the desired address helps trace the circuit to determine if the desired DNS server can be reached.

      Circuit Testing with Ping

      Troubleshooting the network communications circuit uses common tools like ping. Many queries fail because there is no network circuit to the desired DNS server. The ping command line tool is universal to all operating systems and does not require administrative rights.

      Open a command line and use ping to determine if the IP address responds. In this case, the public DNS server for Cloudflare ( is cited:




      When a reply is returned, queries can be made to the server, in which case, skip to the next section.

      If there is no reply using ping, then the circuit is unusable and the requested resolver is not responding. This can be because it’s under attack, dead, or offline. Specify another resolver/DNS server and repeat the attempt.

      An unusable circuit, or route to a DNS server, means that an Internet connection is down for the host making queries. If the circuit is up, another DNS server can be used, and must be placed in the host’s settings. Reset the host to restart the network stack and read the new DNS server entry. Such alternate DNS Internet servers are for Cloudflare, and for Google.


      The traceroute command line tool is also handy in network circuit analysis. It uses either an IP address or a Fully Qualified Domain Name (FQDN) to show latencies between the host and the desired IP address/FQDN.

      Tracing Resolvers with NSLookup

      Windows, macOS, and Linux contain the command line tool, nslookup (Name Server Lookup). It performs a query on a known address, using the default DNS resolver, unless another resolver is specified.



          Non-authoritative answer:
          Addresses:  2607:f8b0:4004:c19::8a

      Here, the default nameserver is’s public DNS server (, with an IP address of It uses a cached (non-authoritative) answer for the queried server ( It then renders three lines of IPv6 addresses and six lines of IPv4 addresses.

      When there’s a working network circuit available, nslookup permits changing the nameserver so that entries among differing nameservers can be compared. When a TLD FQDN entry is changed, it can take as long as 48 hours to be uniform among nameservers/resolvers. This is because non-authoritative servers cache entries using a Time-To-Live (TTL) variable for speedier response. The answer is delivered from cache, without looking up the answer on the next higher-level server. When the cache expires on DNS servers/resolvers/nameservers, a request from a higher authority renews the cached and delivered answer.

      Start of Authority (SOA)

      Every domain used publicly in DNS has a registrar. The registrar keeps a record of ownership, which may not be visible to the public. The entry in this record that must be made public is the IP address(es) of its nameservers. The nameservers/resolvers, in turn, are the guardians of the DNS for TLDs.

      An organization that hosts a domain generally also contains its nameserver, and is the SOA for the domain and any subdomains underneath it. TLD resolvers such as .com, .net, and .org, are highly controlled. They are only accessible through other servers using the DNS Security Extensions (DNSSEC) authentication and security protocol.

      Hosting organizations like Linode may also use other Content Distribution Networks (CDNs) who provide a presence where heavily-used sites manage IP and DNS access. CDNs are not covered by this guide, because their troubleshooting often requires tools that only the CDNs can provide. Nonetheless, these sites must respond appropriately when a host makes a query.


      The most popular client-side DNS query tool beyond nslookup is dig (Domain Information Groper). The dig app must be downloaded to Windows as part of the
      bind package, which also includes an optional DNS server. The dig command is included with most versions of macOS and Linux.

      The dig tool allows specific DNS records to be queried. This includes MX (mail), A records (domain), TXT records (specifically recorded details), and other host records included in the SOA nameserver.

      An example of the dig output shows its command line configuration:


      The output looks similar to:

      ; <<>> DiG 9.16.30 <<>>
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54592
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
          ; EDNS: version: 0, flags:; udp: 1232
          ;; QUESTION SECTION:
          ;                	IN  	A
          ;; ANSWER SECTION:
         	300 	IN  	A
         	300 	IN  	A
         	300 	IN  	A
          ;; Query time: 62 msec
          ;; SERVER:
          ;; WHEN: Thu Jul 14 17:11:03 Eastern Daylight Time 2022
          ;; MSG SIZE  rcvd: 87

      Options for the dig command include:

      • +trace, which queries DNS servers to the SOA.
      • ANY, which finds ALL records, not just the default A record.
      • +f <filename> which calls the hosts listed in the specified file.

      The SOA can be found, and the path to it queried, to see if records match. This allows DNS resolvers along the path to the SOA to be adjusted for longer/shorter TTL caching. This accommodates records that change frequently, such as DynamicDNS records in Active Directory environments.

      Domain Transfers

      When a domain transfer occurs between nameserver registrations, it takes time to propagate to the hundreds of thousands of resolvers that might be contacted. The dig command is the handiest tool to find outdated cache or incorrect entries.

      The Hosts File

      Windows, macOS, and Linux look to a hosts file before trying to resolve a DNS address. The hosts file pre-dates DNS in many ways, and takes precedence over DNS or attempts to use a resolver.

      When present and filled in, the hosts file is the first resolver in any host. In Windows, this file is located in the \system32\hosts entry. On macOS and Linux, it’s located in the /etc/host file.

      The hosts file is canonical, meaning that it overrides any resolver and cannot be violated. When tracing odd DNS access problems, look for the presence of this file, and use a text editor to examine its contents. Entries may be administratively placed to prevent access to specific sites. It is sometimes used as a “private DNS” to control system behavior and prevent typos from permitting access to typo-based malware sites. The hosts file must be altered to allow subsequent access through a resolver to such sites.

      Walled Gardens and Captive Portals

      Walled Gardens and Captive Ports are terms for the same environment. Essentially, barriers presented by network access providers, such as “Free WiFi” services deployed in public spaces, shops, schools, and government facilities. These offerings are controlled through an access control host/router to a network, whether wired or wireless. All DNS or IP address calls are intercepted, and focused to an authorization device.

      After supplying sufficient credentials, a user is provided either confined or open access. Within the Captive Portal or Walled Garden, DNS calls are often intercepted and routed through local or cloud-based DNS servers/resolvers. They resolve requests using their own entries, which may not be the public DNS entry for a user.

      The “wall” in the Walled Garden provides confined access, typically limiting access to social media, adult websites, or other sites chosen by the provider. Although browser DNS-over-HTTPS protocols can sometimes “leap” over, or bypass, these walls, some browsers do not support this protocol.

      To regain access, re-load the network stack and use a public resolver like Cloudflare’s or Google’s

      DNS Poisoning

      The answers provided by DNS servers are listed in the DNS server/resolver’s tables. Access to these tables is usually highly limited. When DNS is correctly configured for host security, it limits how DNS entries can be changed.

      It’s possible to poison DNS servers intentionally with spurious entries in an attempt to hijack browser activity. When performed by bad actors, these entries can focus browser requests to malware, crypto routines, or competitors.

      Administrators regularly use dig and a file of test hosts to compare changes in entries. The value of the test is to show when the list of hosts has changed, and for what reason. A changed address in a popular site may mean its entry has been hijacked upstream, locally, or even at a TLD server. It may also mean the IP address has simply been changed administratively. Poisoned entries must be deleted where possible.

      Hosting Provider Problems

      A hosting provider, or the domain registrar, can flush DNS cache, including informing upstream/downstream providers where they’re connected. Administrators making changes in DNS entries face a problem with the cache TTL/life in both up and downstream servers. Changes can be quick to propagate where CDN and other services, such as Akamai and Cloudflare, are the stored address for downstream servers.


      Each host provides a mandatory A record that points to the IP of the receiver of domain targets. The CNAME record provides an alias for queries, allowing aliases for “www” or other common domain prefixes.

      DNS MX records point to mail. Most hosting providers run mail through an application, such as cpanel. Email entries for a domain are rejected because of missing mail-focused domain keys used in:

      • Transport Layer Security (TLS)
      • DomainKeys Identified Mail (DKIM)
      • Sender Policy Framework (SPF)
      • Domain Message Authentication Reporting and Conformance (DMARC)

      These entries must be valid, and the mail engine used must comply with the DNS records for the domain.

      Host provider email records are entered in the provider’s DNS record for a domain, or maintained separately by a domain administrator.


      Some host providers and registrars lock DNS records so that they cannot be changed by fraudulent or unauthorized access. To prevent hijacking and fraud, the locks placed on records require obtaining a key, providing credentials, or other verification obstacles.

      The authentication credentials needed to change DNS records should be stored carefully. A re-authentication attempt usually requires time and multiple methods of authentication to obtain. Domain hijacks occur when credentials are guessed, spoofed, or heavily attacked.


      Simple typos are a huge problem. So are network outages that initially appear to be DNS problems. Verifying accuracy and the network path fixes many DNS outages. User/host configuration problems, especially an incorrect default DNS/resolver, can also be quickly checked.

      When resolvers must be checked, the toolkit can be simple. Much information can be revealed about the listings inside resolvers using nslookup and dig. Data can be compared from period to period.

      Complying with a hosting provider’s documentation allows you to keep complete records that cooperate with the provider, their services, and email.

      DNS servers are not invulnerable. They can be poisoned. It’s good practice to check important records on a periodic basis to test listing integrity, especially before users fill the support email box.

      Source link

      Troubleshooting Network Issues – IPv4 and IPv6

      A successful internet circuit from host-to-host usually involves many components: from an application in one host, to an application in the desired target host. This tutorial covers troubleshooting connectivity between apps, and their hosts, whether over IPv4, IPv6, or an IPv6 tunnel over IPv4.

      Applications are usually chained to the network stack and capabilities of the host, therefore troubleshooting communications requires troubleshooting through the layers of the ISO OSI stack: through the host network communications layers, through the network interface card, then along the network path, through gateways, routers, and switches, until it meets the target host.

      It involves a working electrical circuit, correct host protocol information, correctly supplied information from local hosts, and verification that the local host’s network stack works. Proxies can make troubleshooting more complex because you must use application-specific techniques, so this is not covered in detail.

      The differences between troubleshooting IPv4 versus IPv6 stacks is simpler now than it used to be. Major operating systems treat them equally, often as parallel stacks. Troubleshooting IPv4 and/or IPv6 involves testing parallel stacks using parallel and common tools.

      Modern operating systems come with a handful of useful basic commands for the network communications software stack. Windows, macOS, and Linux already have common Unix-like network troubleshooting commands built-in, and other cross-platform testing tools are available to download.

      Troubleshooting Stack Configuration

      To start, you need to ensure you have power. Verify your electrical connection to the first router/switch/gateway leading to the rest of your network or internet.

      Wired Ethernet

      Wired Ethernet connections are generally on the back of the host and router/switch/gateway. Working cable connections are indicated by illuminated LEDs on the Ethernet jacks. For gigabit speeds, both LEDs on the cable jack should be lit, while a single lit LED indicates a 100mbp/s connection. The jack on the connected router/switch must also be lit. If the LEDs are not lit, you have no connection and the circuit is broken. This results from bad cables, bad jacks, wrong or incorrectly wired cables, and electrically dead jacks or routers.


      Where a WiFi connection is used, examine the local host to verify the status of the cable or WiFi connection. The connection must be alive and working according to the host desiring connection. Working WiFi supplicant verification is made either in the host in question, or through the WiFi router administration software.

      Once the electrical circuit and/or WiFi connections are verified, the host software stack becomes the second step in the troubleshooting procedure.

      Network Software Stack

      Next, check host protocol adherence. The basic IPv4 and IPv6 addressing scheme must match the needs of the next downstream device (router/gateway/switch/hub). At minimum, there must be a routable address, a correct network mask, and a gateway address (next hop of a router/gateway/switch that can forward packets). Most network stacks require a reachable DNS IP address or a DNS Fully Qualified Domain Name (FQDN) whose IPv4 and/or IPv6 address can be reached from the host.

      The boot process requires one of three types of suppliers of compliant address information. The first is a user/administrator-supplied static address that is permanent for the host (for fixed installations). The second supplier can be through proxy software, such as Mobile Device Management (MDM) like Microsoft’s Intune or IBM’s Maas360, or other proxy software that automates control of the host IP address. The third and most common supplier of addresses comes from the Dynamic Host Configuration Protocol (DHCP).

      DHCP Troubleshooting

      DHCP clients are configured to receive their IPv4/IPv6-compliant address through the DHCP protocol from a downstream host. If the DHCP address server is offline, a usable address for the host network stack is not available until the working DHCP server is re-contacted by the DHCP client.

      The DHCP address must be delivered within an IPv4/IPv6 range that permits the host address to be routed through the next gateway/switch/router to other downstream gateways, then on to the Internet (or the target host if on a local or private network). Many hosts substitute an IPv4 address if they fail to procure a DHCP address in the 169.XXX.XXX.XXX range, which is a point-to-point protocol for machine-to-machine connections not involving gateways.


      A DHCP server may also consult a RADIUS server for information, but become unusable if the RADIUS server cannot be found. DHCP and RADIUS servers can be combined in the same device, and serve as combined proxy authentication (RADIUS) and supplicant provider (DHCP) when confirming network addresses and credentials.

      If a Linode host requests a DHCP address, it receives an IPv4 and IPv6 address from a pool depending on where the host node is located. If a network host receives DHCP host addresses in the 169.XXX.XXX.XXX range, this indicates that the DHCP server did not supply an address correctly, and communications to the needed DHCP must be tested.

      When an IPv4/IPv6-compliant address is delivered to a requesting host, this address is not considered static. Most DHCP addresses are automatically renewed every 90 days, so dependencies on that IP address by applications are at risk when the address is renewed. If a host has been unavailable with a leased address and is re-introduced to the network, the DHCP server delivers the next available list in its pool, which may be different from previous address.

      DHCP servers test an address before leasing it to a DHCP client. However, users on the same local network may have been assigned a static address within the DHCP range. This causes a conflict because each address must be unique. Duplicate IP addresses cause each host with the same address to receive errors. To fix this, flush the Address Resolution Protocol (ARP) cache on each host assigned a duplicate address, as well as the cache on the DHCP server.

      DHCP servers delivered information can overwrite default settings, and overwrite settings of a default/preferred DNS server. Errors ensue if the default/preferred DNS server contains unique information needed by the requesting host (itself supplied with the wrong DNS server). Users have the ability to name a DNS server in a home environment that may conflict, or not be able to resolve within a local network. Administrative procedures must ensure that local organizational DNS servers take priority, or be listed as the first nameserver/DNS host.

      Host Network Stacks

      Even when the electrical circuit is verified, and the host has an IPv4/IPv6 client address, gateway/router/switch address, and DNS, other trouble may exist in the local host network software stack. Numerous shims can be placed in the stack that perform different steps, such as a VPN, authentication, proxies, unique or settings-specific protocols, and other services that impact network use.

      The host network stack is the currently defined and configured list of settings required to make the host a member of a network. These settings include:

      • Valid network address within the range that can be routed by the next downstream device with a correct network mask, which enables the downstream device to correctly address it.
      • Media Access Control (MAC) address that is unique for that subnet.
      • Gateway address for the downstream device to be a target of packets for routing.
      • DNS address, either user/administrator-controlled or delivered from the DHCP protocol, if not defined locally.

      There may be several software drivers in the stack. For example those needed for VPNs, special protocols, network card driver, and others.

      Troubleshooting the stack may require removing all but the base network address information and hardware driver. This minimal stack must work before other components are added. To verify the integrity of the stack, add services back one-at-a-time and test each new component until a culprit is found. Troubleshooting network stacks requires revealing stack settings for the network hardware in use. Keep in mind there are multiple hardware items in a host, and each has a network stack that controls it.

      All hosts display their stack when administratively accessed settings are chosen. This includes third-party network stack software insertions.

      Revealing The Stack In Windows

      GUI: Right-click the network/WiFi icon on the taskbar.

      CLI: ipconfig

      Revealing The Stack In macOS

      GUI: Click the network/WiFi icon and choose Settings, or go to Apple -> System Preferences -> Network.

      CLI: ifconfig

      Revealing The Stack In Linux

      GUI: Open Network-Manager, or right click the network/WiFi icon

      CLI: ifconfig, if, systemd -network-configuration

      If a Linux instance hosted in Linode needs its network stack revealed, the systemd commands are used.

      Windows, macOS, and Linux hosts all contain the ping command, which uses ICMP messaging, a different protocol than TCP or UDP. Pinging a host reveals if a circuit is complete, indicated by a reply to the ping. A few missing replies means there is latency, jitter, congestion, and/or other intermittent connection characteristics.

      The usual syntax of the ping command line tool is:

      ping <hostname or IP>

      If a route to a DNS server, resolver, or local hosts file isn’t present, ping fails where a fully qualified hostname has been used. If ping can find the hostname through a resolver, then it uses the IP address as its target. If no hostname resolution is found, the IP address of the host is preferable. If there is a reply from the host by IP address only, name resolution has failed, which is a DNS problem. If it’s successful, then the circuit path is good. Ping can show intermediate response slowdowns. The Windows version only shows four replies, but other versions show replies until the program is forced to stop with CTRL-C. Vast differences in response times point to network congestion between the hosts, router latencies, jitter, and/or other circuit problems

      The Windows native command line tool tracert, or traceroute in macOS and Linux, traces each host/gateway/router between two hosts. A better, downloadable cross-platform command line tool, mtr (the Windows Version is called WinMTR), performs an interactive traceroute that reveals jitter and latency between two hosts.


      The Wireshark application is a protocol analyzer that works on Windows, macOS, and Linux. Most commonly used in a GUI, Wireshark captures network traffic seen by a host’s port. The captured traffic is analyzed to determine problems between hosts, and measure traffic on the local routable network.

      Wireshark requires hardware configurations to have full access to a desired network port on a host. Traffic can be viewed in real-time, or captured and analyzed for host pairing of conversations among hosts, and specific protocol analysis. It also permits decrypting IPsec and TLS.

      Firewalls and Other Network Traffic Controllers

      Windows, macOS, and Linux each have stateful firewalls. With exceptions for several standard traffic types, by default, they block all inbound traffic unless an outbound connection has been established to an external host. Each of these operating systems can have optional applications installed as traffic controllers, acting as a secondary firewall. These applications can change firewall settings and increase the complexity of troubleshooting networks.

      In Windows desktop and server editions, Control Panel -> System and Security -> Windows Defender Firewall, lets you examine blocked and permitted ports as well as settings for an Active Directory Domain, Private, and Public context.

      The macOS Firewall is turned off by default, but can be turned on, and viewed through Apple -> System Preferences -> Security and Privacy -> Firewall -> Firewall Options.

      Linux firewall primitives are in the Linux kernel, called netfilter. Netfilter control is provided by iptables, the ufw wrapper to iptables, or firewalld. Like Windows and macOS, Linux distros use a variety of added firewall products, which may or may not be chained to the default iptables (or its update, nftables).

      Third party firewalls on Windows, macOS, and Linux may use different commands, and troubleshooting them is vendor/version-specific.

      Additional network traffic control can be asserted to a host by third party software, typically a directory domain threading system such as Microsoft’s Active Directory, or MDM applications.

      Firewall Programming and Table Insertion

      Firewalls admit or deny host traffic for its protection. Troubleshooting firewalls requires knowing the network traffic types, addresses, and protocols needed by the host, as all others should be denied.

      Firewalls block or admit traffic into a host based on rules. A host usually has a default set of rules that can be user-modified, or inherited from proxy control or other tables of rules. Firewall rules tables must all be administratively protected.

      Depending on the firewall’s rules and added proxy control employed, rules files may be imported into the firewall at when it loads from a local or proxy agent. These modified rules may permit the altering of packets, blocking, admitting, routing, and other movements of network traffic through the host’s network interface(s).

      Once sure you have a working network electrical circuit and a correct client network stack, look for apparent blockages caused by firewall rule errors, rule overreach, and/or limitations imposed on one IP protocol but not the other. Both IPv4 and IPv6 rules should be comparable for the same communications path desired.


      Linux iptables/nftables, UFW, and firewalld, all permit the inclusion of runtime-loaded rules files, which are integrated into the settings directives the host firewall uses. This aids other apps that can form them by learning. An example of a learning firewall aid is fail2ban, which can ban IP addresses directly to the iptables rules as an included table. The fail2ban app regularly re-writes the iptables rules according to its configuration by examining traffic, matching offenders that fail rules, then blocking them specifically in the iptables rules. These rules re-load each time iptables loads – like when you restart or boot a system – and can prevent iptables from passing traffic until tables are loaded into the Linux kernel netfilter framework. This delay can simulate a network failure because traffic is blocked until the potentially large tables are loaded into the framework.

      Third Party and Proxy Network Control Troubleshooting

      Proxy control of hosts requires application-specific techniques. Domain control, remote device management, MDM, and Cloud-Assisted Security Brokers can be inserted in most all modern operating systems as a proxy-authenticator, DNS controller, (site) Access Control List limiter, and general connection blocker. Network access to a specific host by domain, DNS resolution and/or IP address can be controlled by proxy. Proxies may prevent local troubleshooting, and by design, proxy control software operations may be masked at the local host from scrutiny.

      Proxy control software requires testing when inappropriate blockage of site-to-site communications is a function of misdirected control by the proxy, or is the result of another site or service blockage problem.

      Successful proxy control requires a working network path to the proxy controller, often located in the cloud, and proxy control problems likely can’t be performed until the proxy is reached.

      Troubleshooting network control proxy software and its agent/linkage software requires the removal of proxy control. Test whether the proxy stack is delivering incorrect blocks or presenting problems to desired and permitted target sites. If the proxy can be removed, and communication is successful, then troubleshooting points to problems in the network control proxy software stack. Troubleshooting the network control proxy stack is usually performed by a trained administrator or network engineer familiar with the specific software stack.


      If a proxy control is in the network circuit/stack, standard troubleshooting methods may fail. Only the proxy control vendor’s troubleshooting methods are successful in this case because the proxy controls the network circuits in non-standard ways.

      IPv4 and IPv6 Troubleshooting

      The aforementioned recommended tools and techniques should work with both IPv4 and IPv6 seamlessly. Where separate tools are necessary, an equivalent IPv6-specific tool is often available on modern hosts. The ping6 app, found in some operating systems, exclusively pings IPv6 hosts.

      Depending on the operating system family and version, two separate-but-equal networking stacks (IPv4 and IPv6) share the same network adapter. One stack may pass IPv4 traffic but not IPv6 traffic, or the reverse. When a DHCP address is given for each protocol, a DNS resolver may be given on the IPv6 protocol that cannot be found by an app that can only inquire IPv4 resolvers, and vice versa. If DHCP delivers a mixture of IPv4 and IPv6, examine both protocols when troubleshooting to complete a network connection successfully.

      In some operating systems, there are equivalent tools made exclusively for IPv6 traffic. For example, in Linux it’s common to see ip6tables as a separate netfilter component used to handle and route IPv6 traffic, because standard iptables does not. nftables, an iptables replacement, works with both IPv4 and IPv6.

      Priorities must be set when two protocols compete for the same resources. For example, a network interface card connection in the host. By default, Microsoft Windows prioritizes IPv6 over IPv4, while Linux commonly does the reverse. A host stack may also have IPv6 turned off, which is not recommended in Windows, but is nevertheless common in all hosts. It’s often an attempt to remove unwanted traffic and network card contention in environments where IPv6 isn’t commonly used. Most network engineers recommend against this, because IPv6 resources are used more seamlessly today.

      IPv6 Tunneling

      When IPv4 was running out of addresses, the large host and network address space rendered by IPv6 was seen as a huge necessary change, even though many routers were not IPv6-compatible. Network client protocol stacks were also not mature. However, any of these stacks may still be in use, and must be examined for version before troubleshooting. Several different methods of tunneling IPv6 over IPv4 were invented and may still be found in some network configurations today.

      For example, IP6to4 is a useful protocol used when a downstream link cannot support IPv6 traffic, as many international ISPs still do not support IPv6. Sometimes users inadvertently leave IPv6 enabled, leaving accidental responders active within their hosts. The IP6to4 protocol encapsulates IPv6 packets into IPv4 packets, disassembling the IPv4 information, and transforming the packet into an IPv6 packet once again. This tunneling action is deprecated but must be used where IPv6 routing isn’t available in the desired routing path between hosts.

      IP6to4 is a handicapped stack, and requires static routing, so that a target IPv6 host can be found. Because of this and other problems, Microsoft deprecated this method of packet tunneling, however IPv6 packet tunneling is still found on older hosts.


      Successful network communication is completed when there is an electrical circuit, the host network stack works, and downstream routers/gateways/switches can connect to a target host/site. The network stack resident in the host is bound by protocols and firewall rules. There are iterative steps involving tools that are available by default in most modern host operating systems.

      Troubleshooting begins by examining the correct values in the host network stack, then the firewall rules. Proxy-controlled network stacks must be treated differently, because they may involve both business policy and specialized treatment germane to the stack proxy.

      Although IPv6 integration is treated separately as a protocol, most modern stacks use a separate set of equivalent tools to IPv4 for troubleshooting. Older IPv6 implementations can be buggy, and require stack version-specific techniques to troubleshoot IPv6 connectivity or interference issues with IPv4.

      Source link

      How To Optimize a WordPress Installation Before Troubleshooting

      Part of the Series:
      Common WordPress Errors

      This tutorial series explains how to troubleshoot and fix common errors that you may encounter when deploying, maintaining, and updating your WordPress installation.

      Each tutorial in this series includes descriptions of common deployment, maintenance, or update errors, and explores ways to fix and optimize your installation to scale.


      WordPress is a robust Content Management System (CMS) that provides blog and site infrastructure, creation, and publishing tools. While WordPress is a well-maintained, open source CMS, you may sometimes encounter issues or errors that will prevent you from having access to common functionalities.

      In this tutorial, you’ll learn how to perform steps to ward against common WordPress errors in a way that also optimizes your site to prevent those errors from occurring in the future.

      Step 1 — Creating a Backup of Your Site

      Before you begin any troubleshooting process, it’s wise to back up your site. Creating backups of your site, whether manually or by using a plugin, allows you to restore your WordPress installation in the event of an error. A backup also serves to protect your WordPress site against security threats, data loss, and more.

      Learn How To Back Up Your WordPress Site to Object Storage with our tutorial, or explore WordPress Backup Plugins to automate the backup process.

      Step 2 — Making Sure your Cache is Clear

      A cache is a temporary storage space that allows browsers and programs to take a snapshot of your site and store temporary files and data, to load your site faster and increase performance.

      While caching does generally give a performance boost to site load times and improves user experience, sometimes errors with visual elements may be a result of a cached version of your site being served. Clearing your browser cache as well as your WordPress cache typically solves issues with older or cached versions of your site being shown.

      This list shares step-by-step information to clear your browser cache on any browser, and there are a number of site caching plugins available that allow you to clear and maintain WordPress cache size, in order to optimize your site’s appearance and performance.

      Step 3 — Auditing Your Plugins

      Plugins are third-party software added to WordPress installations to extend functionality. Even though these extensions provide helpful and convenient features, they can sometimes conflict with each other and cause your site to experience issues in performance, speed, and security.

      To audit your plugins and potentially troubleshoot an error, start by ensuring that each of your plugins are updated to its most recent version. Next, you can also deactivate all plugins and reactivate them one-by-one.

      While inside of your WordPress site’s admin panel, click Plugins, then All Plugins. Within your list of plugins, click the box to Select All, then click Deactivate from the dropdown above the checkbox. Click Apply to deactivate all plugins.Then, select one plugin at a time and click Activate to reactivate each of them while monitoring your website to identify any issues .


      This tutorial highlighted three steps that you can take to prevent your WordPress site from experiencing common errors, and to maintain the health of your WordPress installation.

      For more information on optimizing your WordPress installation on Ubuntu, visit our tutorial, How to Optimize WordPress on Ubuntu 20.04.

      Source link