Reading the Records in a dig Answer

Every record in a dig section is five columns: name, TTL, class, type, and rdata. This walks the columns and then the rdata of the record types you actually meet, from A and CNAME to MX, SOA, SRV, and CAA, so a wall of records reads as plain facts.

Inside the ANSWER, AUTHORITY, and ADDITIONAL sections, every line is one resource record with the same five columns:

example.com.		3600	IN	A	93.184.216.34

That is name (example.com.), in seconds (3600, how long it may be cached), class (IN for Internet, essentially always), type (A), and rdata (93.184.216.34, the type-specific payload). Question records are the exception: they start with a ;, carry no TTL, and have no rdata, because a question only names what you asked.

The types you meet, and their rdata

A and (the IPv4 address and IPv6 address records): an IPv4 or IPv6 address. The rdata is just the address.
(Canonical Name): an alias. The rdata is another name, and the real records live under that target. A CNAME in an answer is why you sometimes see two records: the alias, then the address of what it points to.
NS: a name server that is authoritative for the zone. The rdata is the server's name.
(Mail Exchange): a mail exchanger. The rdata is two fields, a preference number and a hostname; lower preference wins.
(Start of Authority): the zone apex record, and the densest rdata you will read. Its seven fields are the primary server, the admin mailbox (with the first dot standing in for @), the serial, and the refresh, retry, expire, and minimum timers. The minimum doubles as the negative-cache TTL, so it governs how long an NXDOMAIN for this zone is remembered.
(Text): free-form text, quoted. It carries (Sender Policy Framework) policies, (DomainKeys Identified Mail) keys, and domain-verification tokens.
(Pointer): the reverse record, mapping an address back to a name. You see it when you look up an address under in-addr.arpa or ip6.arpa.
(Service): a service locator. The rdata is four fields: priority, weight, port, and target host.
(Certification Authority Authorization): which certificate authorities may issue for the domain. The rdata is a flags byte, a tag (issue, issuewild, iodef), and a value.
HTTPS and SVCB: newer service-binding records that carry connection hints (, port, address hints) for an origin.

TTL is a clock, not a constant

The TTL you see from a recursive resolver counts down as the record ages in its cache, so the same query a minute later can show a smaller number. Query the authoritative server directly (the one in an NS record, with @) and you see the zone's configured TTL instead. That difference is often the fastest way to tell a caching problem from a zone problem.

A CNAME answer is two answers, and the second one can be the problem

Ask for an A record on a name that is a CNAME, and a well-behaved server returns both the CNAME and the A record it resolves to. The answer section carries the chain.

That chain is where two quiet failures live. A CNAME pointing at a name with no record of the requested type returns NOERROR with an incomplete chain — the alias resolved and the target had nothing. And a CNAME crossing into a zone the server is not authoritative for may return only the alias, leaving the client to start a second lookup it may not be configured to make.

Read the whole answer section, not the last line. The record you asked for may not be there even when the status says nothing went wrong.