PTR requests not being generated for local clients #1975
Comments
|
What your are quoting isn't an error, it is just a message telling you that the respective client's name is not yet in the database. Please check the log at full hour to see the resolving attempts. Looking at you configuration, I do wonder who should reply to you PTRs upstream? You do not have |
|
Unbound handles my conditional forwarding. My router handles the PTR replies. I do not see Pihole sending out PTR requests other than a single ipv6 local address and it is of the pihole host device. I have Unbound configured to drop ipv6 PTR requests and prefer to rely on on The way i used to test this in v5 was to restart piholes dns server from the Settings page. Upon restart all initial PTR requests got sent out. This time around i only see a single PTR request mentioned above. Edit----- When i run |
|
Thanks for the additional details, it wasn't clear to me before that I'd recommend using on your Pi-hole to force a refreshing of host names now. Have a close look on the log files about what is happening. Especially
where
|
|
Example: should give you lines like: |
|
So i flushed logs network table restarted dns resolver. I then ran your command above and got the following FTL.log |
|
And there are no corresponding |
|
Corresponding PTR requests in Outside Container Inside Container |
|
Are the PTRs you found in would have been a better suggestion. |
|
FTL is forwarding PTR request fine. I can nslookup from outside and inside container and i am able to resolve manually. I have Unbound configured to only forward ipv4 PTR requests and to NXDOMAIN ipv6, as reflected in the log: |
|
As i understand things, upon a resolver restart FTL should send out PTR request for clients it has recorded in the database based on my settings. There must me a condition set somewhere that its leading to FTL not sending out the PTR request. That is my conclusion based on log results. |
|
Yes, it is hard to really tell from my side what is happening because we have seen only small excerpts from the log here, so far. What is not happening as expected is, e.g., what you have shown here. After the I'd have expected FTL to start to resolve all client host names which would look like this. At the very end, we see a line like Do you see such lines in the log file? |
|
FTL.log after reset of quarries and network table and restart of resolver. The upstream that its skipping is unbound's container. pihole.log Going to sleep now. |
|
This looks like expected, after your cleaning of queries, you start with an empty database:
Hence, no clients are known and no initial resolving is happening. As soon as the first query arrives, the corresponding client is resolved
which works as expected
This is a bug and fixed by 2843fb0. The requirement for this bug to be triggered is starting FTL on an empty database - it won't appear in "normal" cases. The following name resolving is working as expected:
Your log snippet above shows only five clients:
None of these are unexpected results and everything seems to work up until here? Plus the two upstream servers which should work fine as of the fix. Please run in about 5 minutes from me posting this comment to get a customized FTL variant we can work on for fixing what we find here. For one it makes |
|
Oh yes, sorry - I always forget about this docker specialty. @PromoFaux maybe either of us remembers to at least put the link to the README there before we release v6. But I think we should also re-enable this at least for |
|
Off the top of my head checkout commands effectively utilise the install script, none of which is actually utilised in the docker image. The build script in the docker repo should suffice, but perhaps we can add in a link to the instructions to the checkout command |
|
Rebuilt docker image, deleted all configs and let pihole rebuild from scratch. Made only following modifications: My FTL logs still look the same as previous. EDIT 1 --------------- Saw a new commit under fix/resolver, rebuilt image, now im seeing following in Also this error under diagnosis:
EDIT 2 --------------- Ok at top of the hour
It appears PTR requests are being forwarded to localhost and not upstream resolver. |
|
As a test, try to use the host IP in Do you see any change? |
|
Hardcoded upstream dns and added also tried setting pihole conditional forward to my unbound container's IP and port, still looks like PTR is forwarded to
|
|
Please post the full |
|
This exact command was working before and now its not. PTR is now being forwarded to 127.0.0.1 instead of upstream dns. If i bypass Pihole and go directly to my router which maintains my hostnames it works EDIT ------------- @DL6ER Appears hourly PTR requests are now being produced by Pihole, however PTR requests are now being forwarded to |
|
The hourly requests have always been sent to I've just seen your edits.
This is unfortunate, so it seems we indeed need to implement reconnecting. Or we need to find a way how to signal to try again later.
This is the problem and the real reason for
Everything looks like
doesn't work. Could you please check the |
|
Yes you are right. Had a typo in my compose file and the variable I saw your new commit and refreshed my image: I am sill receiving the following error in Piholes, but its not super frequent:
Something i've noticed and want to mention but may not be in scope of this issue. Let me know if i should make a new issue to track. I downloaded and opened
If this was done, then when filtering queries it would be easy to isolate a single device on the network with 'Client (by name)' and if futher filtering was need it could be done by other filters. |
|
Yeah, it's better to create a separate issue ticket to avoid confusion/mixing unrelated stuff and then forgetting about something in the end. Okay, so
Well, this may be an issue with |
|
Understood. Will make a new issue ticket. Would you recommend under pihole or FTL? Yah that typo on my end. In the beginning i was setting bogusPriv via the interface then half way through i switched to using environment variables in docker. You can see my typo in my post above. Just to make sure i rolled back to Changed back to I will dig into |
|
Sorry, I didn't see your comment. The improvements have been merged into |
Versions
Core
Version is 250a44c (Latest: null)
Branch is development-v6
Hash is 250a44c (Latest: N/A)
Web
Version is 59b1dcf (Latest: null)
Branch is development-v6
Hash is 59b1dcfc (Latest: N/A)
FTL
Version is vDev-825a14a (Latest: null)
Branch is development-v6
Hash is 825a14a (Latest: N/A)
Platform
Expected behavior
Pi-Hole should be issuing PTR request for clients to be forwarded upstream.
Actual behavior / bug
Pi-Hole is not issuing PTR requests. Enabled debug.resolver and following error is repeating for all my local clients, both ipv4 and ipv6:
Additional Info
The text was updated successfully, but these errors were encountered: