Slow local DNS lookup
-
@johnpoz One more question about other settings
Could be useful to set some time here, because me all time using OpenVPN UDP for browsing?
-
@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.
-
@johnpoz Thank you so much!
-
@Antibiotic nothing very technical but is there a reason you use
cloudflare-dns.comas hostnames for1.1.1.1and1.0.0.1instead ofone.one.one.onethat Cloudflare mentions (and that resolve to the1.1.1.1and1.0.0.1)? -
@patient0 No any reason
-
@Antibiotic Ok, I'm a bit suprised it does work since
cloudflare-dns.comdoes resolve to totally different IPs.dig +short cloudflare-dns.com 104.16.248.249 104.16.249.249But nevermind, perfect if it works.
-
@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:853Here 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 NAMESERVERNow 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.
-
@johnpoz So cloudflare-dns.com is correct for DOT or should make one.one.one.one ? Now I'm in doubt)))
-
@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 msuser@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:~$ -
@johnpoz Thanks'
-
@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.
