DNS settings in OpenWrt 19

[perot]

Networking does not work because of DNS configuration.

I've set up OpenWRT on a Raspberry Pi 4. There is no stable version yet, only a snapshot, I got r11675-16b01fb1b9. I run a separate machine serving DHCP and DNS, so I deactivated both services on the Pi, entering a static IP address to be used for the DNS. Networking does not work, as the IP address of the DNS server does not find it's way into resolv.conf.

Previously I was playing around with OpenWRT 18.06.4 (current stable), to get acquainted with it. The DNS/DHCP situation was the same, and I got DNS server addresses properly configured: The via LuCI entered DNS server IP address got written into resolv.conf, and everything was functioning there.

After writing the SD card for the Pi 4 I tried to install missing packages, but I had to manually enter the DNS server address into resolv.conf for opkg to work. So I installed packages, and used LuCI to restore a configuration backup that originated from the older (v18.06.4) installation. As far as I can see the configuration is indeed the same now, with the important difference that on bootup, 27.0.0.1 is the only DNS server address in resolv.conf.

Nosing around in the configuration files I found deviations in the file /etc/config/network, in the section "config interface 'lan'". On the older, functioning system I have the line

        option dns '192.168.2.12 192.168.2.13'

(that's correct, two servers, as customary for DNS), while on the Pi 4 this line is missing, but instead I find

        list dns '192.168.2.12'
        list dns '192.168.2.13'

Why does the new LuCI modify the archived /etc/config/network file during import? What exactly is the function of the "list" keyword, i.e. in what respect does it work differently from "option"?

Is this possibly a bug, in either LuCI or the snapshot?

Would it be wise to completely uninstall dnsmasq in my scenario? I did not find any help from the documentation regarding my scenario, as it seems inconceivable to the author(s) that somebody may want neither DNS nor DHCP on the router.

[trendy]

By default /etc/resolv.conf is symbolic link to /tmp/resolv.conf, which points to 127.0.0.1, in order to use dnsmasq. You can leave dnsmasq running and use the option dns, or list dns, they are the same. If you deactivate dnsmasq, delete the symbolic link and recreate the resolv.conf file with the options of your choice.

[perot]

Thanks for your reply, and the info on the workings of resolv.conf.

If I had only remembered that I had deactivated dnsmasq (and odhcpd as well) on that previous installation! I would have checked the startup services right away. Turns out LuCI fails to backup (and restore) the services startup configuration. After I deactivated those on the Pi 4 as well the DNS server address issue is gone!

Which file is the startup configuration saved in? Wouldn't it make sense to add it to backup configuration? Can you think of any other parts of the configuration that might not be backed up?

[mk24]

Running service <service> enable places a link in /etc/rc.d to the corresponding script in /etc/init.d. The link names start with a number which causes a sequential startup. Likewise running service disable removes the link.

If you were running dnsmasq locally on a LAN device such as your setup, it will not resolve LAN names unless you disable rebind protection.

[perot]

I know, I always switch off rebind protection.

I have seen the links, and suspected service may work this way. But if service does not keep the information in some file (as well), then the only way to back this up is to run a script just prior to the backup action that collects the startup link configuration, and another one that puts the links back in place for restoring. I do not know if the LuCI backup facility is equipped to do such a thing.