@Pugs, if you propagate 127.0.0.1 as the name server to clients, they will try to resolve domain names by connecting to  their localhost interface. This can't work. If there is a valid fall-back, this explains the delay in name server lookups.

I'm still not sure about your network setup. If you set a Mgmt VLAN (as discussed in another thread), EAPs will process tagged frames, not untagged frames. And IP 10.10.1.4 can't be assigned from a 10.20.1.1 DHCP range.

VLAN 1 untagged is not a VLAN, but VLAN 1 is the VLAN to be used for untagged frames, that's a big difference. In fact, inside a VLAN network there are no untagged frames.

I would not mix untagged frames and tagged frames on a switch or router port.

@Pugs,

I recommend to use standard ISC DHCP/DNS server on the ER-X, which is the default DHCP/DNS server. dnsmasq has no advantage over the ISC DHCP/DNS server. The following settings are related to the ISC DHCP/DNS server.

In dhcp-server config section, enter the IP address of the ER-X as dns-server. This is the IP the DHCP server propagates to clients.

In dns config section set up a caching server (cache-size 1500), forwarder is your pi-hole (name-server 10.10.1.253).

The latter setting is not to be confused with the router's name server setting (name-server 127.0.0.1) in the system config section!

Have the caching DNS server listen on both VLANs 1 and 30, that's either on interfaces eth0.1 and eth0.30 or on VIFs switch0.1 and switch0.30 depending on your setup.

Change the trunk from ER-X to the switch to tagged for both VLANs (do not set a PVID on the ER-X for the port, just VLAN memberships).

Now, set up two access ports on the switch, one for each VLAN. Connect a laptop to those ports, check IPs, DNS and default gateway set by DHCP in each VLAN.

If everything works, assign another switch port untagged membership of VLAN1, PVID=1 and tagged membership of VLAN 30. Connect the EAP to this port. Note that VLAN 1 ends here, while VLAN 30 will end at the EAP's SSID mapped to VLAN 30.

Mgmt VLAN in Omada controller should be left unset (you use untagged frames to control the EAP), while the VLAN 30 will use tagged frames. Assign one SSID to VLAN 30, the other to no VLAN (there is no VLAN 1 anymore, it was terminated at the switch).

Keep in mind that old EAP firmware versions for EAP-Wall or EAP115 models might still have the bug that untagged frames will be accidently leaked to a VLAN-mapped SSID. AFAIK, this bug was fixed in EAP245, EAP225 and EAP225-Outdoor. This is the reason why I always use a tagged Mgmt VLAN, but managing EAPs with untagged frames is much easier when it comes to adoption of new EAPs, so first try managing the EAPs with an untagged link. You can switch to a tagged Mgmt VLAN 1 anytime later should it become necessary.

Hope this helps!

@Pugs, Omada Controller does not interfere with DNS or DHCP. It even doesn't see this traffic.

Rule of thumb is to get the VLANs working up to the switch before mapping SSIDs to VLANs. To do so, assign two access ports on the switch to the VLANs and check with a laptop whether you get the correct IP, DNS server's IP and default gateway IP. If this works, assign a switch trunk port to those VLANs and connect the EAP to the trunk.

Don't even check for Internet unless you have full network connectivity to the EdgeRouter. Use ping to find out whether you can reach the ER using a laptop on the switch.

@Pugs, it doesn't matter whether you have 2, 20 or 200 VLANs, the principle is always the same: every VLAN can be seen as a separate network. Every network needs a gateway/router, DNS and probably DHCP. Every network can use routing into all other networks or firewalling against all other networks.

The only reason why you would use a forwarding DNS server on a router is to have a shared DNS forwarder appearing in different networks querying a single DNS server in another separate network. If you would route traffic to/from the Pi-Hole, you would not need a forwarder, but could propagate the IP of the Pi-Hole as the DNS server to be used directly to clients.

Anyway, you need to set up each VLAN the same way as you would do with separate physical networks with separate physical routers, switches and APs each (including the tests). Only difference with VLANs is that you save different devices to accomplish different networks.

If something VLAN-related once did work with EAPs and after several firmware upgrades later fails, it could be the VLAN leakage bug fixed some time ago in some models, where untagged frames had been leaked to VLAN-mapped SSIDs. This leakage could have been avoided (and on unfixed models still can be avoided) by not using untagged frames at all and set a Mgmt VLAN for the EAP.

However, it's important to understand that the EAP itself (its CPU so to say) and every VLAN-mapped SSID are virtual separate devices in different networks (VLANs):
 

• The EAP needs to have an IP in order to be manageable (controller/web UI), thus it is in the base network or however you call it. It does not necessarily need DNS nor a default gateway (both are optional and only needed if the EAP itself needs access to other networks for whatever reason, e.g. to access foreign NTP servers).
   
• Every VLAN-mapped SSID is in another network. Clients in those different networks always need an IP, a DNS server and a default gateway if they should be able to access the Internet. Either set those IPs by DHCP or by statically assigning them – then you don't even need a DHCP server, which is very handy for tests.
   
• The DHCP and DNS servers do not need to run on the router. For example, in my networks the DHCP server runs on the switch using different pools and DHCP relaying into the VLANs while the DNS server runs on a dedicated server in a separate network and routing is used to communicate with all clients in all other networks.