[arpa]

Oh how many fun things have been skipped! For example, errors in message header are a nibble. There is compression of sorts, and labels referenced by an offset. There is an unique notation of emails in the SOA records; and some domains and nameservers are just plain magic. If you set out to implement a complete DNS resolver, you are IN for a fun, fun, fun time with printouts of quite a few RFCs dating back to 1987 IIRC. But the most fun part is reading these documents and seeing a story - of networks that never came to be, of dawn of the internet, of very much constrained computers and networking equipment and the genius of the thing that still is the root of the internet as we know it even some 30 years later.

[bemmu]

I recently wrote a simple nonrecursive one in Python to see how many domains I could resolve per second. You quickly hit a limit when you try to use something like Google's 8.8.8.8 server too fast. If you do it recursively starting from root servers, can you go as fast as your bandwidth allows?

[rosstex]

I don't think you can give a recursive query to a root server.

[bemmu]

Sorry, what I meant with "recursive" was doing the recursion myself, instead of handing it off to a server like Google's DNS server. If I follow the replies starting from root server one by one, am I likely to hit some limit?

[oxymoron]

It seems unlikely that you were able to overload the Google public dns server, and it also seems unlikely that you were saturating your connection. Thus you probably hit a rate limit. If you go recursive, and cache at least the TLD servers, distributing requests evenly across the 13 logical servers that typically manage a TLD such as .com, you’ll probably see a much higher per second throughput than through the google server, but still constrained by rate limits.

[gog]

You shouldn't, but as there are multiple root servers you should round robin them instead of hitting the same one every time.