Parent DNS checks: what your registry really sees

1. Domain NS records (authoritative list of nameservers)

This sub-section compares the NS records published in your zone (the authoritative NS inside your domain) with the list of nameservers that the parent zone has on file for your domain. In an ideal configuration, both lists should match exactly or differ only for controlled anycast or load-balancing reasons.

Why Domain NS records are important

Your domain relies on its nameservers to publish every other DNS record: A, AAAA, MX, TXT, CNAME, SRV and so on. If the parent zone delegates your domain to the wrong nameservers, resolvers will ask the wrong servers for your data. Even if your zone file is perfect on your real DNS provider, users will see inconsistent or completely wrong results because they are querying other nameservers.

How DNSprobe checks Domain NS records

DNSprobe first resolves NS records by querying your domain directly at your nameservers, then separately asks the TLD registry for the delegation NS records stored at the parent level. It then compares both lists, normalises hostnames and highlights discrepancies such as missing NS, extra NS that exist only on one side, or differences in TTL that may indicate propagation problems.

Common errors for Domain NS records

• The parent zone points to an old DNS provider while the domain owner has already moved the zone to a new provider but forgot to update the registrar configuration.
• The zone file contains additional NS records for testing or migration, but the parent zone has not been updated, creating a mismatch where some resolvers receive partial or outdated data.
• Typographical errors in nameserver hostnames (for example ns11.example.com instead of ns1) that go unnoticed locally but cause silent delegation failures on the Internet.

Best practices for Domain NS records

• Always keep the NS list at your registrar and the NS list inside your zone file in sync. Any change on one side should be reflected on the other side as soon as possible.
• Use at least two independent nameservers, ideally hosted on separate networks or locations, and avoid mixing experimental or temporary NS entries with production records.
• After any change of nameserver provider, systematically run a full DNS health check with DNSprobe to confirm that both the parent zone and your authoritative zone agree on the NS records.

2. TLD Parent Check

The TLD Parent Check verifies what your top-level domain registry actually publishes for your domain at the parent level. This includes the list of delegated nameservers and, when relevant, the glue records associated with them. It is the official view of your domain from the perspective of the global DNS hierarchy.

Why the TLD Parent Check matters

Resolvers typically start at the TLD level when looking up your domain. If the TLD registry has stale data — for example old nameservers, missing glue or partially removed entries — your domain can appear to work in some places and fail in others. This is especially common after migrations or registrar changes that were not completed correctly.

How DNSprobe performs the TLD Parent Check

DNSprobe sends direct NS queries to the official TLD nameservers for your extension. It does this without recursion, asking only for authoritative information. The answer is parsed to extract your delegated nameservers and glue, and is then compared to what your domain publishes itself. This makes it easy to see if the registry is one step behind your real configuration.

Typical problems detected by the TLD Parent Check

• Registrar changes that were started but never finished, leaving the TLD registry pointing to a mix of old and new nameservers.
• Domains transferred between registrars where the new registrar imported the zone but did not correctly update the delegation at the registry.
• Manual edits in a registrar control panel that removed one nameserver but left other references, creating inconsistent delegation across TLD nameservers.

Best practices for the TLD Parent layer

• After changing DNS provider or moving a domain between registrars, always verify the parent data with a tool like DNSprobe instead of assuming the registrar interface is correct.
• Avoid frequent, unnecessary changes to nameserver hostnames. The more you edit delegation, the higher the risk of a typo or partial update at the registry.
• If your business is sensitive to downtime, plan DNS migrations during low-traffic periods and double-check the TLD Parent Check before, during and after the change.

3. Your nameservers are listed

This sub-section verifies that all nameservers that should answer for your domain are properly listed at the parent level, and that there are no references to servers that no longer host your zone.

Why it is important that your nameservers are listed correctly

If one of your nameservers is not listed at the parent level, some resolvers will never query it, even if it contains the most up-to-date version of your zone. Conversely, if the parent zone still lists a nameserver that you decommissioned, resolvers that hit this server may receive SERVFAIL responses or completely wrong answers.

How DNSprobe checks that your nameservers are listed

DNSprobe cross-references the NS records declared inside your zone with the NS records present at the parent level. Any nameserver that exists only in one of those places is flagged. We also look for duplicates, aliases, and inconsistent hostnames that could indicate partially removed infrastructure.

Common mistakes with listed nameservers

• Leaving a legacy nameserver listed at the registrar after a migration, causing part of the traffic to continue hitting an old zone or an empty server.
• Adding a temporary nameserver for troubleshooting and forgetting to remove it from the parent zone afterwards.
• Mixing internal and external nameservers (for example, a private 10.x IP or lab hostname accidentally added to the public delegation).

Best practices for nameserver listings

• Maintain a clear inventory of which nameservers are authoritative for each domain and update both the zone and the registrar in sync.
• Decommission nameservers in a controlled way: remove them from the parent zone, wait for TTLs to expire, monitor traffic, then shut them down.
• Regularly review your delegation with DNSprobe to ensure that the list of nameservers stays clean, minimal and aligned with your current infrastructure.

