What is expected to happen?

The issue I am facing:
I'm reviewing the pihole/dnsmasq settings.
During this review I noticed the following in /etc/pihole/dnsmasq.conf:

# Never forward A or AAAA queries for plain names, without
# dots or domain parts, to upstream nameservers. If the name
# is not known from /etc/hosts or DHCP, NXDOMAIN is returned
local=//

# DNS domain for both the DNS and DHCP server
# This DNS domain is purely local. FTL may answer queries from
# /etc/hosts or DHCP but should never forward queries on that
# domain to any upstream servers
domain=lan
local=/lan/

To me this "local=" looks like the same parameter/variable?
What is suppose to happen with this?
Anyone an idea?

My understanding (until now) is that there can be multiple of these local-statements.
And each of these prevents forwarding to the upstream dns servers.
Which in my case means that all requests for one of the vlans ending with lan are not forwarded.
Would this be correct? Anything else I need to be aware of?

For those who are interested and have access:
https://tricorder.pi-hole.net/ArRid1CU/

Details about my system:
Latest pihole v6 running as a docker container with network host mode.

What I have changed since installing Pi-hole:
Added vlans and some other config details.

You have defined your local domain as lan in Pi-hole.

  # The DNS domain used by your Pi-hole.
  #
  # This DNS domain is purely local. FTL may answer queries from its local cache and
  # configuration but *never* forwards any requests upstream *unless* you have
  # configured a dns.revServer exactly for this domain. In the latter case, all queries
  # for this domain are sent exclusively to this server (including reverse lookups).
  #
  # For DHCP, this has two effects; firstly it causes the DHCP server to return the
  # domain to any hosts which request it, and secondly it sets the domain which it is
  # legal for DHCP-configured hosts to claim. The intention is to constrain hostnames so
  # that an untrusted host on the LAN cannot advertise its name via DHCP as e.g.
  # "google.com" and capture traffic not meant for it. If no domain suffix is specified,
  # then any DHCP hostname with a domain part (ie with a period) will be disallowed and
  # logged. If a domain is specified, then hostnames with a domain part are allowed,
  # provided the domain part matches the suffix. In addition, when a suffix is set then
  # hostnames without a domain part have the suffix added as an optional domain part.
  # For instance, we can set domain=mylab.com and have a machine whose DHCP hostname is
  # "laptop". The IP address for that machine is available both as "laptop" and
  # "laptop.mylab.com".
  #
  # You can disable setting a domain by setting this option to an empty string.
  #
  # Possible values are:
  #     <any valid domain>
domain = "lan"

You also have this parameter set:

  # If set, A and AAAA queries for plain names, without dots or domain parts, are never
  # forwarded to upstream nameservers
  domainNeeded = true ### CHANGED, default = false

Thank you for the quick response. And yes - I'm aware of these settings.

However - the question is about the expected end result for pihole v6.

Would this be correct? Anything else I need to be aware of?

Using dnsmasq's local option is not tied to VLANs.
It just means that per dnsmasq's documentation, requests ending in the given domain(s) will never be forwarded upstream:

Also permitted is a -S flag which gives a domain but no IP address; this tells dnsmasq that a domain is local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain to any upstream servers. --local is a synonym for --server to make configuration files clearer in this case.

Yes, dnsmasq would allow that option to appear multiple times, but you must not add them to Pi-hole's dnsmasq.conf.

If you'd want to use local for the domains associated to your VLANs, you want to edit your custom 90-vlan.conf accordingly (hope I remember the name correctly, and also that this was what prompted your question).

You are right - I meant the domain/subnet for a certain vlan.

I'm aware of that - it is indeed added to 90-vlan.conf.

Great memory!!! :partying_face: