search

mr-karan / doggo

:dog: Command-line DNS Client for Humans. Written in Golang
https://doggo.mrkaran.dev/
GNU General Public License v3.0
3.07k stars 101 forks source link

Hostname verification over TLS #29

Closed faandg closed 2 years ago

faandg commented 3 years ago

Hi,

Just came across this doggo after looking for a way to do DoT lookups, looks neat and appreciate the colored formatting, nice work.

I want to do a lookup with a couple of specific nameservers but it requires tls hostname verification.

doggo google.se @tls://193.19.108.3
ERROR[2021-08-25T16:45:40+02:00] error looking up DNS records 
error="x509: cannot validate certificate for 193.19.108.3 because it doesn't contain any IP SANs"

Is there a way we can pass the expected hostname of the dns resolver like adblock.doh.mullvad.net for verification? If I use doggo google.se @tls://adblock.doh.mullvad.net, the lookup succeeds but then I do not know which of mullvad's servers responded (there are 2 nameservers listed under adblock.doh.mullvad.net) and I want to be able to test them individually.

cbuijs commented 2 years ago

I was wondering if this could be solved like this (based on google dns):

doggo @tls://dns.google:443/dns-query -n 8.8.4.4 .......

Then you have the IP (no DNS leakage due to hostname resolution by doggo) already, and the hostname specified. Seems the libraries/modules used already to hostname-verification if a hostname is used (but I could be wrong).

But it seems as soon as -n is used, doggo reverts back to udp/unencrypted?

BTW: Using the --nameserver version of the option results in an error as unknown option.

mr-karan commented 2 years ago

But it seems as soon as -n is used, doggo reverts back to udp/unencrypted?

Hm, that seems a bug. I'll investigate.

cbuijs commented 2 years ago

But it seems as soon as -n is used, doggo reverts back to udp/unencrypted?

Hm, that seems a bug. I'll investigate.

It is actually doing both when specified:

doggo @https://dns.google:443/dns-query -n 8.8.4.4 -q google.com ns
NAME        TYPE    CLASS   TTL     ADDRESS         NAMESERVER                       
google.com. NS      IN      15862s  ns4.google.com. 8.8.4.4:53                          
google.com. NS      IN      15862s  ns1.google.com. 8.8.4.4:53                          
google.com. NS      IN      15862s  ns2.google.com. 8.8.4.4:53                          
google.com. NS      IN      15862s  ns3.google.com. 8.8.4.4:53                          
google.com. NS      IN      21600s  ns1.google.com. https://dns.google:443/dns-query    
google.com. NS      IN      21600s  ns2.google.com. https://dns.google:443/dns-query    
google.com. NS      IN      21600s  ns3.google.com. https://dns.google:443/dns-query    
google.com. NS      IN      21600s  ns4.google.com. https://dns.google:443/dns-query

I think when something else then udp:// and tcp:// is used, the ip-address with -n should be used for the name-server hostname, instead of resolving it using the system resolver (which would be the default if -n was not specified).

This is also nice to have all dns traffic encrypted, and prevent some unencrypted leakage during bootstrap of the hostname IP.

Great tool BTW, keep up the good work!

mr-karan commented 2 years ago

I've decided to add 2 new flags:

➜  doggo git:(main) ✗ ./bin/doggo.bin google.se @tls://193.19.108.3 --tls-hostname=adblock.doh.mullvad.net
NAME        TYPE    CLASS   TTL     ADDRESS         NAMESERVER       
google.se.  A       IN      300s    142.250.200.3   193.19.108.3:853    

➜  doggo git:(main) ✗ ./bin/doggo.bin google.se @tls://193.19.108.3 --skip-hostname-verification 
NAME        TYPE    CLASS   TTL ADDRESS         NAMESERVER       
google.se.  A       IN      30s 142.250.200.3   193.19.108.3:853

Will push soon.

mr-karan commented 2 years ago

Released https://github.com/mr-karan/doggo/releases/tag/v0.5.2 which has these flags.

Feel free to re-open in case I missed something.