OpenWrt Forum Archive

Topic: (rpizero) nslookup: can't resolve '(null)': Name does not resolve

The content of this topic has been archived on 30 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I recently built OpenWRT for raspberry pi zero, it has some glitches but probably because I built it from the trunk.

The bigger issue is that if resolv.conf points to 127.0.0.1, the local dns resolver doesn't work at all.
Googling around I found https://dev.openwrt.org/ticket/11495 but my issue seems a bit different

root@gateway:/tmp# cat /etc/resolv.conf 
search home
nameserver 127.0.0.1
root@gateway:/tmp# nslookup www.google.it
nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'www.google.it': Try again
root@gateway:/tmp# nslookup www.google.it 127.0.0.1
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 'www.google.it': Try again
root@gateway:/tmp# nslookup www.google.it localhost
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 'www.google.it': Try again

If I switch to use the router dns service it works correctly

root@gateway:/tmp# cat /etc/resolv.conf 
search home
nameserver 192.168.1.1
root@gateway:/tmp# nslookup www.google.it
nslookup: can't resolve '(null)': Name does not resolve

Name:      www.google.it
Address 1: 172.217.16.35 muc03s08-in-f3.1e100.net
Address 2: 2a00:1450:4016:803::2003 muc03s08-in-x03.1e100.net
root@gateway:/tmp# nslookup www.google.it 127.0.0.1
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      www.google.it
Address 1: 172.217.16.35 muc03s08-in-f35.1e100.net
Address 2: 2a00:1450:4016:803::2003 muc03s08-in-x03.1e100.net
root@gateway:/tmp# nslookup www.google.it localhost
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      www.google.it
Address 1: 172.217.16.35 muc03s08-in-f3.1e100.net
Address 2: 2a00:1450:4016:803::2003 muc03s08-in-x03.1e100.net

May be there is a sort of recursion between the local dns server and dnsmasq.

root@gateway:/tmp# cat /etc/config/dhcp 

config dnsmasq
    option boguspriv '1'
    option localise_queries '1'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'
    option local '/home/'
    option domain 'home'
    option nonwildcard '0'
    option rebind_protection '1'
    option rebind_localhost '1'
    option localservice '1'

config dhcp 'lan'
    option interface 'lan'
    option dhcpv6 'server'
    option ra 'server'
    option ra_management '1'
    option start '100'
    option limit '150'
    option leasetime '12h'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'

I tried with localservice = 0

root@gateway:/tmp# cat /etc/config/network 

config interface 'wan'
    option proto 'dhcp'
    option ifname 'eth0'
    option peerdns '0'
    option dns '8.8.8.8 8.8.4.4'

config interface 'lan'
    option proto 'static'
    option ifname 'eth1'
    option netmask '255.255.255.0'
    option ipaddr '10.255.255.254'

I already tried without the dns and peerdns options

Someone has any hint?

Beside this, both https and firewall rules management are unusable.

I would like to avoid to rebuild everything using eglibc (or glibc).

Thank you!

(Last edited by d.albano on 16 Aug 2016, 15:38)

To me it looks like there are two separate issues mixed here:
1) you are running to the side effects of the incompatibility between musl clib and the nslookup tool from busybox.
See https://dev.openwrt.org/ticket/20893 and https://dev.openwrt.org/ticket/18333
Busybox nslookup ignores the server argument with musl. Thus your local resolver gets always applied with nslookup, so all queries from the nslookup tool go to the local resolver. That hinders your debugging efforts.

2)
The core reason for the DNS problems and for "unusable https and firewall rule management" is probably something wrong with interface/network config, device detection & driver inclusion and/or dnsmasq config. Which Openwrt/LEDE version you have built? Has is the proper support for Zero or have you modified something?

You might edit your topic title to clearly indicate Raspberry Pi Zero in order to get more device-specific answers.

Ps. You might be better of with a LEDE build, as there have been quite a lot of changes since march for brcm2708 platform. See the difference after kernel 447 bump:
http://git.openwrt.org/?p=openwrt.git;a … c6;hb=HEAD
https://git.lede-project.org/?p=source. … c9;hb=HEAD

My build is very recent, I built the firmware one week ago (Bleeding Edge, r49395).

1) Neither ping or any other command line tool work

root@gateway:~# ping www.google.it
ping: unknown host www.google.it
root@gateway:~# traceroute www.google.it
traceroute: bad address 'www.google.it'
root@gateway:~# nc www.google.it -p 80
Error: Couldn't resolve host "www.google.it"

2) I built OpenWRT for raspberry pi zero directly from the trunk of OpenWRT. It works correctly but there are a few web pages of LuCI that are unusable.
I think that they work but are too slow and the page timeout, infact when I access them using ps I see a lot of commands running.

(Last edited by d.albano on 16 Aug 2016, 15:38)

The discussion might have continued from here.