Pi as DNS server - local names not resolving through DHCP


Recommended Posts

I really don't know that much about networking, but somehow I've managed to get this far and it works bar one bugbear. I'm not sure if it's a DDWRT issue, or I've set the network up wrong. Local DNS names don't seem to work when offered via the router DHCP.

 

So, I have a Raspberry Pi which acts as the DNS server for my home network. This is fixed at IP address 192.168.1.10. 

If I tell my devices to use that DNS server, everything works as expected and I can access my pi by using local dns name http://pi.sky/

 

However, I'd like to not have to change the device config, rather get that served from the router. I run DDWRT, and under Router IP settings I've changed the DNS to 192.168.1.10, and also in the DHCP Server settings I've changed it. See below:

Screenshot 2016-06-29 at 20.16.43.png

 

Now, DNS works fine across all devices, and they're genuinely using the Pi as their DNS server (can see the requests on the Pi itself). However, I can't access it anymore using the local name. I just get a "Name not resolved" error. I have to browse to it using the IP address instead. Is this some sort of DDWRT quirk, or am I missing something in the setup (likely something basic!)?


Please help me oh wise gurus!!!? 

Seems you are running DHCP on both the Pi and the router, only one should be handling DHCP, is that's the case turning it off on the router will get you access back to the Pi because there is a conflict going on at the moment 

What can you not access your dd-wrt by its name?  Did you create a record in your dns running on pi to point to the dd-wrt router?

 

What dns are you running on the pi?  On a side note, IMHO single label not a good idea.. .sky is your tld and seems your only using that.. how about home.sky so it would be pi.home.sky or something like that. 

So, to try and clarify a few things:

The Pi is running something called Pi-Hole. It's a DNS adblocker with a web-gui. It's accessible through it's IP address or via http://pi.hole/

If on my devices, I manually point DNS to the Pi IP, I can access the web-gui by that short address. 

 

The issue arises when I don't set them manually and let the router DHCP does it's job. I've pointed DDWRT to use the the Pi as the DNS server. Any devices on the network are definitely using the Pi as the DNS server this way as I can see the requests coming in. But that is when the short address stops working - I can only access it via the IP address.

 

I'm pretty much at my limit of knowledge with this sort of thing now. But I see it where I'm at the point this may be a good opportunity to understand things a bit better - I'm not just after a quick fix.

 

so get down to some basics...

ping - this command allows you to test basic communications between the device/computer you are on to a remote device.  If you get replies, this signifies two things...the computer you are on can query the network to translate a host name to an ip and it can communicate with the remote device

 

nslookup - this command allows you to query the dns server named in your ip properties for a name or address that you type in.

 

examples of both commands:

 

ping www.google.com

ping 172.217.2.196

 

nslookup www.google.com

nslookup 172.27.2.196

 

these two commands will give you some basic information that will allow you to further troubleshoot network issues.  So using these commands you want to make sure that "pi.hole" is resolving to the right ip addresses and that the dns query is quering the proper server when looking up "pi.hole"

so if you do a query to your pi for pi.hole do you get a response?

 

What are you using to test your dns with? Dig, nslookup, drill, host, just a ping?

 

I would suggest you grab dig very easy to use, then do a query to your pi for what your looking up.  What records have you setup for your local network in this dns, are you clients setup to self register?

 

So if I query my pfsense box which is running my dns, which is unbound in resolver mode and I ask it for its own name.. I get a response..

dnsquery.jpg

 

So from here you can see TON of info that would help you troubleshoot your issue.  So you can see what I asked for in the query section, you can see the answer I got back, you can see what server I asked, what the response time was in ms.  You can see the TTL on the record I looked up.  You see the status dns returned back, the flags on the settings for example that recursion was asked for, etc.

 

What are you clients actually pointing too for dns?  Simple enough to see with ipconfig /all

 

dnsviadhcp.jpg

 

So you can see what dns client is pointing too, you see it got IP from dhcp server, you see what search suffix it might be using which could throw off your dns query.

 

 

true dig is not native windows, but it takes all of 10 seconds to install and is so much better than nslookup ;)  Grab bind from isc, install just the tools.

 

https://www.isc.org/downloads/

 

 

installdig.jpg

This is the output (using another pi) when using router assigned DNS:

 

pi@raspberrypi:~ $ dig 192.168.1.10

; <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> 192.168.1.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63436
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
192.168.1.10.           0       IN      A       192.168.1.10

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 30 16:56:48 UTC 2016
;; MSG SIZE  rcvd: 57

pi@raspberrypi:~ $ dig pi.hole

; <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> pi.hole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20115
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi.hole.                       IN      A

;; Query time: 5 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 30 16:57:41 UTC 2016
;; MSG SIZE  rcvd: 36

 

Edited by Biohead

Same again, this time changing to use a static IP + DNS pointing directly at 192.168.1.10

 

pi@raspberrypi:~ $ dig 192.168.1.10

; <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> 192.168.1.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24012
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
192.168.1.10.           300     IN      A       192.168.1.10

;; Query time: 16 msec
;; SERVER: 192.168.1.10#53(192.168.1.10)
;; WHEN: Thu Jun 30 17:50:03 UTC 2016
;; MSG SIZE  rcvd: 57

pi@raspberrypi:~ $ dig pi.hole

; <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> pi.hole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26984
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi.hole.                       IN      A

;; ANSWER SECTION:
pi.hole.                300     IN      A       192.168.1.10

;; Query time: 5 msec
;; SERVER: 192.168.1.10#53(192.168.1.10)
;; WHEN: Thu Jun 30 17:51:15 UTC 2016
;; MSG SIZE  rcvd: 52

 

