A DNS lookup opens a small database, and most of what a site depends on lives in it: the address that answers HTTP, the host that takes mail, the servers allowed to sign for the domain, and the authority that may issue a certificate. A terminal answers one question at a time. The DNS records API returns all the common record types in one JSON object, which is enough for a monitor, a checklist or a pre migration check.
Start with the default call:
curl "https://api2.globus.studio/v2/dns?domain=globus.studio"The response groups records by type: A, AAAA, MX, TXT, NS, SOA, CNAME, CAA and SRV. Text records are joined from their chunks into whole strings, MX and SRV keep their priorities, and the SOA record keeps the serial and the timers. A single call is usually faster than five shell commands, and there is no parsing step where a space in a TXT record can break a script.
What each group is good for
Address records answer whether the name resolves and over which protocol. When a site works on IPv4 and fails on IPv6, the AAAA group is the first place to look, and a missing AAAA on a host that advertises IPv6 support is a deployment bug that only some visitors see.
Name servers and the SOA record describe delegation. If the NS list at the registry and the NS list in the zone disagree, the domain is in a split brain state and changes will appear to work for some resolvers and not for others. The serial number in SOA is the cheapest way to confirm that a zone transfer or an edit actually landed.
CAA records limit which certificate authorities may issue for the domain. A CAA record that names one authority and a certificate from another is a contract violation, and the endpoint reports flags, tag and value so the check does not depend on a particular certificate authority syntax.
Mail records without a parser
Two record types matter for email. MX names the hosts that accept mail and their priorities. TXT carries SPF, and also DKIM keys at selector names and DMARC at the _dmarc subdomain. The DNS records API returns the raw TXT strings, which is the right level for a quick check: a mail setup review needs the actual policy, not a summary written by another service.
A null MX is the case worth knowing. A published value of 0 . means the domain refuses mail on purpose, as described in RFC 7505. Most tools render it as a host with an empty target, and a naive check reports a broken MX. The response keeps the dot and sets the service flag to false, so parked domains and sending only domains do not look broken.
Service flags
The services block answers two questions that come up in every launch review: does www resolve, and can the domain receive mail. Both are computed from the same data, so a www that only works through a wildcard certificate but not through DNS shows up immediately.
Limits worth planning for
The lookup has a three second budget. On a slow resolver the meta block sets partial to true, and some groups come back empty. That is a deliberate trade: a public endpoint should answer with what it has rather than hold the connection open. A retry after a few seconds usually fills the gaps.
Answers are cached for one minute. That is short enough for a deployment check and long enough to survive a page that fires the same request several times.
There is no TTL per record in the response. The resolver used by the server does not report it, and inventing a number would be worse than leaving it out. If TTL matters for a migration, compare the answer from two resolvers over time instead of trusting a single field.
Where it fits
Use the endpoint before a DNS migration, after a certificate change, and as a daily check for the domains a business depends on. Add type=MX or type=TXT when only one group matters: the response then contains a single key and the payload stays small.
The catalogue page has the parameter table and a live example: DNS records API.