Can't find ip to name with local upstream

General
1

I just installed and got up and running in an Ubuntu LXC Container. It’s was very ez to setup and I am liking it a lot for my home. I noticed one minor issue with Core v6.1.4 that I see. When I do nslookup on ip to name I get the following:

nslookup 192.168.2.5
Server: pi.hole
Address: 192.168.2.224

*** pi.hole can't find 192.168.2.5: Non-existent domain

However if I use the upstream all is good. I verified the upstreams are correct. (I did remove the domain name in the output,)

nslookup 192.168.2.5 192.168.2.111
Server: Vega
Address: 192.168.2.111

Name: Cygnusx1
Address: 192.168.2.5

I provide all clients with 3 DNS Addresses, pihole is the first with my locals as 2nd and 3rd. It doesn’t appear to be a big thing but I can’t get my head around this at the moment. I can query name just fine, if I nslookup google.com, pihole gives me the names back. I am only using pihole as a blocker, no dhcp or dns from it.

2

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

3

Actually I figured this out, under DNS Settings, switch to expert and there was a box that was checked that blocked resolution of ip to name of private networks. Once unchecked and pihole rebooted, things now resolve correctly.

4

I'd be surprised if that actually would have fixed your issue.

Never forward reverse lookups for private IP ranges won't control where Pi-hole sends reverse lookups.
If that where wouldn't configured correctly, you may just be observing a coincidentally successful resolution through one of your other local DNS servers your clients are using:

This would allow clients to by-pass Pi-hole at their own discretion, using one of your other locals.

This needs to be fixed if you want Pi-hole to filter DNS requests:
Pi-hole has to be the sole DNS server for your clients.

5

This is a home lab, and we are only talking about ad blocking, if pihole goes down, everything keeps working! Pihole is not critical enough to stop everything else from working in my home. The one you are failing to see is that reverse lookups were not working before and unchecking/disabling the setting fixed the issue. It was my specific issue, not everything requires you to upload a log. I will take the win an move on, thank you very much.

6

Without a debug log, I can't know whether your configuration could be working as you intend it to.

But your clients being able to talk to one of 3 different DNS servers could contribute to your observation of failing reverse lookups.
Your description suggests a current DNS resolution chain like:

client -+--> Pi-hole -----> unknown (no debug log)
        |or               
        +--> local DNS#1 --> presumably pubic DNS?
        |or               
        +--> local DNS#2 --> presumably pubic DNS?

If each of those 3 DNS servers would hold only a portion of your local name definitions, any local request going to one of the ignorant other two would fail.

And as mentioned, you'd additionally allow clients to by-pass Pi-hole at their own discretion.

If you already run a separate DNS server holding local name information, you'd commonly enable Pi-hole's Conditional Forwarding to have Pi-hole retrieve local name information (including reverse lookups) from that DNS server, while exclusively propagating Pi-hole as local DNS.

A resulting DNS resolution chain would look like:

client -> Pi-hole -+--(via upstream DNS servers)----> public DNS
                   |
                   +--(via Conditional Forwarding)--> local DNS

As clients talk to Pi-hole directly, this would also allow you to take advantage of Pi-hole's client specific filtering.

Alternatively, you may propagate your two existing local DNS servers in your network, and configure them to use Pi-hole for public DNS requests:

client -+--> local DNS#1 -+
        |                 |
        |or               +--> Pi-hole --> public DNS
        |                 |
        +--> local DNS#2 -+

Either way would ensure that clients wouldn't by-pass Pi-hole via your other two DNS servers while allowing local name resolution, but note that you wouldn't be able to attribute DNS requests to individual clients with the latter configuration, so no client specific filtering.

As mentioned, Never forward reverse lookups for private IP ranges won't control where Pi-hole sends reverse lookups.

It may have properly addressed your issue only if you'd configured your local DNS servers as Pi-hole's Upstream DNS Servers exclusively, and it wouldn't be required if you'd enabled Conditonal Forwarding to your local DNS servers.

Sharing a debug log would probably have spared me from lengthy explanations, as it may have allowed me to provide more specific advice, as well as checking your IPv6 DNS configuration, but that's your choice, of course.

In any case, the most important advice from my initial reply is that allowing your clients to pick out of three DNS servers will have them by-pass Pi-hole's filtering at their own discretion on occasions.

1 Like
7

Sir:

I appreciate the help, but things are working as intended. I do forward out to public dns from my internals, basically you have a forward to a forward or Pihole to local to internet. In the end isn’t that how everything works? So lets stop with the Corp talk and remember this is not a Production Environment only a home lab. This is one of the config options offered by Pihole. If you read the docs, they speak of this configuration.

Most of these will be from devices, lights and stuff. I don’t browse the internet from a light bulb or my sonos devices. I use sonos so it is whitelisted with my other devices from apple, android, roku, and chromecast.

What you are suggesting is a point of failure for your whole network if pihole goes down. I don’t see blocking ads as worthy of this, all things should remain up. This is not a firewall or IPS device. The only way I would do what you are suggesting is by having 2 piholes for redundancy as I do with DNS, DHCP and so on, if it was critical.

As mentioned, Never forward reverse lookups for private IP ranges won't control where Pi-hole sends reverse lookups*.* When you tell me this, I can tell you Pihole forwards to upstream DNS, which is my local and handles my private addresses, I get resolution as intended. My locals forward out to the internet if that is needed for resolution.

9

If by “things are working as intended,” you mean that you intend to never be sure which server your clients are using for DNS, then you’re right.

You will find hundreds of threads here where users are confused as to why sometimes Pihole blocks and sometimes it doesn’t. It almost always comes down to having multiple DNS servers available to the clients; while many intend to set it up so if Pihole fails, another (public) DNS server is used instead, invariably the “secondary” public DNS is almost always used.

Pihole doesn’t fail as a matter of course. If it’s not working, there’s typically a fundamental networking issue going on. It’s not “Corp talk,” it’s experience. I’ve had Pihole running on a Raspberry Pi 3b for more years than I can remember, and the only time it has any issues is when the whole Internet is down for my location.

You are, of course, free to configure things as you please, but you should understand that ramifications of those choices and the likely outcomes.

To be clear, when you specify multiple DNS addresses for your clients, they will typically pick the one that responds fastest…and that is often a public DNS. Then they stick with it until there’s a good reason to switch. Even if you specify Pihole “first,” because the secondary server isn’t really “the 2nd choice,” it’s just an additional choice.

All that is to say that yes, you can set it up this way, but the documented behavior is that this type of setup typically ends up using a non-Pihole server for DNS. That contradicts the point of bothering to set it up in the first place.

Your home lab is your own business and you probably have a very good idea of what it’s doing, how and why. So no disputing of that from me. And forgive me if I unnecessarily run to the defense of the devs who almost certainly do not need my help, but the condescension I read into the text above encouraged me to don my knight’s garb.

All of the above is my opinion, not “Corp talk” (which is kind of hilarious given the nature of Pihole), and Just The Thoughts Of A User.

2 Likes
10

Honestly I could careless if a wifi light bulb uses pihole or not. It's not an IPS system, you take advantage blocking way to serious.

11

Hello @cygnusx1,

Your opening request for support indicates that you have an often-seen misconfiguration and misunderstanding which might explain what you are seeing, but you did not follow the help template and did not provide a debug log token.

The debug log allows devs and support to quickly assess a summary of your Pi-hole environment and not waste time on irrelevant testing and back and forth questions. In the absence of those we can only suggest likely scenarios. These are as much for the benefit of future visitors, searching for an answer, as they are for you.

You received a comprehensive reply from Bucking_Horn which explained why your observation is possibly a coincidence, as well as some good advice on how NOT to configure your Pi-hole, along with some pros and cons of different, commonly-used local DNS architectures.

As nprampage pointed out, if you're going to set up Pi-hole, no-one cares whether you're using a laptop or a lightbulb – that's your business – the architecture information provided here is still valid and correct, very well presented and is for everyone's benefit. It is not "Corp talk" and that kind of attitude isn't going to work in this forum, which is a friendly place for all Pi-hole users and enthusiasts.

You should take that information, say "thankyou", and see if you can use it to improve your local network architecture and fix any misconceptions you find that you have.

Search the forum for other ideas. Do some reading. Complete the discobot forum induction in your private messages after signing up.

Pay attention to help templates. If you need further support, follow them, and please provide a debug token URL.

2 Likes
12

I appreciate the help you have tried to render. I work in this space for a living. The only misconfiguration I noticed was the check box I unchecked, to make things work. All I have heard from those responding is, I have it setup wrong. If this was a friendly place then when I said I have it fixed and working as I intended, that should have been the end of it. Now you want to join in and add your 2 cents that it is wrong. Look at the docs for Pihole and you will see it is a config option they talk about. There again, it is only wrong in your mind.

15

You should go back and read the text of the setting, I didn’t find you helpful at all. When I said I found the fix you wanted to argue that it was just a coincidence. When you read the text of the setting and my issue you realize right away this is the issue. I hope you don’t treat others this way…

17

Why do you seem so eager to read my advice with that much hostility?

My last line in this topic until now has been:

Your original reply to that was:

I didn't argue any further since you stated that you intend your Pi-hole to be bypassed, and all of the sudden now it's:

And what's more, you also tried to devalue Pi-hole developers' as well as my own advice on another thread, insinuating that developers have jumped on you - when in fact no developer was involved with you in this topic.

Why is there so much ill-will and hostility in your replies to posts that genuinely try to help you?

18

I think it is important to provide feedback, in this type of engagement. It identifies areas of improvement. Looking at the totality of the engagement, you apparently don’t get much of it. If I had to select a product based on a support engagement, I would have went with AdGuard or a Competitor. I know in Health Care if Vendor did what you did and was so dismissive, they would have lost the contract! Your only response was it was a coincidence. Now I would ask you to reread my original post review the text of the settings and then tell me you think it is a coincidence. I had 3 or 4 of you jumping on me because I dared to disagree. The emails come from Pihole Community, so you all represent. Whether the emails are from

19

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.