Best practice for single DNS server serving multiple VLANs?

I have set up an AdGuard Home instance and for now have configured it to listen on multiple VLANs. I'm wondering what's best practice here. I have three separate networks at this point - the main LAN, a VLAN for the smart TV and a guest network. AdGuard Home is serving DNS for the last two already, but I've bound it to an IP in that specific subnet every time. Is there a more efficient way of making the DNS server manage multiple networks? I've seen people just put the DNS server in a separate network, but wondering what the added value is when you have a limited amount of separate networks.

Thanks!

You could leave dnsmasq as nameserver for all the vlans and forward all queries to adguard. But that will reduce visibility on adguard about the initiator of the query.
Otherwise you can advertise from dhcp the IP of the adguard for each vlan.
I don't think there is any other option or best practice.

1 Like

Thanks! I still have Unbound running on the router, and any DNS requests the firewall catches outgoing are redirected to the AdGuard instance. Odhcpd advertises the AdGuard IP as DNS server as well.

True, I'm seeing a few requests seemingly from the router already. But those would have only gone out to the WAN otherwise, no?

I have the firewall settings below for the VLAN in question, this should be intercepting DNS requests that ignore the DHCP set DNS server (10.0.30.7). The rule is probably redundant now that the firewall is intercepting and redirecting DNS requests.

config zone
	option name 'dnsfilter'
	list network 'dnsfilter'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option log '0'

config forwarding
	option src 'dnsfilter'
	option dest 'wan'

config rule
	option src 'dnsfilter'
	list src_ip '!10.0.30.7'
	option dest 'wan'
	option dest_port '53'
	option target 'DROP'
	option name 'Dnsfilter DNS'

config redirect
	option name 'Dnsfilter DNS redirect'
	option target 'DNAT'
	option src 'dnsfilter'
	option src_dport '53'
	option dest 'dnsfilter'
	option src_ip '!10.0.30.7'
	option dest_ip '10.0.30.7'
	list proto 'tcp'
	list proto 'udp'

config nat 'dnsfilter'
	option name 'Dnsfilter masquerade DNS'
	option src 'dnsfilter'
	option dest_ip '10.0.30.7'
	option dest_port '53'
	list proto 'tcp'
	list proto 'udp'
	option target 'MASQUERADE'

Yes, unless they are legitimately from the router itself.

Yeah.

1 Like

Would this be an appropriate solution to allow Unbound on the router to still perform DNS requests then? The nature of the filtered requests suggests they were from Android TV, but I still want Unbound to be able to perform its duty indeed.

Does fw4 give precedence to rules that are specified first? The redirect and NAT rule are still in place, after this one.

config rule                                   
        option src 'dnsfilter'                
        list src_ip '!10.0.30.1'                
        list src_ip '!10.0.30.7'              
        option dest 'wan'                           
        option dest_port '53'                 
        option target 'DROP'                  
        option name 'Dnsfilter DNS'

You may want to add the source zone as well. You are trying to block the forwarded packets and not the locally generated, right?

Yes. But DNAT is applied before filter rules and SNAT after the filter rules.

Yes indeed. The source zone is called dnsfilter here, which is already part of the rule - unless you're talking about something else?

No, you're right. I misread the rule. You're all good.

1 Like

I've set the logging option on the redirect and masquerade rules and it seems the smart TV is still talking to the 'old' DNS server on 10.0.30.1 despite it not being advertised anymore. DHCP sends along 10.0.30.7 as the DNS server IP. Setting it all up manually (with 10.0.30.7 as the sole designated DNS server) still makes the TV send the DNS request to the router somehow. The redirect is doing its job, so that's good, but I'm wondering what's happening here and why Android TV is still 'remembering' 10.0.30.1 somehow while 10.0.30.7 has been set?

Logread prints the following. Am I correct that MAC= concatenates the target MAC and source MAC? It sure looks like it.

Fri Dec 23 23:49:45 2022 kern.warn kernel: [45648.928096] Dnsfilter DNS redirect: IN=dnsfilter OUT= MAC=dc:2c:xx:xx:xx:xx:88:c9:xx:xx:xx:xx:08:00:45:00:00:41 SRC=10.0.30.93 DST=8.8.8.8 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=14858 DF PROTO=UDP SPT=56244 DPT=53 LEN=45
Fri Dec 23 23:49:45 2022 kern.warn kernel: [45648.947734] Dnsfilter masquerade DNS: IN=dnsfilter OUT=dnsfilter MAC=dc:2c:xx:xx:xx:xx:88:c9:xx:xx:xx:xx:08:00:45:00:00:41 SRC=10.0.30.93 DST=10.0.30.7 LEN=65 TOS=0x00 PREC=0x00 TTL=63 ID=14858 DF PROTO=UDP SPT=56244 DPT=53 LEN=45

Right at that same time I am seeing that query denied by AdGuard, and seemingly coming from the router of course:

Did you reset the TV?
Maybe it still remembers it for some reason.
If the AGH is in another network from the TV, then you don't need to do the SNAT, so the original IP will show in AGH.