When nslookup and curl return unexpected wildcard results for github.com, the issue usually stems from local DNS cache poisoning, misconfigured forwarders in BIND9, or an incorrect upstream resolver chain. This article details how to diagnose these specific failures using standard Linux tools and correct BIND9 configuration practices without relying on invalid system commands.
Understanding the Wildcard Anomaly
A wildcard DNS record is a valid configuration where a single record matches multiple subdomains using an asterisk (*). However, when you query a root domain like github.com and receive a response that looks like a wildcard match (e.g., resolving to an IP associated with *.github.com), it indicates a resolution path error. The client is not querying the authoritative servers correctly, or an intermediate server is intercepting the request.
This behavior often manifests as curl failing to connect because the IP address returned does not correspond to the actual service endpoint. Simultaneously, nslookup might show the origin of the answer as a local resolver rather than a.root-servers.net or GitHub’s authoritative nameservers. This discrepancy is the primary symptom of a broken upstream forwarding chain or a local caching daemon returning stale or poisoned data.
To verify if this is a global issue or local to your machine, you must isolate the resolution path. If other devices on the same network resolve github.com correctly, the problem is confined to your local DNS stack. If all devices fail, the issue lies within your network’s authoritative DNS server, likely a BIND9 instance misconfigured to handle upstream queries incorrectly.
Distinguishing Local vs. Network-Wide Failures
The first step in troubleshooting is determining the scope. Usedig @8.8.8.8 github.com to bypass local resolvers entirely. If this command returns the correct A and AAAA records for GitHub, your local configuration is at fault. If it also fails or returns weird wildcard data, your internet connection or ISP DNS might be interfering, though this is rare for major domains.
For network-wide issues, inspect your BIND9 server. A common mistake is configuring BIND9 to use /etc/resolv.conf directly for upstream lookups. As noted in previous corrections, BIND9 does not read /etc/resolv.conf for upstream servers; it uses the forwarders directive within its own configuration files. If your BIND9 setup attempts to parse /etc/resolv.conf via a symlink or an invalid include, it may fail to find valid upstream servers, causing it to fall back to recursive resolution that gets intercepted by wildcard catches-all zones.
Correcting BIND9 Forwarder Configuration
If you are running BIND9 as your local DNS authority, you must ensure it forwards queries for external domains to reliable public resolvers like Google DNS or Cloudflare. The configuration should reside in/etc/bind/named.conf.options or a similar included file.
You need to define the forwarders block explicitly. For example:
options {
directory "/var/cache/bind";
// Forward unresolved queries to Google DNS
forwarders {
8.8.8.8;
8.8.4.4;
};
// Disable recursion if this is a caching-only server,
// or enable it carefully if acting as a full resolver
recursion yes;
allow-query { localhost; };
};named-checkconf. If the syntax is valid, reload the service. Do not rely on systemd-resolved commands to flush BIND9 caches, as they operate on different daemons. Instead, use the BIND9-specific tool rndc to clear the cache.
Clearing the BIND9 Cache Properly
Stale wildcard records can persist in the BIND9 cache if a previous erroneous response was cached. To force BIND9 to forget these entries, use the following command:sudo rndc flushnslookup github.com. The answer section should now reflect the current authoritative IPs for GitHub. If the issue persists, check if you have accidentally defined a catch-all zone (like zone "." IN { type master; file "/dev/null"; };) which might be intercepting queries before they reach the forwarders.
Diagnosing Local Resolver Issues
On modern Linux distributions using systemd, the local stub resolver is managed bysystemd-resolved. A frequent error in troubleshooting guides is suggesting systemd-resolve --flush-caches, which is invalid. The correct command uses the resolvectl utility.
If your local machine is experiencing the wildcard issue while the network is fine, you likely have a corrupted cache in systemd-resolved. Flush this cache using:
sudo resolvectl flush-cachesgithub.com are discarded. Additionally, verify that your /etc/resolv.conf points to 127.0.0.53 (the systemd-resolved stub) rather than pointing directly to an external IP or a broken local service. Misconfigurations here can cause applications like curl to bypass the system resolver and hit dead ends.
For users in WSL environments, DNS issues can also stem from the host OS leaking settings incorrectly. If you are on WSL 1, consider reviewing related guides on Curl Error (6): Couldn't Resolve Hostname - DNS Resolving Issue in WSL 1 to ensure your environment variables are correctly passing DNS information from the Windows host to the Linux guest.
Verifying Resolution with Dig
Once you have cleared caches and verified configurations, usedig for detailed diagnostics. Unlike nslookup, dig shows the full query/response cycle, including flags and additional sections.
Run dig +trace github.com. This command traces the resolution path from the root hints down to the authoritative server. You should see a chain of queries hitting root servers, then TLD servers, and finally GitHub’s authoritative nameservers. If the trace stops early or redirects to a local IP unexpectedly, you have identified the point of failure in your forwarding chain.
Check the ANSWER SECTION in the final response. It should contain A and AAAA records matching GitHub’s infrastructure. If it contains a CNAME pointing to a wildcard pattern that doesn’t expand correctly, your local resolver might be mishandling CNAME chains. Ensure that your BIND9 configuration allows proper CNAME flattening or follows referrals correctly.
Preventing Future Wildcard Interceptions
To prevent recurrence, audit your DNS zone files. Ensure no accidental wildcard entries exist for top-level domains. In BIND9, avoid using*.example.com unless absolutely necessary for dynamic DNS updates. Furthermore, monitor your logs for repeated SERVFAIL or REFUSED responses, which indicate clients are hitting blocks or misconfigurations.
Regularly update your BIND9 software to patch security vulnerabilities that could be exploited for DNS spoofing. Keep your upstream forwarders updated as well. If you are migrating away from BIND9, consider reviewing migration strategies such as those found in Migrating from Bind9 to PowerDNS: Forwarders Setup Guide to ensure robust forwarder handling in alternative systems.
Frequently Asked Questions
Why does nslookup show a different IP than dig?
nslookup often uses the default system resolver and may display cached results, whereas dig allows you to specify exact servers and flags. Always use dig for accurate diagnostics because it reveals the full query path and avoids local cache interference by default.
Can I use /etc/resolv.conf to configure BIND9 forwarders?
No, BIND9 does not read/etc/resolv.conf for upstream server configuration. You must define forwarders explicitly in the named.conf.options file using the forwarders directive. Using /etc/resolv.conf only affects how the host resolves names, not how BIND9 forwards them.
What is the correct command to flush systemd-resolved cache?
The correct command issudo resolvectl flush-caches. The older systemd-resolve command is deprecated and does not support the --flush-caches flag in most modern distributions. Using the wrong command will result in a "command not found" or invalid option error.
How do I know if my BIND9 server is catching all queries?
Check your zone definitions for a catch-all entry likezone "." IN { type master; ... }; or wildcard records in active zones. Use named-checkconf to validate your configuration and review /var/log/syslog for queries being handled by unexpected zones instead of forwarded.
Is it safe to disable recursion in BIND9?
Disabling recursion is safe if BIND9 is configured strictly as a caching server with valid forwarders. However, if clients rely on BIND9 for recursive resolution of internal domains, disabling it will break their ability to resolve non-forwarded hosts. Test thoroughly after making changes to therecursion option.