you notice when you don't get an answer for pi.hole your asking your router at 192.168.1.1, not .10

 

So no why would it have a record?

 

To be honest there really shouldn't even be A records for IP addresses so not sure why your getting such an answer..  If you want do a query for an IP you need to do a PTR, with dig you can do that with -x option

 

see

 


Budman@I5-WIN C:\Users\budman                                            
> dig -x 192.168.9.100                                                   
                                                                         
; <<>> DiG 9.10.4-P1 <<>> -x 192.168.9.100                               
;; global options: +cmd                                                  
;; Got answer:                                                           
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10652                
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  
                                                                         
;; OPT PSEUDOSECTION:                                                    
; EDNS: version: 0, flags:; udp: 4096                                    
;; QUESTION SECTION:                                                     
;100.9.168.192.in-addr.arpa.    IN      PTR                              
                                                                         
;; ANSWER SECTION:                                                       
100.9.168.192.in-addr.arpa. 3600 IN     PTR     i5-win.local.lan.        
                                                                         
;; Query time: 0 msec                                                    
;; SERVER: 192.168.9.253#53(192.168.9.253)                               
;; WHEN: Fri Jul 01 07:46:09 Central Daylight Time 2016                  
;; MSG SIZE  rcvd: 85                                                   

 

In your first query that devices is not asking your pi, its asking your dd-wrt.. Maybe it did not update its lease, maybe it has dns set static.. What is the output of its ipconfig /all

 

I noticed that... it's as though even though the router is told is use the Pi as the DNS server for the local network it's not directly telling connected devices - rather acting as a middleman. Which is what lead me to think it's possibly a router issue - is this something worth asking over on the ddwrt board?

I don't think it being a Pi comes into play at all. It just so happens this software was built in mind for a pi - it can run on most linux distros.

 

It's the fact devices are showing the router as the DNS server, despite me telling the router to use the Pi address. I can see the live dns requests coming in on the pi from the devices, so clearly it's doing it's job - just the router isn't. When I take the router out of the equation (i.e. use static IP + manually set DNS) everything works as expected.

dude post up your ipconfig /all from this device.. It clearly is not asking your pi so clearly its set to ask your router.  Did it update your lease since you set your dhcp server to point to the pi?

Sorry, I thought I'd replied this morning. I'm away now so can't post the output. 

However I did manage to resolve the problem - in ddwrt theres an option in the dhcp setup "Use DNSMasq for DNS". 

It's enabled by default, but if you're using an alternative DNS it has to be disabled to point clients directly to the other DNS server - otherwise the router is still a DNS server, just sending it's requests to the other one. 

When I did an ipconfig before, the DNS server was listed as 192.168.1.1, now it's listing as 192.168.1.10 as I hoped for.

 

Thanks for the help guys, never knew of the dig tool before and it looks quite useful. 

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • The reviews you refer to mean nothing. Where there is no journalism there is no reason to call the gaming media's opinion pieces "reviews". For GP games there is indeed a metric for success - increasing subscriptions. Which turns in revenue. The only circumstance in which subs do not rise when great is being released is a Game Pass system where the company is close to fully saturated with customers in a subscription. However, in that case as the theory goes you spend aplenty in all kind of games - from shady live service cash cows and customer offending agitprop crap in purple colours to robust and entertaining single player games. And keep a solid level of profitability. Ignoring the simply innocuous but mid games MGS has released primarily of the second kind.
    • Report: Microsoft to use AWS to help GitHub deal with a major surge in demand by Pradeep Viswanathan Thanks to the surge of coding AI agents, GitHub's usage has skyrocketed over the past 12 months. To meet this demand, GitHub started with a plan in October 2025 to increase capacity by 10x. However, by early this year, the company realized that it needed 30x scale. This rapid growth has caused severe strain on the platform's reliability, resulting in several small outages over the past few months. In April, GitHub published a long blog post explaining the steps it is taking to resolve these reliability issues. In the post, the company also confirmed that it is working toward a multi-cloud architecture for better resilience. Today, Business Insider reported that GitHub is turning to Amazon Web Services to help deal with a major surge in AI-driven coding activity. It is important to note that GitHub is still in the process of moving completely to the Azure cloud. The current plan is to move the platform fully to Azure by 2027 so that it can scale better as per developer demand. Therefore, the current decision to utilize AWS might be part of a short-term plan to meet immediate demand. A Microsoft spokesperson confirmed that GitHub is using multiple cloud providers with the following statement: For Microsoft, the decision highlights the operational pressure behind the AI boom. GitHub has to stay reliable for developers at a time when rivals such as Codex, Cursor, Claude Code, and other AI coding tools are gaining attention. And the decision to use AWS for computing capacity seems practical given the circumstances.
    • It's growing on me, however, your right, it make better usability sense if the tabs were bellow the address bar.
    • Qwen 3.6 is better value per dollar, and you can run it locally for free.
    • I don't believe them that anyone using threads, at least meaningfully. It's the same thing for Facebook, people just don't engage with Meta platforms like they are thinking. This isn't 2006.
  • Recent Achievements

    • Reacting Well
      Dys Topia earned a badge
      Reacting Well
    • Conversation Starter
      NovaEdgeX earned a badge
      Conversation Starter
    • One Year In
      Console General earned a badge
      One Year In
    • Week One Done
      Twozo Technologies earned a badge
      Week One Done
    • One Month Later
      Twozo Technologies earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      517
    2. 2
      +Edouard
      182
    3. 3
      PsYcHoKiLLa
      106
    4. 4
      Steven P.
      88
    5. 5
      ATLien_0
      68
  • Tell a friend

    Love Neowin? Tell a friend!