DNS works for clients but not router (in ssh terminal mode) using YazDHCP and Unbound.

[CornfieldWin]

Must be doing something basic the wrong way on my AX-88U Pro, but not sure what. Does unbound have to be installed after YazDHCP? Going to do a factory reset in any case, but would like to get it right.

 

[ColinTaylor]

Please explain what it is that doesn't work from the router's SSH? What error messages are you getting?

 

[CornfieldWin]

Please explain what it is that doesn't work from the router's SSH? What error messages are you getting?

All attempts to ping in SSH terminal say "bad address", nothing is resolving. Windows CMD is happy as a clam to ping local DNS names which I assign using DHCP assignment after which I religiously reboot. I know I saw this somewhere else as a YazDHCP and unbound interaction but off hand I can't find it. Tried Domain and local directives in dns.conf.add but that hung DHCP assignments after just a few were done and I them removed the directives.

 

[bennor]

@CornfieldWin, post your DNS configuration on the router (both LAN and WAN). And post any DNS Director configuration(s) you may have on the router.

 

[ColinTaylor]

All attempts to ping in SSH terminal say "bad address", nothing is resolving. Windows CMD is happy as a clam to ping local DNS names which I assign using DHCP assignment after which I religiously reboot. I know I saw this somewhere else as a YazDHCP and unbound interaction but off hand I can't find it. Tried Domain and local directives in dns.conf.add but that hung DHCP assignments after just a few were done and I them removed the directives.

By default you won't be able to resolve local DHCP client names from a router SSH session. This is by design as the router itself directly queries the WAN DNS servers and not the router's local DNS sever. If you want to change this behaviour you need to change the "Wan: Use local caching DNS server..." option in Administration - Tweaks.

 

[CornfieldWin]

By default you won't be able to resolve local DHCP client names from a router SSH session. This is by design as the router itself directly queries the WAN DNS servers and not the router's local DNS sever. If you want to change this behaviour you need to change the "Wan: Use local caching DNS server..." option in Administration - Tweaks.

Cannot find the WAN option in Administration - Tweaks or in WAN DNS Settings in WAN where I could Forward local domain queries to upstream Server DNS knowing that unbound lives there and I use no others, but don't like that idea for potential future confusion and misconfiguration.

 

[ColinTaylor]

Cannot find the WAN option in Administration - Tweaks...

Yes, sorry you are correct. I forgot you were using the 3006 firmware. That option was removed.

rc: remove option to have the router use its own resolver for local r… · RMerl/asuswrt-merlin.ng@33c0796

…esolution This option was never officially supported (it was a tweak), and with DNS handling being more complex in 3006, it was safer to drop this option than attempting to ensure it worked with ...

github.com

 

[CornfieldWin]

@CornfieldWin, post your DNS configuration on the router (both LAN and WAN). And post any DNS Director configuration(s) you may have on the router.

I know I had this working a few months back but can't find my notes. Everything I search for says this should work. The issue is not forwarding local names to unbound but rather letting dnsmasq resolve local names first (unbound.conf has an option for bypassing dnsmasq but it is not being used) and only then pass on non-local names to the upstream recursive servers (which happens to be unbound in this case). Clients to go ax88upro (192.168.1.1) on Port 53 to dnsmasq (one instance per interface) which works correctly for local names and then forwards as necessary to unbound on port ax88upro:5353 as modified by unbound installation (server=127.0.01:5353 in dsnmasq.conf). But onboard router name resolution is not going through dnsmasq, although it does go to unbound on 5353. There cannot be two DNS servers on the same IP address so the firmware has to first force incoming DNS requests (on port 53) first to dnsmasq which handles redirection as needed. Why the firmware skips directly on the router (localhost) to Port 5353 seems strange but that might be a misunderstanding on my part. How does the firmware's builtin dnsmasq resolve its own dhcp assigned names without unbound in the picture? Put another way, how does ax88upro become a client of dnsmasq? What I found online looking around does not seem to work. I did see that ax88upro's address is automatically assigned (using LAN address) as is its hostname but that is different from being a client of dnsmasq for name resolution.

 

[ColinTaylor]

