adamchalmers / blog

1 stars 2 forks source link

What I learned from making a DNS client in Rust #5

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

What I learned from making a DNS client in Rust

A lot about sockets, syscalls and bits

https://blog.adamchalmers.com/making-a-dns-client/

mupi2k commented 2 years ago

If all you want is the A record (as suggested by your +short example), you don't even need dig... nslookup or host will work. Dig's real power is looking up other records (NS, MX, TXT (for validating SPF/DKIM/DMARC) SOA (which is extremely valuable for a DNS company...)

jfmatth commented 2 years ago

Thanks for sharing, a very interesting article. I'm with you DIG is very confusing to me too, but your article helped some.

Please keep up the contributions, you have a lot to offer.

adamchalmers commented 2 years ago

@mupi2k Thanks, I hadn't ever used nslookup or host before, they're nifty. I'm glad I eventually learned how to tune dig to my liking, generally just using +noall and then adding in the sections I want.

@jfmatth Thank you :)

mycroes commented 2 years ago

You could also write a library to communicate with Siemens PLC's over the S7 protocol. It requires 2 RFCs, 2 well-written blogposts and much of what you needed for your DNS client. I actually want to start using Rust as well, just haven't found the right idea to start with yet... Thanks for your post though, I enjoyed reading it!

vassilevsky commented 2 years ago

Great job! Seems like Rust is a great language for this kind of tasks. Must've been satisfying to learn the protocol and get it to work :)

If you want to see a powerful built-in binary parsing / construction syntax, do take a look at Erlang. For example:

https://pagefault.se/post/interesting-ideas-in-plt-erlang-binary/

adamchalmers commented 2 years ago

@vassilevsky Wow, that's a really neat feature. Being able to pattern-match on all those bytes, unpack them, and put the remainder into another variable for later matching is super easy.

ryansb commented 2 years ago

Not that you asked, but there's actually a reason behind the dig output looking like this:

;; QUESTION SECTION:
;adamchalmers.com.      IN  A

;; ANSWER SECTION:
adamchalmers.com.   300 IN  A   104.19.237.120
adamchalmers.com.   300 IN  A   104.19.238.120

Semicolons are a comment character in the zonefile format used by bind and other DNS servers. Say you're an admin wanting to export an existing record to a new zone file for a migration or something.

You could run dig adamchalmers.com >> myzone.domainname and not have to grep/sed out the extra output and it would already be in the correct zonefile format. All the ; prefixed lines are ignored, and the answer matches NAME\tTTL\tSCOPE\tTYPE\tVALUE where \t are tab characters. It's a handy output format for that use case, but perhaps not a great default since I imagine most dig users would rather it always be +short.

adamchalmers commented 2 years ago

That's really interesting, thanks so much Ryan! Knowing why definitely makes the cryptic output less frustrating.

jiaxuan-guo commented 1 year ago

Awesome, thank you for sharing!!