4. DNS Parent sent Glue (glue records for in-bailiwick nameservers)

Glue records are A or AAAA records stored at the parent level to break circular dependencies when your nameservers are inside the same domain they serve (in-bailiwick). For example, if example.com uses ns1.example.com as a nameserver, the registry must also publish the IP of ns1.example.com as glue.

Why glue records are critical

Without correct glue, resolvers cannot reliably reach your nameservers. They would first need to resolve ns1.example.com, which itself depends on example.com being resolvable. Proper glue records remove this chicken-and-egg problem by giving resolvers a working IP for your nameservers at the parent level, even before your zone is loaded.

How DNSprobe verifies glue records

DNSprobe queries the TLD registry for your delegation and inspects the additional section of the DNS response to find glue records. We then compare the IP addresses published as glue with the A/AAAA records inside your authoritative zone. Differences are highlighted, because they mean that some resolvers may use outdated or incorrect IP addresses for your nameservers.

Typical glue-related problems

• Changing the IP of a nameserver only in the zone file, without updating the corresponding glue at the registrar, leaving resolvers pointing to the old address.
• Having glue only for IPv4 while your zone and resolvers expect IPv6 as well, or vice versa, creating asymmetric reachability.
• Removing a nameserver from the zone but forgetting to remove its glue record at the parent level, causing unnecessary or misleading traffic.

Best practices for glue management

• Whenever you change the IP address of a nameserver that is in-bailiwick, update the glue records at your registrar at the same time as the A/AAAA records in your zone.
• Prefer hosting your nameservers on stable infrastructure with long-term IP assignments to avoid frequent glue updates and propagation windows.
• Use DNSprobe regularly to ensure that the "DNS Parent sent Glue" test is fully green and that parent glue always matches your live nameserver IPs.

5. Nameservers A records (IP addresses of your NS)

This sub-section focuses on the A and AAAA records of your nameservers themselves. Even if delegation and glue are correct, wrong or unstable IP addresses on the NS hostnames will cause timeouts, high latency or intermittent resolution failures.

Why Nameservers A records matter

Nameservers are the foundation of your DNS. If their IP addresses change without coordination, if they are placed behind overloaded hardware, or if they point to test servers, every lookup for your domain will suffer. Monitoring the A/AAAA records of your NS hostnames helps detect misconfigurations that are invisible at the zone-file level.

How DNSprobe analyses Nameservers A records

DNSprobe resolves each NS hostname listed for your domain and collects all associated A and AAAA records. We then check for internal or private IP ranges, unstable configurations (such as pointing to web hosting IPs that may change) and inconsistencies between what the parent zone and your authoritative zone announce.

Frequent problems with Nameservers A records

• Nameserver hostnames pointing to private or RFC1918 addresses, which makes them unreachable from the public Internet.
• A records that follow web-hosting changes instead of dedicated DNS infrastructure, causing unplanned DNS outages during website migrations.
• Temporary IP addresses used for testing that were never replaced by final production addresses.

Best practices for Nameservers A records

• Host your nameservers on stable, monitored infrastructure with well-defined IPs that change rarely and are not reused for unrelated services.
• Avoid pointing NS hostnames to load-balanced frontends or CDN IPs unless you fully control the DNS behaviour of those endpoints.
• Document the expected IP addresses for each nameserver and periodically audit them with DNSprobe to detect unexpected changes.

6. Test parent NS delegation manually from your own terminal

The Parent section in DNSprobe compares what the registry (parent zone, such as .com or .ca) publishes for your nameservers with what your own zone returns, including glue records and IP addresses. You can reproduce these checks from a terminal by querying your NS records through your resolver and directly against the TLD servers.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package. The examples below show the NS records seen by your recursive resolver, follow the full delegation path from the root, and finally query a specific TLD server to see the parent delegation and glue:

                dig example.com NS +noall +answer
    
                # Query NS records for example.com as seen by your current recursive resolver    
                dig example.com NS +trace
    
                # Follow the delegation chain from the root down to example.com to see each step    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to compare what your resolver returns, how the delegation trace looks, and what a TLD server publishes for your domain:

                dig example.com NS +noall +answer
    
                # Query NS records for example.com as seen by your current recursive resolver    
                dig example.com NS +trace
    
                # Follow the delegation chain from the root down to example.com to see each step    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
        

Windows: using nslookup

On Windows, the legacy nslookup tool can query NS records both through your normal resolver and directly against a chosen name server. Run the following from Command Prompt or PowerShell to see your NS records, then ask a specific TLD server what it publishes for your domain:

                nslookup -type=NS example.com
    
                REM Second command: explicitly ask the g.gtld-servers.net TLD server for the NS delegation of example.com    
                nslookup -type=NS example.com g.gtld-servers.net
        

Important: only query DNS records for domains that you own or are authorised to analyse. Repeated automated lookups against third-party domains or TLD servers without permission may be treated as abusive traffic by some providers.