What's the anatomy of a DNS session?

I'm working on a homework assignment that basically asks us to parse a DNS response to get the IP address and such. The problem is the professor has told us in great detail what the response looks like from the DNS server, but I don't know what to send the server. My first attempt was to netcat <ip address of local name server> 53 and just type in www.google.com and hit enter and look for a response but I didn't get anything back.

Can anyone describe to me what a DNS query looks like (like开发者_开发知识库 how many bytes are allowed for each part of the query)?

---

1. Download wireshark, and run it
2. Do something that uses DNS (make sure you aren't using a cached hostname)
3. Look through the wireshark packets that are captured.

---

This should be covered by RFC 1034, section 3.7, but I kind of glazed over just skimming it, let alone actually reading the thing.

---

The basic shape of a DNS query is a short header that's essentially all fixed byte values, followed by what you'd get if you took the name, prefixed it with a dot (.), then replaced each dot with a byte in the range 1-63 indicating the length of the following segment of the name up to the next dot, followed by some more fixed-value bytes. As long as all you're doing is basic address lookups and nothing fancy like zone transfers, this is about all you need to know about DNS protocol.

For details of the header, etc. fields, read RFC 1035. Or just copy them from a packet sniffer dump. The only thing you'll want to vary is the query id (it should be suitably random to avoid trivial spoofing attacks against your program), and possibly the RR type (for instance if you need to query IPv6 (AAAA) or reverse DNS (PTR) records in addition to just A.

---

This doesnt directly answer your question, but try running nslookup for the commandline and look at the options available. You can instruct it to query for specific items, such as the MX records etc.

But if you are more interested in what the protocol itself looks like? this RFC has way more info than you could possibly want: https://www.rfc-editor.org/rfc/rfc1035