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

    • MVS subscribers got the proper 26200.8655 Win11 25H2 ISO downloads as of 6/16/2026 avoiding this whole MCT fiasco by MS. I'll obtain the official 8655 MVS ISO download instead.
    • too bad the "backend" June 2026 ESD files are still at build 26200.8653 and not at the correct build 26200.8655 release. I'll avoid using the MCT for several weeks until late July 2026
    • Qualcomm's new Snapdragon Reality Elite chip brings on-device AI to Android XR devices by Pradeep Viswanathan Qualcomm has been delivering dedicated SoCs for mixed reality and spatial computing devices for several years. The journey started with the Snapdragon XR1, followed by the Snapdragon XR2 in 2019, the Snapdragon XR2 Gen 2 in September 2023, and finally the Snapdragon XR2+ Gen 2 in 2024. Today, Qualcomm announced a major upgrade with the new Snapdragon Reality Elite Platform, which targets premium mixed reality and spatial computing devices. OEMs can use this SoC to power both all-in-one video-see-through headsets and lightweight, tethered optical-see-through glasses. Qualcomm highlighted that the Snapdragon Reality Elite will power the next wave of Android XR devices coming later this year. These wearables will offer better visuals, improved power efficiency, and deeper on-device AI integration compared to the previous generation. The Snapdragon Reality Elite can deliver up to 48 TOPS of AI performance, allowing large language models and large vision models to run directly on the device for the first time. In addition to enabling new spatial AI experiences, these new AI capabilities will improve head and hand tracking, as well as see-through features. On the performance side, the Snapdragon Reality Elite offers up to 60% higher GPU performance, up to 30% higher CPU performance, and up to 160% higher NPU performance compared to the previous generation. The platform supports visuals of up to 4.4K per eye at 90 frames per second for sharper images and smoother motion. Qualcomm is also claiming significant efficiency improvements. The Snapdragon Reality Elite can offer up to 20% longer battery life under the same workload. More importantly, the chipset can run up to 12 degrees Celsius cooler under load, making headsets more comfortable for users to wear for longer periods. The platform also includes improvements to video see-through, featuring lower latency and better image quality. Qualcomm states that its EVA hardware block helps accelerate demanding computer vision workloads, improving how digital content blends with the real world.
    • Umm... GitHub continues to use AWS. That's the story, that's the headline. There's no "new" news here. GitHub continues to require additional capacity beyond the originally-planned Azure allocations. There's nothing special about this; nothing noteworthy. They're still using AWS' infra until the cutover is complete.
    • Hello, Also known for https://www.theguardian.com/technology/2009/jan/29/adware-internet.   Regards, Aryeh Goretsky    
  • Recent Achievements

    • Collaborator
      vjlex earned a badge
      Collaborator
    • 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
  • 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!