3 ms·

Author here. Didn't expect this to show up so soon, but I'm glad people like it — I only published v0.1 on Saturday. Over on the Rust forum I gave a brief over

by cytzol 6y ago

Author here. Didn't expect this to show up so soon, but I'm glad people like it — I only published v0.1 on Saturday. Over on the Rust forum I gave a brief overview of the crates and developer tools I used: https://users.rust-lang.org/t/dog-a-command-line-dns-client/51178?u=ogham https://users.rust-lang.org/t/dog-a-command-line-dns-client/...

mattl 6y ago
Glad we’ve proven dogs can look up
alpb 6y ago
This is great, already installed via Homebrew. Something that puzzles me while using dig(1) is that I don't really understand the +trace output. In my mind it should be rather easy to trace a DNS request, something like: dig A google.com → etc/resolv.conf says your nameserver is X.Y.Z.T → made a query to X.Y.Z.T, it recursed → domain google.com has nameserver ns.a.b. → ADDITIONAL section told us ns.a.b is at X.C.F.G IP → made dns query to X.C.F.G, it told us it was Authoritative and gave RRs [IP1, IP2]. I never quite can get this level of clarity from dig(1), instead, "dig A google.com +trace" gives an output like this: https://gist.github.com/ahmetb/28a3853bef72fbabf4f0d8ac0712a38d https://gist.github.com/ahmetb/28a3853bef72fbabf4f0d8ac0712a... which makes me think like: what the hell, am I actually hitting root nameservers every time? If your tool can help developers here, I think it's a major value add.
- kbenson 6y ago
  > what the hell, am I actually hitting root nameservers every time? Trace hits the roots because trace is for tracing the lookups from the root nameservers through the rest of the path. It's in the man page: +[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. ...
- cesarb 6y ago
  > made a query to X.Y.Z.T, it recursed If it recursed, then X.Y.Z.T gave you the final response. It doesn't tell you how it arrived at that final response, and it might not even know (it only saves the final response in the cache). The output of dig +trace is the steps a recursive resolver would have to follow if it started from scratch (with a cold cache).
  - alpb 6y ago
    Oh yeah my bad, in that case, let's say "X.Y.Z.T said it doesn't support recursion".
OJFord 6y ago
Be honest - did you write this just for the name and resulting gags?
- cytzol 6y ago
  All I'm saying is that lookup.dog was originally going to contain a Shaun of the Dead GIF and nothing else, in the same vein as butt.holdings or cheese.singles. The DNS part came later.
leshow 6y ago
Great work here, interesting project. I get the desire to roll your own versions of things, but personally I'd feel more comfortable using it if it used the standard community packages for dns and logging like trust-dns and tracing though.

by cytzol 6y ago

mattl 6y ago

Glad we’ve proven dogs can look up

alpb 6y ago

This is great, already installed via Homebrew. Something that puzzles me while using dig(1) is that I don't really understand the +trace output. In my mind it should be rather easy to trace a DNS request, something like: dig A google.com → etc/resolv.conf says your nameserver is X.Y.Z.T → made a query to X.Y.Z.T, it recursed → domain google.com has nameserver ns.a.b. → ADDITIONAL section told us ns.a.b is at X.C.F.G IP → made dns query to X.C.F.G, it told us it was Authoritative and gave RRs [IP1, IP2]. I never quite can get this level of clarity from dig(1), instead, "dig A google.com +trace" gives an output like this: https://gist.github.com/ahmetb/28a3853bef72fbabf4f0d8ac0712a38d https://gist.github.com/ahmetb/28a3853bef72fbabf4f0d8ac0712a... which makes me think like: what the hell, am I actually hitting root nameservers every time? If your tool can help developers here, I think it's a major value add.

kbenson 6y ago
> what the hell, am I actually hitting root nameservers every time? Trace hits the roots because trace is for tracing the lookups from the root nameservers through the rest of the path. It's in the man page: +[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. ...
cesarb 6y ago
> made a query to X.Y.Z.T, it recursed If it recursed, then X.Y.Z.T gave you the final response. It doesn't tell you how it arrived at that final response, and it might not even know (it only saves the final response in the cache). The output of dig +trace is the steps a recursive resolver would have to follow if it started from scratch (with a cold cache).
- alpb 6y ago
  Oh yeah my bad, in that case, let's say "X.Y.Z.T said it doesn't support recursion".

OJFord 6y ago

Be honest - did you write this just for the name and resulting gags?

cytzol 6y ago
All I'm saying is that lookup.dog was originally going to contain a Shaun of the Dead GIF and nothing else, in the same vein as butt.holdings or cheese.singles. The DNS part came later.

leshow 6y ago

Great work here, interesting project. I get the desire to roll your own versions of things, but personally I'd feel more comfortable using it if it used the standard community packages for dns and logging like trust-dns and tracing though.