How to run the check
Enter a domain, or any hostname under it. The tool works out which zone is in charge, asks that zone's parent which nameservers it hands off to, then asks those nameservers what the zone says about itself. It also looks up every nameserver's IP address and talks to each server directly, so you learn more than a plain NS lookup would tell you.
How the handoff works
DNS is a chain of handoffs. No single server knows every domain, so each level points to the next. When someone looks up example.com, they start high up at the com zone, which does not hold your records but knows where to send the question. That pointing step is called delegation: com delegates example.com to your nameservers and steps out of the way. Your nameservers are the ones that actually hold the zone and answer for it, which is what authoritative means. They are the source, not a cache passing along someone else's copy.
comyour nameserversexample.com zoneWhat glue is and when you need it
There is a catch when a nameserver lives inside the zone it serves. If ns1.example.com is the server for example.com, a resolver cannot find ns1.example.com without first asking a server for example.com, which is the exact thing it is trying to reach. Glue breaks that loop: the parent zone publishes the IP address of ns1.example.com directly, so the resolver gets an address instead of a dead end. A nameserver that lives outside your zone, like ns1.someprovider.net, is found through normal lookups and does not need glue in your delegation.
Reading the result
When the parent's list and your zone's own list name the same servers, the handoff is consistent and resolvers will land where you expect. For each server, "Answered" means it replied on that address at all. "Authoritative SOA" is the stronger check: the server not only replied, it claimed authority for this zone, which is what you actually want from a nameserver.
A server that shows up on only one side is the common warning sign. It usually means a provider move that was started but never finished: the new server was added in one place, or the old one was removed in one place, and the matching change never happened on the other side. Nothing breaks immediately, because resolvers may still reach a working server, but the delegation is now inconsistent and the odd server out is the first thing to reconcile.
Fixing a mismatch
Start at the parent side, which is your registrar's delegation, and compare it against the NS records at your DNS provider. Remove old servers from both places, add every new server to both places, and add the required glue before you switch to a nameserver that lives inside the zone. If a server is listed correctly but does not answer authoritatively, fix that server or drop it from the delegation rather than waiting for DNS caches to sort it out. A stale delegation does not heal on its own.