I know I had this working a few months back but can't find my notes. Everything I search for says this should work. The issue is not forwarding local names to unbound but rather letting dnsmasq resolve local names first and only then pass on non-local names to the upstream recursive servers (which happens to be unbound in this case). Clients to go ax88upro (192.168.1.1) on Port 53 to dnsmasq (one instance per interface) which works correctly for local names and then forwards as necessary to unbound on port ax88upro:5353 as modified by unbound installation (server=127.0.01:5353 in dsnmasq.conf). But onboard router name resolution is not going through dnsmasq, although it does go to unbound on 5353. Why the firmware skips directly to Port 5353 seems strange but that might be a misunderstanding on my part. How does the firmware's builtin dnsmasq resolve its own dhcp assigned names without unbound in the picture? Put another way, how does ax88upro become a client of dnsmasq? What I found online looking around does not seem to work. I did see that ax88upro's address is automatically assigned as is its hostname but that is different from being a client of dnsmasq for name resolution.

As I attempted to explain above, this is by design. Local name resolution uses the servers specified in /etc/resolv.conf (together with whatever's in the /etc\hosts file).

 

[CornfieldWin]

Better yet, just replace what is in /etc\resolv.conf with "nameserver 127.0.01" and then it works as intended on the router to pass first through dnsmasq and then on to unbound (or whatever upstream DNS resolver) that dnsmasq is configured to use.

Oddly, it is not even necessary to remove no-resolv from dnsmasq.conf suggesting that the firmware is doing this for the native router host despite the no-resolv directive but does honor the no-resolve directive for external client access via port 53 so that a DNS loop does not develop. It's kind of a strange two way split, but its works once configured.

Even fixed IP addresses (really bad network management) can be kept in dnsmasq.conf[.add], but dynamic IP and hostname is much better practice (exporting/importing DHCP_clients through the DHCP GUI with YazDHCP makes this easy). Also a quick device inventory with MAC addresses and network identification can be made with Network->Map-View List to export DHCP_clientlist. I don't know if this is documented and I just missed it but it would be good to have it one place that is easy to find. Anyone setting up a home lab with a Media server, Homeassistant, NAS/DAS, multiple IOT devices and maybe unraid, OMV, or opensense will want to know it. I have seen painful opsense threads where they try to figure it out using DNSMasq and unbound or other resolvers.

Last question, /etc\resolv.conf symbolically links to a temp file created by the firmware. How to make sure the lookback and nothing else persists between boots?

Update: Tried setting WAN router to local network which worked for local devices (the router too, thank heavens) but cut out unbound. So it is not quite the same as editing /etc/resolv.conf.

Found work around: Use hosts.postconf to force the loopback name server entry in /etc\resolv.conf. The firmware appears to several times to force its WAN dns entries into /etc\resolv.conf but it can be successfully overridden.

Why not offer 127.0.0.1 as acceptable WAN dns address in the GUI instead of rejecting it? It is actually the way to make DNS work as (reasonably) expected by most use cases which will want dnsmasq on the router as well as clients to resolve internal address. [Admittedly some put unbound on 53 and configure fall back to dnsmasq on some other port (like 5053) but that seems clumsy and potentially dangerous if an internal domain might resolve externally.]

 

[ColinTaylor]

Better yet, just replace what is in /etc\resolv.conf with "nameserver 127.0.01"...

That's exactly what that webUI option I mentioned earlier used to do. But as you can see from the GitHub I linked to it was removed for a reason.

 

[CornfieldWin]

OK. "it was safer to drop this option than attempting to ensure it worked with the different scenarios, now that dnsmasq can run multiple instances for separate SDN." Curious if this applies to YazDHCP addon which runs successfully with dnsmasq instances on every comms related Linux interface but with the no-resolv directive? Not sure why those multiple instances would get confused by a config file that they are directed to ignore. At the same time the GUI without YazDHCP will use the common /etc\resolv.conf apparently without confusion among the multiple SDN instances. Somehow loopback at 127.0.0.1 might get confused internally in the kernel?

 

[CornfieldWin]

Have not found a problem with this configuration. Will keep.