Change in local name resolution in rc3 from snapshot April 2023

SvenHz commented 1 year ago

Describe the bug

Hi, I am using OpenWRT on two Asus RT-AX53U that I am using as dumb APs. I was using OpenWrt SNAPSHOT r22479 from early April 2023 before.

I have upgraded one of the APs to OpenWrt 23.05.0-rc3, r23389.

All works fine (downlink Wifi 5GHz is 20% faster -- great!) with the exception of one thing: local (reverse) name lookup of hosts on the local LAN (10.0.0.0/24) does not work anymore (other lookups work fine). DNS server is another OpenWRT box (untouched) that is my router to the Internet (config supplied by DHCP). On the April snapshot it works fine. Configuration is identical.

I can see a difference in /tmp/resolv.conf:

April snapshot

# cat /tmp/resolv.conf
# Interface lan
nameserver 10.0.0.1
search home.lan

rc3

# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
nameserver ::1

Is this expected and how can I get the old behavior back?

# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix '*******::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'

config interface 'lan'
        option device 'br-lan'
        option proto 'dhcp'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'

# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'
        option filter_aaaa '0'
        option filter_a '0'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

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'
        option loglevel '4'`

OpenWrt version

r23389-5deed175a5

OpenWrt target/subtarget

ramips/mt7621

Device

ASUS RT-AX53U

Image kind

Official downloaded image

Steps to reproduce

On rc3:

# nslookup 10.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1:53

** server can't find 1.0.0.10.in-addr.arpa: NXDOMAIN

On April snapshot (correct behavior):

# nslookup 10.0.0.1
Server:         10.0.0.1
Address:        10.0.0.1:53

1.0.0.10.in-addr.arpa   name = castor.home.lan

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

[X] I am reporting an issue for OpenWrt, not an unsupported fork.

jow- commented 1 year ago

Is it possible that you simply did an /etc/init.d/dnsmasq stop; /etc/init.d/dnsmasq disable on your previous deployment? This would write the DHCP received DNS server directly into /etc/resolv.conf and it would also fall in line with your LAN interface configuration, which is set to DHCP client mode, so providing an own DHCP and DNS proxy server on OpenWrt would make little sense.

Disabled service state is not propagated across upgrades / config backup, so it is entirely possible that dnsmasq simply got reenabled after upgrade.

SvenHz commented 1 year ago

@jow- that is it! Thank you so much. This was the missing link. Stopping and disabling dnsmasq on the new r3 installation solves the issue and indeed it was disabled on the other AP running the earlier snapshot. Case closed!

openwrt / openwrt