Classic DNS had a 512-byte limit on UDP answers and no room in the header for new options. (0), defined in RFC 6891, fixes both by adding a pseudo-record of type . dig prints it as its own block:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
It is called a pseudo-section because OPT is not real zone data. It exists only on the wire to carry EDNS parameters, so it never appears in a zone file and you never query for it directly.
What the fields mean
version is the EDNS version, effectively always 0. udp is the largest UDP response the sender is willing to receive, advertised so the responder can send bigger answers without falling back to TCP. Modern resolvers commonly advertise 1232 bytes, a deliberately conservative value chosen to stay under the point where IP fragmentation tends to cause trouble. flags carries EDNS flag bits; the one you will see is do, OK, which is how a client says "send me the DNSSEC records too."
Below the EDNS line, dig may print further options such as COOKIE (a lightweight anti-spoofing token) or NSID (a server identifier). These are informational and vary by resolver.
Why it matters for troubleshooting
EDNS is where several confusing failures live. If a large answer plus a large advertised UDP size produces a fragmented UDP packet that a firewall or a broken path drops, the query appears to hang or fail even though the server answered. That is exactly why the advertised size trended down to values like 1232: smaller answers fit in one packet and survive more paths. When you see intermittent SERVFAIL on names with big answers (many addresses, or DNSSEC signatures), the OPT line and the UDP size are the first place to look, and forcing TCP with +tcp is a fast way to confirm it.
The do flag ties directly into DNSSEC: without it, a resolver will not return the signature records, so if you are trying to inspect DNSSEC and see none, check that the OPT line shows do set.
The buffer size is a promise the network may not keep
The OPT record advertises how large a UDP response the client will accept — commonly 1232 or 4096 bytes. Advertising is not the same as receiving.
A response larger than the path gets fragmented, and plenty of middleboxes and firewalls drop IP fragments without comment. The query goes out, the server answers, the answer never arrives, and the resolver waits for a timeout it will blame on the server.
This is why DNS "being slow" is so often not slow at all. It is a large answer failing silently and a client waiting out a retry. The tell is that small queries work perfectly and DNSSEC or lookups do not, because those are the ones that grow.