Slow local DNS lookup

johnpoz

@Antibiotic look at the ttl, its only 60 seconds.. your 2nd query was 2 minutes later.. Or 1 min 37 seconds, clearly something longer than the 60 second cache.

WHEN: Sun Nov 03 20:44:30 EET 2024
WHEN: Sun Nov 03 20:46:07 EET 2024

I hate those stupid idiotically short ttls - 60 seconds is utterly pointless for any sort of cache, so I set my min ttl to 1 hour, 3600 seconds.

But do your test faster than the ttl, and your 2nd response should be from cache.

Antibiotic

@johnpoz said in Slow local DNS lookup:

so I set my min ttl to 1 hour, 3600 seconds.

Could you please show, where is I can change this settings?

johnpoz

@Antibiotic in the resolved advanced section

I have been running this for years and years and never had any issues.. But keep in mind that you are really going against common practice and that is to accept what the owner sends for ttl.. but 60 seconds is insanely low.. And since your forwarding, its almost always going to be something lower because your pulling from where you forwarded cache..

the only place I could see having a problem is some ddns your trying to resolve where the IP has changed right after you looked it up, etc. you would have the old IP cached for 1 hour.. But I have yet to run into anything where the 1 hour ttl has caused a problem

Antibiotic

@johnpoz Thank you buddy)))

johnpoz

@Antibiotic I also set serve 0, so even if the cache has expired you will get the last IP and then it will look it up again.. So your client will get an IP instantly, but if for some reason that fails, when the client does a refresh he will have a freashly looked up record.

Antibiotic

@johnpoz Do you mean, these settings to make ON?

Screenshot_3-11-2024_21324_192.168.20.1.jpeg

Antibiotic

@johnpoz One more question about other settings

Screenshot_3-11-2024_21652_192.168.20.1.jpeg

Could be useful to set some time here, because me all time using OpenVPN UDP for browsing?

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.