DNS Lookup

What this DNS lookup shows

DNS, the Domain Name System, is the internet’s directory. It turns a name such as example.com into the things a computer needs to use it: the address of its web server, the servers that receive its email, the servers that answer for it, and a handful of other facts. Each fact is stored as a record of a particular type. When you run a lookup, HostChecker asks for the records of eight types for the name you typed, using the standard dig command, and lays the answers out by type. What you get depends on whether you enter a domain name or an IP address.

For a domain name

Enter a domain and the lookup asks for its A, AAAA, CNAME, MX, NS, TXT, SOA, and CAA records, one type at a time. The tile counts every record found, and the list shows each type with what came back. A type with nothing to show reads “none”. Here is an example, with what each part tells you:

The dot at the end of a name, as in mail1.example.com., marks it as a complete name. You can ignore it. The complete, unedited answers are under “Show complete raw command output”, and they carry one thing the list leaves out, the TTL:

Each line reads: the name the record belongs to, its TTL, the class (IN, for the internet), the record type, and the data. The TTL (time to live) is how many seconds a DNS resolver may keep the answer before asking again. HostChecker asks through a resolver that remembers answers, so the TTL shown is usually what is left of the original and counts down between checks. This example is also an alias: www.example.com is a CNAME for example.com, and the lookup follows it the way a browser would. The first line is the alias, and the second is the address at the end of it. For an alias, the other record types can come back from the name it points to. The name at the start of each raw line shows whose record it is.

For an IP address

Enter an IP address and the lookup does the reverse: it asks which name the address’s owner has registered for it, called reverse DNS or a PTR record. Only that one type is asked for. Here is an example, with what each part tells you:

The name in the raw output, 10.113.0.203.in-addr.arpa., is the address written backwards with .in-addr.arpa on the end, which is where reverse records are kept. The owner of the address block controls them, which is usually a hosting company or an internet provider rather than the website’s owner, so you set a reverse name through them and not at your domain registrar. A reverse name does not have to match what the domain points to, but many mail servers check that a sending address has one. Addresses on private networks, such as 192.168.x.x or 10.x.x.x, have no public reverse name, and IPv6 addresses are not accepted.

Either way, three things are worth knowing. The lookup asks one resolver, the one HostChecker’s server uses, so a record you changed minutes ago can still show its old value until the old TTL runs out. It does not say why a type came back empty: a name that does not exist, a name with no records of that type, and a DNS server that did not answer all read as “none”. And it looks up only the exact name you typed, so www.example.com and example.com are separate lookups. To see where the name actually leads and whether the site answers, run Host Check.

How to read the result

• A and AAAA. The addresses the name points to: A for IPv4, AAAA for IPv6. This is the first thing to compare with where you expect the site to be. Several addresses are normal for large sites, and the order can change between checks. Check an address with WHOIS to see who it belongs to.
• CNAME. The name is an alias for another name, and DNS carries on from there. If a name has a CNAME, any address you see for it belongs to the name it points to.
• MX. The mail servers, each with a priority number. Senders try the lowest number first and fall back to higher ones. An MX value of 0 . (a zero and a single dot) is a deliberate “this domain accepts no email”. A domain with no MX record at all is different: sending servers then fall back to the domain’s address record, so mail may still go to the web server.
• NS. The name servers that answer for the domain. They should list the same servers as the Name servers in WHOIS. If they do not, the registrar’s setting is the one the internet follows first.
• TXT. Text records. You will usually see an SPF record (it starts v=spf1 and lists who may send email for the domain) and verification codes for services such as Google or Microsoft. A domain should have only one SPF record. Each quoted piece is at most 255 characters, so a longer value is split into several quoted pieces, which are read as one with nothing between them.
• SOA. The start of authority, in order: the primary name server, the administrator’s email address (written with a dot where the @ goes), a serial number that changes when the zone is edited, then the refresh, retry, and expire timers in seconds, and a final number, the minimum, which caps how long resolvers remember that a record does not exist.
• CAA. Which certificate authorities may issue certificates for the domain. issue covers ordinary certificates, and issuewild covers wildcard ones, falling back to issue if absent. Certificate authorities are required to check these before issuing. With no CAA records, any authority may issue.
• None. No record of that type came back. For most types that is simply how the domain is set up. If every type reads none and the tile is red, as below, the name has no usable DNS.

Common DNS problems and fixes

The site still goes to the old server after a change

Resolvers keep each answer for its TTL, so for a while some of them hand out the old address and others the new one. That is what people call propagation, though nothing is being pushed anywhere: old answers are simply expiring. Look at the TTL in the raw output to see how long caches may hold the old value. If the old address is still showing well after that TTL has run out, the change was probably not saved at your DNS provider, or the domain’s name servers point somewhere else. If you are planning a move, lower the TTL ahead of time, by at least as long as the old TTL, and raise it again afterward. Browsers and your own computer cache DNS too, so restarting the browser or flushing the local cache can matter.

Every type reads none

The name did not resolve. Check the spelling and the ending first. Then use WHOIS to see whether the domain is registered and not on hold or expired. If it is, compare the Name servers there with the DNS provider where you manage the records: the registrar must point at the provider that holds the zone, and that provider must have a zone for the domain. A DNS server that is down or answering with an error also reads as none here, and so can a domain whose DNSSEC signatures are broken, because resolvers that check them refuse to answer.

The domain works but www does not (or the reverse)

They are separate names with separate records. Look up both. The usual fix is a CNAME that makes www an alias for the bare domain, or an A record for each.

A CNAME cannot be added at the root of the domain

A name that has a CNAME cannot have any other record, and the root of a domain always has NS and SOA records, so it cannot be an alias. Use A and AAAA records at the root. Some DNS providers offer a feature called ALIAS, ANAME, or CNAME flattening that follows another name for you and answers with plain address records.

Email is not arriving

Check the MX lines: they should exist, point at the right provider, and use names that have address records of their own. An MX or NS value should never be an alias (a CNAME). Then check the TXT lines for one SPF record that includes your mail provider, because two SPF records cause SPF to fail. SPF is only part of email authentication; DMARC and DKIM live at names this lookup does not accept (see the FAQ). Email Check is the tool for those.

A certificate will not issue

If the domain has CAA records, the certificate authority you are using has to be listed, with issuewild as well for a wildcard certificate. Remove or correct a CAA record that names the wrong authority. If every type reads none, the authority cannot validate the domain at all.

The name servers here do not match WHOIS

The NS list comes from DNS, and the Name servers in WHOIS come from the registrar. A difference usually means a name server change was started but not finished, or the old DNS provider still serves a copy of the zone. Fix the Name servers at the registrar, since that is where resolvers start, and make sure both providers carry the records until the change has settled.

Frequently asked questions