
How to hand-write DNS messages - jmlr
https://routley.io/tech/2017/12/28/hand-writing-dns-messages.html
======
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.

------
userbinator
Writing a simple DNS resolver is a common assignment in networking courses,
and I do recommend it --- keeping in mind that the protocol was designed to
work on machines with a fraction of the memory and CPU power as those today,
helps understanding some of the otherwise odd design decisions; for example,
requests and replies have the same format and header to allow the same buffer
to be reused for both receiving the request and sending the reply. The QCLASS
is another field from a time when people thought DNS would be used for
networks other than the Internet.

A minor correction: DNS deals only with the _hostname_ or _authority_
component of the URL, so any mention of "URL encoding" doesn't make sense in
this context.

~~~
tcprst
I'd say any mention of URL should be avoided for the sake of confusion.

I can't count the number of times I've been asked by a developer running a web
server on a random port to "make sure to include the port" on the A record I'm
adding.

