DNS request timed out., then works
-
I am seeing strange behavior where doing an
nslookup
will timeout sometimes once or twice, then work. Other times it times out completely.>nslookup router.nooblink.com Server: router.nooblink.com Address: 192.168.1.1 DNS request timed out. timeout was 2 seconds. Name: router.nooblink.com Address: 192.168.1.1
Notice how this is resolving the router, it times out once, then works.
Here is one for google:
>nslookup google.com Server: router.nooblink.com Address: 192.168.1.1 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. Non-authoritative answer: Name: google.com Addresses: 2607:f8b0:400a:80b::200e 142.250.217.110
Similar, but times out twice.
Here is one for DuckDuckGo:
>nslookup duckduckgo.com Server: router.nooblink.com Address: 192.168.1.1 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Request to router.nooblink.com timed-out
I have my DNS servers set for Quad9, CloudFlare, then Google:
- 127.0.0.1
- 9.9.9.9
- 1.1.1.1
- 1.0.0.1
- 8.8.8.8
- 8.8.4.4
Any idea why I might be seeing this strange behavior?
-
Check you LAN interface : your device (PC) can reach pfSense port 53 TCP and UDP ?
On pfSense : unbound is listening on LAN and running and not constantly restarting ? Check the system and revolver log to check this. -
@Gertjan whatever the main issue was, it seems to have resolved itself. It started working about 3.5 hours after it stopped. I wonder if something strange was happening with my ISP? I don't see unbound/resolver restarting a bunch in the logs. It looks like the resolver logs show DNS queries being replied to (log below).
However, now it seems like my DHCP static entries are not being registered with unbound. I can resolve my routers hostname, but not other static leases on my network.
2024-07-02 10:30:35.591912-06:00 unbound 62220 [62220:1] info: Verified that unsigned response is INSECURE 2024-07-02 10:30:35.591829-06:00 unbound 62220 [62220:1] info: NSEC3s for the referral proved no DS. 2024-07-02 10:30:35.591582-06:00 unbound 62220 [62220:1] info: query response was ANSWER 2024-07-02 10:30:35.591491-06:00 unbound 62220 [62220:1] info: reply from <kinesis.us-east-1.amazonaws.com.> 205.251.199.151#53 2024-07-02 10:30:35.591289-06:00 unbound 62220 [62220:1] info: response for kinesis.us-east-1.amazonaws.com. A IN 2024-07-02 10:30:35.574608-06:00 unbound 62220 [62220:1] info: resolving kinesis.us-east-1.amazonaws.com. A IN 2024-07-02 10:30:33.624001-06:00 unbound 62220 [62220:1] info: Verified that unsigned response is INSECURE 2024-07-02 10:30:33.623976-06:00 unbound 62220 [62220:1] info: NSEC3s for the referral proved no DS. 2024-07-02 10:30:33.623878-06:00 unbound 62220 [62220:1] info: Verified that unsigned response is INSECURE 2024-07-02 10:30:33.623852-06:00 unbound 62220 [62220:1] info: NSEC3s for the referral proved no DS. 2024-07-02 10:30:33.623664-06:00 unbound 62220 [62220:1] info: query response was ANSWER 2024-07-02 10:30:33.623639-06:00 unbound 62220 [62220:1] info: reply from <ring-iperf3-us-west-2.prod.ring.net.> 205.251.193.33#53 2024-07-02 10:30:33.623591-06:00 unbound 62220 [62220:1] info: response for iperf.ring.com. A IN 2024-07-02 10:30:33.578292-06:00 unbound 62220 [62220:1] info: query response was ANSWER 2024-07-02 10:30:33.578269-06:00 unbound 62220 [62220:1] info: reply from <ring-iperf3-us-west-2.prod.ring.net.> 205.251.193.33#53 2024-07-02 10:30:33.578230-06:00 unbound 62220 [62220:1] info: response for iperf.ring.com. A IN 2024-07-02 10:30:33.533265-06:00 unbound 62220 [62220:1] info: query response was ANSWER 2024-07-02 10:30:33.533240-06:00 unbound 62220 [62220:1] info: reply from <ring-iperf3-us-west-2.prod.ring.net.> 205.251.198.25#53 2024-07-02 10:30:33.533195-06:00 unbound 62220 [62220:1] info: response for iperf.ring.com. A IN 2024-07-02 10:30:33.517220-06:00 unbound 62220 [62220:1] info: resolving iperf.ring.com. A IN 2024-07-02 10:30:33.517173-06:00 unbound 62220 [62220:1] info: query response was CNAME 2024-07-02 10:30:33.517148-06:00 unbound 62220 [62220:1] info: reply from <ring.com.> 205.251.198.63#53 2024-07-02 10:30:33.517099-06:00 unbound 62220 [62220:1] info: response for iperf.ring.com. A IN 2024-07-02 10:30:33.499657-06:00 unbound 62220 [62220:1] info: resolving iperf.ring.com. A IN
-
@RyanM said in DNS request timed out., then works:
However, now it seems like my DHCP static entries are not being registered with unbound. I can resolve my routers hostname, but not other static leases on my network.
Do you use KEA or ISC DHCP ?
KEA, as explained in the other 1000+ posts and the announcement blog, doesn't support "DHCP static entries" amongst others.
Get back to ISC DHCP, and you'll be fine. -
@Gertjan Ouch, yeah I upgraded to Kea. I don't remember, maybe a month ago? It must have been rolling with some kind of cache in the meantime because the local hosts were working until I rebooted my router last night. I guess when I read that about static entries, I figured it applied to DHCP leases, not the static entries. That is unfortunate. So, could I "fix" this by replicating the "DHCP Static Mappings" to the "Host Overrides"? Or is that not a good idea?
-
@RyanM said in DNS request timed out., then works:
Or is that not a good idea?
Read the release notes again : Netgate Adds Kea DHCP to pfSense Plus Software Version 23.09.
You will fully understand what happened
-
@Gertjan I finally got around to reading the release notes. It doesn't provide a work-around for the lack of DNS registration of static DHCP leases. Is this capability on the roadmap?
Until then, is my suggestion of adding "Host Overrides" into my DNS Resolver config a good idea or a bad one?
-
@RyanM said in DNS request timed out., then works:
It doesn't provide a work-around for the lack of DNS registration of static DHCP leases. Is this capability on the roadmap?
Has been said here on the forum : this is the initial pre lease of KEA.
Its been worked on right now.
"The next pfSense version is always better".