Slow local DNS lookup

johnpoz

@Antibiotic that really has nothing to do with browsing or openvpn over udp.. those are queries in unbound waiting in the que.. Unless you have 1000's of clients doing a lot of queries and really a under powered dns that should never be a problem.. You could set it to couple or 3 seconds or so if you wanted.. But I doubt it will ever come into play.

Antibiotic

@johnpoz Thank you so much!

patient0

@Antibiotic nothing very technical but is there a reason you use cloudflare-dns.com as hostnames for 1.1.1.1 and 1.0.0.1 instead of one.one.one.one that Cloudflare mentions (and that resolve to the 1.1.1.1 and 1.0.0.1)?

Antibiotic

@patient0 No any reason

patient0

@Antibiotic Ok, I'm a bit suprised it does work since cloudflare-dns.com does resolve to totally different IPs.

dig +short cloudflare-dns.com
104.16.248.249
104.16.249.249

But nevermind, perfect if it works.

johnpoz

@patient0 said in Slow local DNS lookup:

m a bit suprised it does work since cloudflare-dns.com does resolve to totally different IPs.

it really shouldn't because what should happen when you forward over tls is you should validate the server your talking to responds with the correct cn/san in the cert.. A sane client should complain.. Part of the whole dot thing is validation your talking to who you expect to be talking too.

If your just forwarding it wouldn't matter, but using dot it should matter

edit: example of dot query doing tls validation

Here is simple example where it passes

$ doggo.exe @tls://192.168.2.253 nas.home.arpa --tls-hostname=doh.home.arpa
NAME            TYPE    CLASS   TTL     ADDRESS         NAMESERVER
nas.home.arpa.  A       IN      3600s   192.168.9.10    192.168.2.253:853

Here is example where it fails

 doggo.exe @tls://192.168.2.253 nas.home.arpa --tls-hostname=server.com
time=2024-11-04T07:23:30.002-06:00 level=ERROR msg="error in lookup" error="tls: failed to verify certificate: x509: certificate is valid for doh.home.arpa, not server.com"
NAME    TYPE    CLASS   TTL     ADDRESS NAMESERVER

Now a real dot query, should not only validate the cn/san name matches, but that the cert is signed by a CA that the client trusts.

Antibiotic

@johnpoz So cloudflare-dns.com is correct for DOT or should make one.one.one.one ? Now I'm in doubt)))

johnpoz

@Antibiotic 1111 answers back with

certificate is valid for cloudflare-dns.com, *.cloudflare-dns.com, one.one.one.one

So any of those would validate, if that is actually been checked.. put something in wrong and see if answers. I don't use dot so not sure if unbound is even validating that, or if there is some option you have to enable for it to do it.

But using cloudflare-dns.com is returned by the cert when you talk to 1111

same goes for 1001

edit: I remembered another client I have that can do dot queries. See how it passes with one.one.one.one, but fails with wrong hostname

user@UC:~$ kdig -d @1.1.1.1 +tls-ca +tls-host=one.one.one.one example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 146 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: 4pqQ+yl3lAtRvKdoCCUR8iDmA53I+cJ7orgBLiF08kQ=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
;; DEBUG:      SHA-256 PIN: Wec45nQiFwKvHtuHxSAMGkt19k+uPSw9JlEkxhvYPHk=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 31692
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 408 B

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

;; ANSWER SECTION:
example.com.            2720    IN      A       93.184.215.14

;; Received 468 B
;; Time 2024-11-04 10:48:52 CST
;; From 1.1.1.1@853(TCP) in 57.1 ms

user@UC:~$ kdig -d @1.1.1.1 +tls-ca +tls-host=one.one.one.two example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 146 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: 4pqQ+yl3lAtRvKdoCCUR8iDmA53I+cJ7orgBLiF08kQ=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
;; DEBUG:      SHA-256 PIN: Wec45nQiFwKvHtuHxSAMGkt19k+uPSw9JlEkxhvYPHk=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The name in the certificate does not match the expected. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 1.1.1.1@853(TCP)
user@UC:~$

And notice the 146 system certs imported, so with this test the cert has to be trusted as well, not just match on name.. See how it fails because this system doesn't trust my CA.. Let me get it to trust it and do the same test.. I have never installed my local CA on this system, because it never used to access anything I use local certs for.

user@UC:~$ kdig -d @192.168.2.253 +tls-ca +tls-host=doh.home.arpa nas.home.arpa
;; DEBUG: Querying for owner(nas.home.arpa.), class(1), type(1), server(192.168.2.253), port(853), protocol(TCP)
;; DEBUG: TLS, imported 146 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=doh.home.arpa,C=US,ST=IL,L=Schaumburg,O=Home,OU=Home CA
;; DEBUG:      SHA-256 PIN: 1ooj7dE/is2fHGbRskOqdnb2Cg4OFm/93Pzy0MNObLk=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The certificate issuer is unknown. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 192.168.2.253@853(TCP)
user@UC:~$

Antibiotic

@johnpoz Thanks'

johnpoz

@Antibiotic just to be complete, I added my homeCA to trusted, and now it validated the cert and trusts it

user@UC:/$ kdig -d @192.168.2.253 +tls-ca +tls-host=doh.home.arpa nas.home.arpa
;; DEBUG: Querying for owner(nas.home.arpa.), class(1), type(1), server(192.168.2.253), port(853), protocol(TCP)
;; DEBUG: TLS, imported 147 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=doh.home.arpa,C=US,ST=IL,L=Schaumburg,O=Home,OU=Home CA
;; DEBUG:      SHA-256 PIN: 1ooj7dE/is2fHGbRskOqdnb2Cg4OFm/93Pzy0MNObLk=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1939
;; Flags: qr aa rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 406 B

;; QUESTION SECTION:
;; nas.home.arpa.               IN      A

;; ANSWER SECTION:
nas.home.arpa.          3600    IN      A       192.168.9.10

;; Received 468 B
;; Time 2024-11-04 11:00:02 CST
;; From 192.168.2.253@853(TCP) in 43.8 ms
user@UC:/$

Notice it listed 147 now, since I added my homeca

This is how sane client doing dot or doh should function, the cert being used should match cn/san and the CA that signed/issued that cert should be trusted by the system. Off the top I am not sure if when you forward with unbound if either of those is being done.. I am not a fan of doh or dot, I have no actual use case for them.. I resolve.. Only reason I fired up unbond to be able to do doh and dot was as a learning experience.. I have a thread around here somewhere where went over how to let unbound serve up doh to your local network, etc. I don't actually use it.. but I set it up and it works.

Normally clients themselves would use doh, dot is more for NS to NS.. while you can click to get dot working with unbound internally, you need to add couple custom options to have it do doh.