Slow local DNS lookup

[Antibiotic]

Slow local dns lookup. Is it normal?

Dns resolver in forward mode to cloudflare.
This is my firewall rules and unbound settings.

pfSesne plus 24.11 beta

[johnpoz]

@Antibiotic well there is no freaking way you actually talked to 1.1.1.1 or 1.0.0.1 in 0 and 1ms.. Those have to be cached results.. Unless you were actually sitting in one of their DC ;)

Do a query to unbound from a client, what were you looking up btw? If you you look up something that is not in the cache it will take some ms, but after you have looked it up, then the query should be pretty instant, ie 0,1,2 ms sort of response.

$ dig @192.168.9.253 www.yahoo.com

; <<>> DiG 9.16.50 <<>> @192.168.9.253 www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51320
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.yahoo.com.          3600    IN      CNAME   me-ycpi-cf-www.g06.yahoodns.net.
me-ycpi-cf-www.g06.yahoodns.net. 3600 IN A      69.147.65.251
me-ycpi-cf-www.g06.yahoodns.net. 3600 IN A      69.147.65.252

;; Query time: 202 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Sun Nov 03 12:40:47 Central Standard Time 2024
;; MSG SIZE  rcvd: 119

from cache

$ dig @192.168.9.253 www.yahoo.com

; <<>> DiG 9.16.50 <<>> @192.168.9.253 www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22403
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.yahoo.com.          3597    IN      CNAME   me-ycpi-cf-www.g06.yahoodns.net.
me-ycpi-cf-www.g06.yahoodns.net. 3597 IN A      69.147.65.251
me-ycpi-cf-www.g06.yahoodns.net. 3597 IN A      69.147.65.252

;; Query time: 1 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Sun Nov 03 12:40:50 Central Standard Time 2024
;; MSG SIZE  rcvd: 119

[Antibiotic]

@johnpoz said in Slow local DNS lookup:

dig @192.168.9.253 www.yahoo.com

My response
; <<>> DiG 9.20.2 <<>> @192.168.20.1 www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50005
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;www.yahoo.com. IN A

;; ANSWER SECTION:
www.yahoo.com. 60 IN CNAME me-ycpi-cf-www.g06.yahoodns.net.
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.42.204
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.43.204
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.43.205
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.42.205

;; Query time: 604 msec
;; SERVER: 192.168.20.1#53(192.168.20.1) (UDP)
;; WHEN: Sun Nov 03 20:44:30 EET 2024
;; MSG SIZE rcvd: 151
; <<>> DiG 9.20.2 <<>> @192.168.20.1 www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;www.yahoo.com. IN A

;; ANSWER SECTION:
www.yahoo.com. 60 IN CNAME me-ycpi-cf-www.g06.yahoodns.net.
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.43.204
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.42.205
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.43.205
me-ycpi-cf-www.g06.yahoodns.net. 60 IN A 27.123.42.204

;; Query time: 639 msec
;; SERVER: 192.168.20.1#53(192.168.20.1) (UDP)
;; WHEN: Sun Nov 03 20:46:07 EET 2024
;; MSG SIZE rcvd: 151

[Antibiotic]

@johnpoz
Caching not working?

[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?

[Antibiotic]

@johnpoz One more question about other settings

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'