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!!!? 

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

The Pi isn't a DHCP server, it's just a DNS server. 

I did think about doing it that way, but if it fails for whatever reason then it makes things that bit more difficult which is why I haven't gone that way.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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"

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

nslookup if you have windows computers

dig if you have *nix

 

dig will not work on windows computers natively (not part of the native os commands). 

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

So if you are viewing your ip properties and it showing the router as your dns, then I would agree it is an issue of the router firmware.  

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

    • No registered users viewing this page.