DNS Packet Analyzer — Response Fields, TTL & Record Breakdown

On the wire, DNS responses bundle a header, question section, and answer/authority/additional sections with type-specific RDATA. Most incident tickets need which A, MX, or TXT strings published and for how long — not opcode bits.

Our DNS packet analyzer maps live resolver answers into typed rows with TTL. Think of it as the answer section expanded into a spreadsheet: each record is one RR the resolver would place in the response body.

type is the QTYPE name — A, AAAA, MX, TXT, NS, CNAME, SOA, SRV, or CAA. host is the owner name (QNAME or CNAME chain target). value is formatted RDATA — MX includes priority and hostname; TXT may span authentication strings.

TTL shows seconds the resolver will cache that RR. Low TTL on A records during cutover is intentional; unexpectedly low TTL on NS may signal instability. Compare TTL across types when planning cache flush windows.

byType mirrors how engineers mentally bucket DNS responses: all A answers together, all TXT together. Bloated TXT sections often correlate with slow mail receiver SPF expansion — visible when TXT array length dwarfs A count.

Empty byType keys mean NXDOMAIN or no answers for that type on the public path. Absence is data — document negative results in incident notes.

summary.ipv4 and summary.ipv6 list address targets. summary.mailServers parses MX priorities. summary.hasSpf and summary.hasDmarc booleanize authentication posture without reading every TXT string.

nameservers in summary reflect NS RRset at the queried name — compare against trace tools when delegation looks wrong.

Packet capture tools show retransmits, truncation, and EDNS buffer sizes our page does not surface. Use dig +tcp or Wireshark when UDP truncation is suspected. This analyzer excels when you need multi-type RR inventory faster than six separate dig commands.

Pair with DNS trace lookup when NS in summary disagrees with registrar expectations — delegation issues precede answer-section analysis.

During suspected hijack, export analyzer output immediately. TTL and value columns prove what resolvers cache. Attach queriedAt to tickets for audit trails.

Compare two exports minutes apart when TTL was lowered — changing values with stable TTL suggest authoritative edits; changing values with dropping TTL suggest active attacker rotation.

Automate with GET /ip-tools/api/extended?action=dns-history&domain=example.com. Parse records, byType, summary, and queriedAt from JSON. Integrate post-deploy verification in CI.

Same action powers DNS record history and DNS monitoring tool — choose page by workflow vocabulary, not different backend behavior.

Queries hit public DNS for names you submit. TXT may include DKIM and verification material — treat exports as sensitive.

Analyze domains you own or are authorized to investigate.

Persistent SERVFAIL, truncated responses, or DNSSEC validation failures need resolver-specific tooling. This page assumes NOERROR-style answers through Google Public DNS JSON API.

Authoritative-only records never published to public resolvers will not appear — AXFR or provider panel exports remain necessary for hidden staging records.