Every record a domain publishes, read into named columns, and answered from Dhaka and Miami so you can see a name that means two different things.
This is the plain view: everything the domain publishes, resolved now rather than from a cache we kept. It is the page to open when something is wrong and you do not yet know what. Take every type at once, or pick one from the list beside the box.
The same question is also put to three machines we own -- two in Dhaka and one in Miami -- and the page shows what each of them saw. That is a different question from propagation, and the one people usually mean when they say a site "works for me": not whether the caches have caught up, but whether the name means the same thing in one part of the world as it does in another. It normally does, and the page says so in a line. When it does not, that is either a CDN working as intended or a mistake nobody had noticed, and either way you can now see which.
The answers are read into columns rather than printed the way the wire sent them. That sounds cosmetic and is not. A SOA record on the wire is seven meaningful numbers in a row with nothing saying which is which, so anybody who does not already know the field order cannot use it -- which is everybody the page was written for. Here the serial is under "Serial", the refresh interval is a duration in words, and an MX priority sits in a priority column where you can see the order mail is actually tried in. The exact zone lines are still there, one click down, for when you are comparing our reading against your own file.
Two things are worth a deliberate look. NS records tell you who is actually authoritative, which is often not who somebody believes is authoritative after a migration. And CAA names which certificate authorities may issue for the domain: publish none and any public CA may issue for you, which is a decision most people have not realised they are making.
Queries here use EDNS0 with a TCP fallback, so a large record set comes back complete. A truncated reply is how a lookup tool ends up showing you a domain's records with the important one missing.
Usually caching somewhere between you and the authority. This page resolves fresh each time, so a difference from another tool is often that the other tool cached.
No. This asks one resolver what the answer is now. A propagation check asks many resolvers around the world whether they agree yet, which is what you want during a migration.
Because both would be empty on every domain and would teach you to ignore the list of what was asked for and not found -- which is the line that matters when CAA is missing. A CNAME cannot exist at the apex of a zone alongside other records, and a PTR is about an address rather than a name. Pick either from the list to look one up directly; PTR takes an address like 8.8.8.8.
Because the name genuinely answers differently depending on where you ask from. Large sites do this on purpose so visitors reach a nearby server; google.com answers 192.178.158.x to our Dhaka machines and something else entirely to Miami. It is only a problem when you were not expecting it, which is exactly why the page shows all three rather than picking one.
No, and they are opposites in a useful way. Propagation asks eighteen public resolvers from one place whether the caches have caught up with a change you made. This asks three machines in two countries what the name means where they are. Anycast is why the first cannot honestly draw a map and why the second can.
Yes. Add format=json, or send Accept: application/json. You get named fields rather than table cells: an MX priority is a number, and a SOA arrives with serial, refresh, retry, expire and minimum under those names. The records come back in the same order the page shows them.