{{ summaryHeading }}
{{ summaryFigure }}
{{ summaryLine }}
{{ badge.label }}
Probe random labels and deeper branches below one root so you can tell whether public resolvers are synthesizing answers from a wildcard record or returning negative responses for the tested type.
Current inputs differ from the last completed run. Re-run the check before trusting the on-screen wildcard read.
Checking {{ progressCompleted }} of {{ progressTotal }} resolver probes...
Example: example.com or www.example.com.
Supported: A, AAAA, CNAME, TXT, or MX.
Leaf = name.root; deep = name.branch.root.
Accepted values: 3, 4, 6, or 8 probes per lane.
Optional examples: www, api, or dev.api.
Use Defaults for Cloudflare + Google, or Select all for every listed resolver.
{{ resolver_keys.length }} / {{ resolverCatalog.length }} selected
Optional; off is fine for a basic wildcard check.
Optional; leave off unless comparing validation policy.
Accepted range: 1000 to 15000 ms.
ms
Signal Read Copy
{{ row.label }} {{ row.value }}
Resolver Probe QName Outcome Answer or authority TTL Cache hint AD Time Copy
{{ run.resolverName }} {{ run.probeLabel }} {{ run.qname }} {{ run.outcomeLabel }} {{ run.displayAnswer || run.authorityNote || run.errorText || 'No answer data returned' }} {{ run.ttlMin === null ? '-' : run.ttlMin }} {{ run.negativeCacheSeconds === null ? '-' : formatSeconds(run.negativeCacheSeconds) }} {{ run.ad === null ? '-' : (run.ad ? 'Yes' : 'No') }} {{ run.latencyMs === null ? '-' : `${run.latencyMs} ms` }}
Resolver Direct Deep Boundary Lead answer Negative read Copy
{{ row.resolver }} {{ row.direct }} {{ row.deep }} {{ row.boundary }} {{ row.leadAnswer }} {{ row.negativeRead }}
Evidence Read Copy
{{ row.label }} {{ row.value }} 

          

        

      


    

  

                

                

                    

                        

                            Tags: DNS, Diagnostics, Networking
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


        
    

        

        

            


                

                    

                    
                


                

                

                
            

            

                
                
            

        

    


    

        

                                                                                                                                                                                                                                                                        
        

            

                
                
                
                
            

            

                
                
            

            

                

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        

                            
                            :
                            
                        

                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        
                    

                    

                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        
                    

                

            


            
        

    



    

        

  

  
DNS wildcard behavior appears when a zone synthesizes an answer for a name that does not exist exactly. The important detail is where synthesis starts. A wildcard such as *.example.com can answer random names below example.com, but existing names, delegations, and closer matching branches can stop or change that behavior.


  
Wildcard records are useful for catch-all web routing, tenant onboarding, and temporary migrations. They can also mask mistakes. A random host that resolves does not prove every deeper name behaves the same way, and a clean apex answer does not reveal what happens under a branch such as api.example.com.


  

    Diagram showing apex, leaf, deep, boundary branch, and verdict probes for DNS wildcard behavior
  


  
Testing several random labels through more than one public resolver gives better evidence than checking one invented hostname. Resolver caches, DNSSEC flags, and negative caching can still make results differ for a short time.






  
Technical Details:


  
DNS wildcards are governed by closest-encloser logic. A resolver first looks for an exact match. If the queried name does not exist, the authoritative data can synthesize an answer from a wildcard owner at the closest existing ancestor. Existing branches, delegations, or different record types can prevent a simple catch-all reading.


  
The checker builds a probe plan under the supplied zone or host root. It can test leaf names, deeper two-label names, and an optional boundary branch. It queries selected record types over public DNS-over-HTTPS resolvers and summarizes answer counts, resolver splits, negative-cache hints, and operational next steps.


  

    

      
      
Probe roleWhat it testsWhat to watch

      
        
Apex controlThe supplied root itself.Confirms the baseline record type is visible.

        
Leaf probesRandom one-label names under the root.Repeated matching answers suggest wildcard synthesis.

        
Deep probesRandom names with another random branch.Shows whether wildcard behavior appears at deeper levels.

        
Boundary branchA known sub-branch and random names below it.Finds closer-encloser or delegation effects.

      
    

  


  
Negative answers can include SOA data that suggests how long NXDOMAIN or NODATA may remain cached. DNSSEC DO and CD flags are optional request modifiers; they do not create wildcard behavior, but they can change the records or flags visible in a resolver response.


  
The tool supports A, AAAA, CNAME, TXT, and MX probes. A wildcard for one record type does not prove a wildcard for another record type, so the selected type should match the operational question.






  
Everyday Use & Decision Guide:


  
Use Leaf + deep branches for the first run because it checks both common catch-all behavior and deeper inheritance. Four probes per lane is a useful default. Raise the count when the zone is important enough to trade speed for stronger evidence.


  
    
    
  • Enter the root without *.. The checker removes wildcard notation and generates random names below the root.
    • 
    
  • Add Boundary branch when a known label, such as api or dev, may have its own records or delegation.
    • 
    
  • Use multiple resolvers when a production change is near. A split between Cloudflare, Google, and DNS.SB can reveal cache or policy differences.
    • 
    
  • Do not read one positive answer as proof of a safe wildcard. Compare answer signatures, TTL, authority notes, and resolver split.
    • 
  


  
If the verdict says wildcard-like answers are visible, copy the probe table before changing DNS. It gives you concrete names, answers, TTLs, and resolver views for the change record.






  
Step-by-Step Guide:


  
The check is intentionally simple to run:

  
    
    
  1. Enter Zone or host root, such as example.com.
    2. 
    
  2. Select the Record type you care about.
    3. 
    
  3. Choose Probe topology and Probe count.
    4. 
    
  4. Add Boundary branch if a known sub-branch needs its own test.
    5. 
    
  5. Select resolvers, set DNSSEC flags only when relevant, then press Check.
    6. 
  

  
If validation fails, correct the root name or remove wildcard characters from the boundary branch.






  
Interpreting Results:


  
The verdict is strongest when many random probes return the same answer signature and multiple resolvers agree. A direct apex answer alone is not wildcard evidence. A boundary NS answer means a delegation or branch-specific authority may be changing what names below that branch see.


  
A negative-cache hint is a timing clue, not a final state. If a change was just made, wait at least the surfaced SOA-based cache time before treating a negative result as stable.






  
Worked Examples:


  
For example.com with record type A, four leaf probes that all return the same IP and TTL while the apex also answers suggests a catch-all A record. The Lead signature and probe rows give the repeated answer.


  
If leaf probes answer but deep probes return NXDOMAIN, wildcard behavior may exist at one level but not inherit through the random branch pattern tested. That is a reason to inspect authoritative zone data before relying on deep hostnames.


  
When Boundary branch is api and the boundary NS check returns records, random names below api.example.com may be controlled by another zone. Treat the branch output separately from the parent wildcard verdict.






  
FAQ:


  
Does a wildcard DNS record match the zone apex?
No. A wildcard owner such as *.example.com is for names below the zone, not for example.com itself.

  
Why can A and TXT results differ?
Wildcards are record data in DNS. A zone can synthesize A answers without publishing a matching TXT wildcard.

  
Why do public resolvers disagree?
Resolver cache state, DNSSEC handling, transport errors, and recent zone changes can produce different views for a short period.






  
Glossary:


  

    
Wildcard owner
A DNS owner name whose leftmost label is *.

    
Closest encloser
The nearest existing ancestor name used when deciding whether wildcard synthesis applies.

    
Negative cache
Temporary resolver memory of an NXDOMAIN or NODATA result.

  






  
References: