ogham / dog Goto Github PK

I have a python script called digs that do multiple dig on specified nameservers.

Today I am trying dog, and I love its ability to accept multiple nameservers.

~
❯ dog example.com MX -n 1.1.1.1 -n 8.8.8.8
MX example.com.  23h57m48s   0 ""
MX example.com. 1d0h00m00s   0 ""

However I can't point which is wich. What if dog have a separator between them if we supply multiple nameservers ?

~
❯ dog example.com MX -n 1.1.1.1 -n 8.8.8.8 -n x.x.x.x
[1.1.1.1]
MX example.com.  23h57m48s   0 ""
[8.8.8.8]
MX example.com. 1d0h00m00s   0 ""
[x.x.x.x]
MX example.com. 1d0h00m00s   0 ""

My current workaround is to use JSON output and filter the result:

dog on  master is 📦 v0.1.0 via 🦀 v1.48.0
❯ cargo r --  example.com MX -n 1.1.1.1 -n 8.8.8.8 -J |  jq .responses[0].answers[0]
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/dog example.com MX -n 1.1.1.1 -n 8.8.8.8 -J`
{
  "class": "IN",
  "exchange": "",
  "name": "example.com.",
  "preference": 0,
  "ttl": 86126,
  "type": "MX"
}

dog on  master is 📦 v0.1.0 via 🦀 v1.48.0
❯ cargo r --  example.com MX -n 1.1.1.1 -n 8.8.8.8 -J |  jq .responses[1].answers[0]
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/dog example.com MX -n 1.1.1.1 -n 8.8.8.8 -J`
{
  "class": "IN",
  "exchange": "",
  "name": "example.com.",
  "preference": 0,
  "ttl": 86252,
  "type": "MX"
}

By using rustls we could compile dog without requiring OpenSSL and compile using musl.

See osa1/tiny#179 and:

Rustls vs OpenSSL: (link: https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html)

• 15% quicker to send data
• 5% quicker to receive data
• 20-40% quicker to full handshake (client)
• 10% quicker to full handshake (server)
• 30-70% quicker to resume (client)
• 10-20% quicker to resume (server)
• Uses <1/2 as much RAM

Not sure if this is something that you might fix or if this is an issue with homebrew somehow, but trying to install dog via homebrew:
brew install dog on ubuntu 20.04, getting this error:

==> Downloading https://github.com/ogham/dog/archive/v0.1.0.tar.gz
Already downloaded: /home/pavel/.cache/Homebrew/downloads/e9869860b4b74bd1955a7e4be363a6bbd20d683ca8b4cf4942938e6567865c15--dog-0.1.0.tar.gz
==> cargo install
Last 15 lines from /home/pavel/.cache/Homebrew/Logs/dog/01.cargo:
  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-unknown-linux-gnu
  $TARGET = x86_64-unknown-linux-gnu
  openssl-sys = 0.9.58

  ', /home/pavel/.cache/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.58/build/find_normal.rs:157:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `dog v0.1.0 (/tmp/dog-20201110-1700102-b2dqt0/dog-0.1.0)`, intermediate artifacts can be found at `/tmp/dog-20201110-1700102-b2dqt0/dog-0.1.0/target`

Caused by:
  build failed

READ THIS: https://docs.brew.sh/Troubleshooting

Cool project!

It would be great if the --type parameter enabled the user to query types that dog doesn't know about.

RFC3597 section 5 describes a conventional text representation for unknown (and optionally known) RR types:

   In the "type" field of a master file line, an unknown RR type is
   represented by the word "TYPE" immediately followed by the decimal RR
   type number, with no intervening whitespace.

For example, --type=TYPE28 would be equivalent to --type=AAAA.

I'd contribute a patch, but unfortunately my hands are tied due to the license.

• The version of dog being used (dog --version)

dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

// I actually built dog from the latest source code. d2d22fd

• The command-line arguments you are using

DOG_DEBUG=trace dog -q example.com -H --nameserver="https://1.0.0.1:443/dns-query" --time

• Your operating system and hardware platform

Linux x86_64

# DOG_DEBUG=trace dog -q example.com -H --nameserver="https://1.0.0.1:443/dns-query" --time

[INFO dog] Running with options -> Options {
    requests: RequestGenerator {
        inputs: Inputs {
            domains: [
                Labels {
                    segments: [
                        (
                            7,
                            "example",
                        ),
                        (
                            3,
                            "com",
                        ),
                    ],
                },
            ],
            types: [
                1,
            ],
            classes: [
                IN,
            ],
            resolvers: [
                Specified(
                    "https://1.0.0.1:443/dns-query",
                ),
            ],
            transport_types: [
                HTTPS,
            ],
        },
        txid_generator: Random,
        edns: SendAndHide,
        protocol_tweaks: ProtocolTweaks {
            set_authoritative_flag: false,
            set_authentic_flag: false,
            set_checking_disabled_flag: false,
            udp_payload_size: None,
        },
    },
    measure_time: true,
    format: Text(
        Automatic,
        TextFormat {
            format_durations: true,
        },
    ),
}
[INFO dns_transport::https] Opening TLS socket to "1.0.0.1:443"
Error [network]: failed to lookup address information: Name or service not known
Ran in 5ms

Hi Benjamin

This amazing app had been added to the Scoop official main bucket (check ScoopInstaller/Main#1652, sorry for my latency), so scoop users could install dog via scoop install dog now.

• The exact dog commit you are building (git rev-parse --short HEAD)
• The version of rustc you are compiling it with (rustc --version) - rustc 1.43.0
• Your operating system and hardware platform - Ubuntu 20.04
• The Rust build target (the exact output of rustc --print cfg)

dog-0.1.0 Version

If you are seeing compilation errors, please include the output of the build process.

Compiling rand_core v0.5.1
Compiling dog v0.1.0 (/home/ubuntu/dog-0.1.0)
Compiling rand_chacha v0.2.2
Compiling rand v0.7.3
Compiling dns-transport v0.1.0 (/home/ubuntu/dog-0.1.0/dns-transport)
error[E0658]: use of unstable library feature 'str_strip': newly added
--> dns-transport/src/https.rs:109:36
|
109 | if let Some(sp) = self.url.strip_prefix("https://") {
| ^^^^^^^^^^^^
|
= note: see issue #67302 rust-lang/rust#67302 for more information

error: aborting due to previous error

For more information about this error, try rustc --explain E0658.
error: could not compile dns-transport.

To learn more, run the command again with --verbose.

When trying to query against a specified nameserver, the command fails. Please see the output below.

$ ./dog --version
dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

$ ping -6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.096 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.094 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.083 ms
^C
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2039ms
rtt min/avg/max/mdev = 0.083/0.091/0.096/0.005 ms

$ ./dog example.net TXT @::1
Error [network]: failed to lookup address information: Name or service not known

$ ./dog example.net TXT @[::1]
Error [network]: invalid port value

Hi, is there a limitation in dog that doesn't allow this:

dog -t SRV _servicename._tcp.example.com

Or am I using it wrong? dog gives the error:

Invalid options: Invalid domain "_servicename"

But underscores are a normal part of SRV queries, from what I gathered by reading https://tools.ietf.org/html/rfc2782. Thank you.

There should be some way to have dog emit statements when packets are sent and received, so a user making lots of requests (or a user who is just curious) can see their progress. Something similar to what nping does, possibly ANSI-dimmed so it does not distract from the actual output table.

Currently you can do this by setting DOG_DEBUG to non-empty, but this activates a lot of developer-related output that is not guaranteed to remain stable between releases.

Can't get no response from dog.exe on Windows 10 machine.

Sometimes it just hangs and sometimes it says:
Error [network]: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)

I've added Windows Firewall exception for dog.exe but it didn't help.

• The version of dog being used (dog --version)
  v0.1.0

• The command-line arguments you are using
  dog.exe example.net
  .\dog.exe example.net MX

• Your operating system and hardware platform
  Windows 10 Pro 20H2 (19042.630)

When running a query against a local DNS server operating to serve DNS over HTTPS, the SSL / TLS connection will not establish if the server has "self-signed" certificates. This is the case even if the system trusts the CA which signed these server certificates. It seems that perhaps Dog is basing it's trust decisions on the non-modified and OpenSSL supplied trust store and ignoring system set ones (such as are in /usr/local/share/ca-certificates).

$ dog mydevice.local -H @https://127.0.0.53/dns-query
Error [tls]: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1913: (self signed certificate)

First of all, thanks a lot for this really nice DNS client!

dog was recently packages in nixpkgs. I have opened a pull request to also add the shell completions and man page (NixOS/nixpkgs#103192) to the Nix package. However, pandoc is a really large dependency that increases evaluation time quite a bit.

Would it be possible to include a pregenerated version of the man page (dog.1) in the repository as well?

IDNA is Internationalizing Domain Names in Applications.

dig alredy does support it (I believe it's optional when it's compiled with libidn2 support). Example:

❯ dog кристал.мкд
Status: NXDomain

❯ dig +short кристал.мкд
92.55.64.104

dig man page documents its IDN support:

       +[no]idnin
              Process [do not process] IDN domain names on input. This requires IDN SUPPORT to have been enabled at compile time.

              The default is to process IDN input when standard output is a tty.  The IDN processing on input is disabled when dig output is redi‐
              rected to files, pipes, and other non-tty file descriptors.

       +[no]idnout
              Convert [do not convert] puny code on output. This requires IDN SUPPORT to have been enabled at compile time.

              The default is to process puny code on output when standard output is a tty. The puny code processing on output is disabled when dig
              output is redirected to files, pipes, and other non-tty file descriptors.
…
IDN SUPPORT
       If dig has been built with IDN (internationalized domain name) support, it can accept and display non-ASCII domain names. dig appropriately
       converts character encoding of domain name before sending a request to DNS server or displaying a reply from the server. If you'd  like  to
       turn off the IDN support for some reason, use parameters +noidnin and +noidnout or define the IDN_DISABLE environment variable.

• The version of dog being used (dog --version)

C:\WINDOWS\system32>dog --version --color=never
dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

• The command-line arguments you are using

dog --color=never example.net

• Your operating system and hardware platform

Windows 10
Version 1909 (OS Build 18363.1139)

With DOG_DEBUG=1:

C:\WINDOWS\system32>dog --color=never example.net
�[38;5;243m[�[0m�[36mINFO�[0m dog�[38;5;243m]�[0m Running with options -> Options {
    requests: RequestGenerator {
        inputs: Inputs {
            domains: [
                Labels {
                    segments: [
                        (
                            7,
                            "example",
                        ),
                        (
                            3,
                            "net",
                        ),
                    ],
                },
            ],
            types: [
                1,
            ],
            classes: [
                IN,
            ],
            resolvers: [
                SystemDefault,
            ],
            transport_types: [
                Automatic,
            ],
        },
        txid_generator: Random,
        edns: SendAndHide,
        protocol_tweaks: ProtocolTweaks {
            set_authoritative_flag: false,
            set_authentic_flag: false,
            set_checking_disabled_flag: false,
            udp_payload_size: None,
        },
    },
    measure_time: false,
    format: Text(
        Never,
        TextFormat {
            format_durations: true,
        },
    ),
}
�[38;5;243m[�[0m�[34mDEBUG�[0m dog::resolve�[38;5;243m]�[0m Found network adapter "{8BDFCD10-EE2C-4414-ABB3-2DDDE46042E4}"
�[38;5;243m[�[0m�[34mDEBUG�[0m dog::resolve�[38;5;243m]�[0m Found nameserver V6(2a00:1028:c000:ba6:828c:97ff:fed7:8b82)
�[38;5;243m[�[0m�[36mINFO�[0m dns_transport::udp�[38;5;243m]�[0m Opening UDP socket
Error [network]: invalid port value

C:\WINDOWS\system32>

dog v0.1.0
Windows 10 2004

When quering some domains for TXT records, dog only responds with Malformed packet:

dog gp.se TXT
Error [protocol]: Malformed packet: length 351 was specified, but read 7 bytes

dog svt.se TXT
Error [protocol]: Malformed packet: length 301 was specified, but read 237 bytes

dog kungalv.se TXT
Error [protocol]: Malformed packet: length 378 was specified, but read 172 bytes

dog kungalv.se TXT @1.1.1.1
Error [protocol]: Malformed packet: length 378 was specified, but read 172 bytes

dog kungalv.se TXT @8.8.8.8
Error [protocol]: Malformed packet: length 378 was specified, but read 172 bytes

Although most other domains I've tested works fine, for example

dog one.se TXT
TXT one.se. 30m00s   "v=spf1 redirect=_spf.one.se"

and other types of records seems to be no issue:

dog kungalv.se MX
MX kungalv.se.                             59m51s   10 "kungalv-se.mail.protection.outlook.com."
 A kungalv-se.mail.protection.outlook.com.     1s + 104.47.0.36
 A kungalv-se.mail.protection.outlook.com.     1s + 104.47.1.36

The sheepdog project, which is officially deprecated, but still depended on by a number of tools including libvirt-lxc and Gnome Boxes and hence preinstalled on a number of linux systems also uses dog as a command name. This can be seen with e.g:

$ sudo dnf provides dog
sheepdog-1.0.1-13.fc33.x86_64 : The Sheepdog distributed storage system for KVM/QEMU
Repo        : @System
Matched from:
Filename    : /usr/bin/dog

I'm not sure it's worth changing your name over collision with a project that is deprecated anyway, however this is still an issue that is good to be aware of as it will likely affect users until the dependencies on Sheepdog are removed from those projects upstream.

Right now it only resolves ipv4 records if no query type is specified, but it would be neat to show ipv6 records as well since, according to google, 30% of their traffic is ipv6 nowadays. :)

When a nameserver host name contains the 2 letters 'ns' in the first bit of the host name dog seems to think that it needs to look for the NS values, but that's not what needs to happen.

I've tried both the simple as well as the explicit defined arguments and the results are the same.

The version of dog being used (dog --version):

dog --version
dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

The command-line arguments you are using:

$ dog inbetweencows.nl MX @1.1.1.1 --seconds
MX inbetweencows.nl. 600   5 "mailfilter1.mijndomein.nl."
MX inbetweencows.nl. 600   6 "mailfilter2.mijndomein.nl."

$ dog inbetweencows.nl MX @nsn1.mijndomein.nl --seconds
MX inbetweencows.nl.  600   6 "mailfilter2.mijndomein.nl."
MX inbetweencows.nl.  600   5 "mailfilter1.mijndomein.nl."
NS inbetweencows.nl. 3600 A "nsn1.mijndomein.nl."
NS inbetweencows.nl. 3600 A "nsn2.mijndomein.nl."
NS inbetweencows.nl. 3600 A "nsn3.mijndomein.nl."

$ dog -q inbetweencows.nl -n nsn1.mijndomein.nl -t MX --seconds
MX inbetweencows.nl.  600   6 "mailfilter2.mijndomein.nl."
MX inbetweencows.nl.  600   5 "mailfilter1.mijndomein.nl."
NS inbetweencows.nl. 3600 A "nsn1.mijndomein.nl."
NS inbetweencows.nl. 3600 A "nsn2.mijndomein.nl."
NS inbetweencows.nl. 3600 A "nsn3.mijndomein.nl."

$ dog -q inbetweencows.nl -n 1.1.1.1 -t MX --seconds
MX inbetweencows.nl. 600   5 "mailfilter1.mijndomein.nl."
MX inbetweencows.nl. 600   6 "mailfilter2.mijndomein.nl."

Another namserver host name that contains 'ns' later in the string doesn't have this occurrence:

$ dog tussendekoeien.nl MX @max.ns.cloudflare.com --seconds
MX tussendekoeien.nl. 120   10 "mail.tussendekoeien.nl."

Your operating system and hardware platform:
(X)Ubuntu 20.10

Greetings,

Currently, IP/PTR look ups do not have the same polish of other records. The help output states -q, --query=HOST Host name or IP address to query, but it does not work for IPv4 or IPv6.

$ dog --version 
dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

$ dog --query=127.0.0.1
Status: NXDomain
SOA  35m04s A "a.root-servers.net." "nstld.verisign-grs.com." 2020111401 30m00s 15m00s 7d0h00m00s 1d0h00m00s

$ dig +short -x 127.0.0.1
localhost.localdomain.
localhost.

$ dog --query=::1
Status: NXDomain
SOA  35m11s A "a.root-servers.net." "nstld.verisign-grs.com." 2020111401 30m00s 15m00s 7d0h00m00s 1d0h00m00s

$ dig +short -x ::1
localhost.localdomain.
localhost.

One should not have to convert IPs to the in-addr.arpa or ip6.arpa domains, especially for IPv6. Should the default record for IPs be PTR?

$ dog 1.0.0.127.in-addr.arpa
SOA 127.in-addr.arpa. 3h00m00s A "localhost." "nobody.invalid." 1 1h00m00s 20m00s 7d0h00m00s 3h00m00s

$ dog 1.0.0.127.in-addr.arpa PTR
PTR 1.0.0.127.in-addr.arpa. 1h00m00s   "localhost.localdomain."
PTR 1.0.0.127.in-addr.arpa. 3h00m00s   "localhost."

$ dog 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
SOA 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 3h00m00s A "localhost." "nobody.invalid." 1 1h00m00s 20m00s 7d0h00m00s 3h00m00s

$ dog 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa PTR
PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 1h00m00s   "localhost.localdomain."
PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 3h00m00s   "localhost."

Also, ANY does not return PTR records for in-addr.arpa or ip6.arpa domains.

$ dog 1.0.0.127.in-addr.arpa ANY
SOA 127.in-addr.arpa. 3h00m00s A "localhost." "nobody.invalid." 1 1h00m00s 20m00s 7d0h00m00s 3h00m00s

$ dog 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa ANY
SOA 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 3h00m00s A "localhost." "nobody.invalid." 1 1h00m00s 20m00s 7d0h00m00s 3h00m00s

This seems to be the only rough edge on an otherwise slick project.

Running dog on Windows 10 Pro with Powershell or Powershell Core window does not generate the color coding expected.

Under the default Powershell terminal

Under the Powershell Core 7.1 terminal

• The version of dog being used (dog --version)
  v0.1.0

• The command-line arguments you are using
  ./dog.exe yahoo.com -n 8.8.8.8

• Your operating system and hardware platform

Windows 10 Pro
Version 2004 (OS Build 19041.630)

Love the idea and want to use this. Thanks for building it and releasing it.

If dog does something unexpected, or displays an error on the screen, or if it outright crashes, then please include the following information in your report:

• The version of dog being used (dog --version)
• The command-line arguments you are using
• Your operating system and hardware platform

If it’s a crash, please include the full text of the crash that gets printed to the screen. If you’re seeing unexpected behaviour, a screenshot of the issue will help a lot.

• os: MacOS Catalina 10.15.7
• version: v0.1.0 via brew
• desc: I setup DNS at OS Network setting as 1.1.1.1 and 1.0.0.1 but 1.1.1.1 is not supported in some places and this connection refused occurs when 1.1.1.1 is not supported. so it works fine if I remove 1.1.1.1. I guess dog should support other DNS ip/hostname if fails.

$ DOG_DEBUG=trace dog google.com MX
[TRACE dog::options] Got domain -> "google.com"
[TRACE dog::options] Got qtype -> "MX"
[INFO dog] Running with options -> Options {
    requests: RequestGenerator {
        inputs: Inputs {
            domains: [
                Labels {
                    segments: [
                        (
                            6,
                            "google",
                        ),
                        (
                            3,
                            "com",
                        ),
                    ],
                },
            ],
            types: [
                15,
            ],
            classes: [
                IN,
            ],
            resolvers: [
                SystemDefault,
            ],
            transport_types: [
                Automatic,
            ],
        },
        txid_generator: Random,
        edns: SendAndHide,
        protocol_tweaks: ProtocolTweaks {
            set_authoritative_flag: false,
            set_authentic_flag: false,
            set_checking_disabled_flag: false,
            udp_payload_size: None,
        },
    },
    measure_time: false,
    format: Text(
        Automatic,
        TextFormat {
            format_durations: true,
        },
    ),
}
[INFO dns_transport::udp] Opening UDP socket
[DEBUG dns_transport::udp] Opened
[INFO dns_transport::udp] Sending 39 bytes of data to 1.1.1.1 over UDP
[DEBUG dns_transport::udp] Wrote 39 bytes
[INFO dns_transport::udp] Waiting to receive...
Error [network]: Connection refused (os error 61)

Version: v0.1.0
OS: Linux

dog example.net mx should likely return the same as dog example.net MX. dig does not care about the capitalization of the dns query type, and not setting the correct capitalization would be an easy thing for a user to miss.

You can install dog using a command

cargo install --git https://github.com/ogham/dog dog

It is simpler than cloning a repository, and it already works. Maybe add this as an installation method in the docs?
However I would prefer to simply write

cargo install dog

if it is possible

Hi,

I believe in the README.md it should state "just --list" instead of "just --tasks". At least thats what the just documenation says: https://github.com/casey/just#listing-available-recipes

Best regards,
Alessandro

When a line starting with search containing hostnames is given in resolv.conf, it will make Linux append these hostnames to a query without any dots in it when doing lookups:

• https://bash-prompt.net/guides/resolv-conf/
• https://superuser.com/questions/570082/in-etc-resolv-conf-what-exactly-does-the-search-configuration-option-do

dog should support this too. It's feasible because we do our own resolv.conf parsing, but would require some restructuring because it's in a "get list of resolvers" function, not a "get general resolv configuration" function, so there's no way to return the data we need. I also think it should inform the user that this is happening somehow.

Hi @ogham 👋

Thanks for building this neat utility. 👍

I've created a Homebrew formula for dog but until it passes 75 stars it can't be submitted to the default formulae. Once that happens feel free to ping me or submit my work directly. In the meantime, you can test it using the following command:

brew install vladimyr/vladimyr/dog

Formula source → https://github.com/vladimyr/homebrew-vladimyr/blob/aa8e7e1/Formula/dog.rb

One killer feature would be to have a hint on the resolution source. For example, if I do dog example.com and I have example.comremmaped in my /etc/hosts file, it should show something, like a H at the end of the line.

I don't know how feasible it is, but having a distinction between the following sources would be great:

• Regular DNS
• mDNS (local)
• /etc/hosts

I think the last one could be easy, just grep the file, but I don't know about the first two.

Commonly used in existing tools are flags -4 and -6. Constraining query to a specific protocol family is essential to validate if query/response behaviour may differ between IPv4 and via IPv6 and to figure out on which point in the network stuff queries are screwed up.

Examples where these flags are available are dig, and its TLS supporting sibling kdig:

• https://linux.die.net/man/1/dig
• https://www.knot-dns.cz/docs/2.6/html/utilities.html

I have a standard UDP/TCP-only nameserver setup, trying to pass -H to dog results in a panic and abort instead of an error message (there's nothing useful in the backtrace):

> dog nemo157.com -H
thread 'main' panicked at 'Invalid HTTPS nameserver', dns-transport/src/https.rs:55:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[1]    2815113 abort (core dumped)  dog nemo157.com -H

Using current master:

> jq -r '.installs | keys[] | select(contains("dog"))' ~/.cargo/.crates2.json
dog 0.1.0 (git+https://github.com/ogham/dog#445ed98bcfd8d2e4cbb8e924e6cf69ad5f9589e1)

Is there any way to generate and include .debs in the release page? I've seen other projects have them, so I imagine there's a Cargo utility to generate them, and they're much more useful than plain zips.

• dog version: 0.1.0 (Downloaded prebuilt binary from https://github.com/ogham/dog/releases/tag/v0.1.0 )
• OS: Windows 10 (Microsoft Windows [Version 10.0.19042.572])

Maybe need to call enable_ansi_support function somewhere...?

Can´t seem to get this to work, am I missing something obvious?

Dog

❯ dog google.com
Error [network]: No such host is known. (os error 11001)

Dig

❯ dig google.com

; <<>> DiG 9.14.8 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46221
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             240     IN      A       172.217.21.174

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Nov 09 16:25:04 W. Europe Standard Time 2020
;; MSG SIZE  rcvd: 55

Version information

❯ dog --version
dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

Edition	Windows 10 Pro for Workstations
Version	20H2
Installed on	‎2020-‎06-‎17
OS build	19042.610
Experience	Windows Feature Experience Pack 120.2212.31.0

dog builds just fine on my arm64 machine (once I give it a suitably up-to-date version of rustc). Any chance of distributing an arm64 binary?

I think it might be simple as adding an arch matrix to the Travis builds.

I use Windows10 with WSL2, and I put the dog to the environment.

When I run dog command line, I got this problem.

Hello, I don't see any kind of DNSSEC support, either in the query space (no DNSKEY or DS recognized) or in the resolving/validation part (I don't see any check for AD bit and validation) or even in the displayed fields. Thanks.

Maybe add a special DNS record type ALL to query all known types?
It would be very handy feature

I really like this tool! However, one convenience feature that I'm missing is "Just show me commonly useful information about this domain". I know that with dig and drill you can use ANY but that's not quite what I want in most cases. Frankly, I'd be happy about ALL or --all or something like that which showed the equivalent of dog example.net A AAAA NS MX TXT SOA CNAME. Personally, I'd even like that by default.

For instance, nowadays you at least have A and AAAA entries and dog by default only shows A which I don't think is very "modern" as a default. I know that other tools have the same default but in my understanding, dog is supposed to be convenient, too.

If dog does something unexpected, or displays an error on the screen, or if it outright crashes, then please include the following information in your report:

• The version of dog being used (dog --version) - v.0.1.0
• The command-line arguments you are using - dog
• Your operating system and hardware platform - Intel CPU, Ubuntu 20.04 (Pop_OS!)

If it’s a crash, please include the full text of the crash that gets printed to the screen. If you’re seeing unexpected behaviour, a screenshot of the issue will help a lot.

Placed the binary in /usr/local/bin and try to run dog or dog --version results in the following error:

user@laptop:~$ dog
dog: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.32' not found (required by dog) user@laptop:~$ dog --version dog: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.32' not found (required by dog)

It appears that 20.04 LTS has 2.31 by default, where 20.10 has the 2.32. Is it not possible to run on Ubuntu without manually installing the newer packages?

dog fails to compile due to rust-lang/rust#65721

• The exact dog commit you are building (git rev-parse --short HEAD)
  git rev-parse --short HEAD

• The version of rustc you are compiling it with (rustc --version)
  rustc 1.41.1 (f3e1a954d 2020-02-24)

• The Rust build target (the exact output of rustc --print cfg)

Output:

cargo build
Updating crates.io index
Updating git repository https://github.com/llogiq/mutagen
Downloaded log v0.4.11
Downloaded rand v0.7.3
Downloaded serde_json v1.0.59
Downloaded byteorder v1.3.4
Downloaded getopts v0.2.21
Downloaded serde v1.0.117
Downloaded native-tls v0.2.4
Downloaded httparse v1.3.4
Downloaded datetime v0.5.1
Downloaded ansi_term v0.12.1
Downloaded atty v0.2.14
Downloaded regex v1.4.2
Downloaded cfg-if v0.1.10
Downloaded getrandom v0.1.15
Downloaded openssl-probe v0.1.2
Downloaded openssl v0.10.30
Downloaded libc v0.2.80
Downloaded rand_core v0.5.1
Downloaded itoa v0.4.6
Downloaded openssl-sys v0.9.58
Downloaded ryu v1.0.5
Downloaded rand_chacha v0.2.2
Downloaded unicode-width v0.1.8
Downloaded foreign-types v0.3.2
Downloaded lazy_static v1.4.0
Downloaded autocfg v1.0.1
Downloaded cc v1.0.61
Downloaded pkg-config v0.3.19
Downloaded ppv-lite86 v0.2.10
Downloaded bitflags v1.2.1
Downloaded regex-syntax v0.6.21
Downloaded foreign-types-shared v0.1.1
Compiling libc v0.2.80
Compiling cfg-if v0.1.10
Compiling cc v1.0.61
Compiling pkg-config v0.3.19
Compiling autocfg v1.0.1
Compiling bitflags v1.2.1
Compiling log v0.4.11
Compiling getrandom v0.1.15
Compiling foreign-types-shared v0.1.1
Compiling openssl v0.10.30
Compiling byteorder v1.3.4
Compiling lazy_static v1.4.0
Compiling httparse v1.3.4
Compiling ryu v1.0.5
Compiling regex-syntax v0.6.21
Compiling native-tls v0.2.4
Compiling serde v1.0.117
Compiling serde_json v1.0.59
Compiling openssl-probe v0.1.2
Compiling ppv-lite86 v0.2.10
Compiling unicode-width v0.1.8
Compiling itoa v0.4.6
Compiling ansi_term v0.12.1
Compiling foreign-types v0.3.2
Compiling getopts v0.2.21
Compiling dns v0.1.0 (/opt/dog/dog/dns)
error[E0658]: use of unstable library feature 'matches_macro'
--> dns/src/types.rs:217:9
|
217 | matches!(self, Self::Standard { .. })
| ^^^^^^^
|
= note: for more information, see rust-lang/rust#65721

Compiling datetime v0.5.1
Compiling atty v0.2.14
Compiling openssl-sys v0.9.58
Compiling rand_core v0.5.1
error: aborting due to previous error

For more information about this error, try rustc --explain E0658.
error: could not compile dns.
warning: build failed, waiting for other jobs to finish...
error: build failed

I certainly miss AXFR support to view all records in zone and have to fall back to dig

Maybe something like:

./dog -H @https://doh:[email protected]/dns-query example.nl

Albeit this method is deprecated as per RFC3986, par. 3.2.1, so perhaps "-u doh -p BeGentle" would be the better approach.

On my system, no matter what I query, I always get:

dog example.net
Error [network]: Connection refused (os error 111)

dog google.com
Error [network]: Connection refused (os error 111)

$ dog --version 
dog ● command-line DNS client
v0.1.0
https://dns.lookup.dog/

I'm on Arch Linux. My network is actually fairly simple. I use systemd-resolved for my usual DNS. drill and dig are perfectly happy performing the queries.

$ resolvectl
Global
       LLMNR setting: yes                 
MulticastDNS setting: yes                 
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
  Current DNS Server: 127.0.0.1           
         DNS Servers: 127.0.0.1           
Fallback DNS Servers: 1.1.1.1             
                      9.9.9.10            
                      8.8.8.8             
                      2606:4700:4700::1111
                      2620:fe::10         
                      2001:4860:4860::8888

Link 2 (enp67s0)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

Link 3 (br0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes                      
       LLMNR setting: yes                      
MulticastDNS setting: no                       
  DNSOverTLS setting: no                       
      DNSSEC setting: no                       
    DNSSEC supported: no                       
  Current DNS Server: 10.13.37.1               
         DNS Servers: 10.13.37.1               
                      fd00::3681:c4ff:fee4:7801

Link 4 (docker0)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

Link 5 (br-b1c82fd2937d)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

As for now, it's quite challenging to cross-compile this project.
To let the users pass additional features like openssl-vendored would make it much more comfortable. However, I would also recommend switching to rustls (#21).

Version: v0.1.0
OS & hardware: macOS 10.15.7, 2020 MacBook Pro 16"
Arguments: dog TXT canvasmedical.com

$ dog TXT canvasmedical.com
Error [protocol]: Malformed packet: length 105 was specified, but read 69 bytes

Works with dig.

I often setup new machines and want to quickly grab Go/Rust binaries from github, so I wrote a web service to do this https://github.com/jpillora/installer (e.g. curl https://i.jpillora.com/ogham/dog!). This seems like a common thing people do (e.g. https://github.com/jpillora/chisel#install see binary download count).

You might not be in favour shell one liners, completely understand, feel free to close. Also, awesome project! This will definitely be replacing host / dig, just like exa has replaced ls 😁

Hey there!

I noticed that for DoT and DoH there is no way to pin the resolver's IP while still passing the hostname that should be used for TLS's SNI. The way unbound deals with this is by allowing you to pin all details about the nameserver (like this, on my personal unbound configuration), and on that same note I also noticed that there is no way to specify different port's for the nameserver.

So I'll leave these feature suggestions here for your consideration:

1. Adding a --port and -p flags for when the DNS server is not running on the standard port number (such as local testing with unbound and such);
2. Adding a dedicated --sni flag for DoT and DoH so that using Google DNS with DoT would look like:

   dog example.com --nameserver=8.8.8.8 --sni=dns.google --port=853
   

3. Maybe adding some shorthand syntax that looks like curl's --resolve or unbound's for use with @nameserver... or the -n flag that can be parsed in one go, such as dns.google:8.8.8.8:853 or something?

Thanks for dog btw! As someone who uses dig a lot, better tooling in this area is greatly appreciated :D

If dog does something unexpected, or displays an error on the screen, or if it outright crashes, then please include the following information in your report:

• N/A
• -S vs -T
• N/A

If it’s a crash, please include the full text of the crash that gets printed to the screen. If you’re seeing unexpected behaviour, a screenshot of the issue will help a lot.

The docs (specifically https://dns.lookup.dog/features/dns-over-tls) reference DoT being -T, but -T is for TCP, not TLS (TLS is -S) (tested to make sure, corroborated by other parts of the manual)

Sorry if this isn't the right place, I couldn't find the docs repository

It would be cool if dog shows the used nameserver to query.

If a nameserver is specified, it is clear of course.

But especially if no nameserver is specified, it would be helpful to know which nameserver was chosen.
dig also shows this info.

hey, first of all, I like this approach! :)

has everything I want from dig, but with an easier-to-read output.

Would you mind providing an AUR package (for Arch Linux)?