DNSMasq blocking *.domain

[SharkScout]

When I specify:

config dnsmasq
        list server '/youtube.com/'

It blocks "youtube.com", but not "www.youtube.com".

Openwrt's documentation refers to DNSMasq's man page.

My understanding of dnsmasq's man page does not match with this observation, it says:

-S, --local, --server=[/[]/[domain/]][[#]][@][@[#]]

Specify IP address of upstream servers directly. Setting this flag does not suppress reading of /etc/resolv.conf, use --no-resolv to do that. If one or more optional domains are given, that server is used only for those domains and they are queried only using the specified server. This is intended for private nameservers: if you have a nameserver on your network which deals with names of the form xxx.internal.thekelleys.org.uk at 192.168.1.1 then giving the flag --server=/internal.thekelleys.org.uk/192.168.1.1 will send all queries for internal machines to that nameserver, everything else will go to the servers in /etc/resolv.conf. DNSSEC validation is turned off for such private nameservers, UNLESS a --trust-anchor is specified for the domain in question. An empty domain specification, // has the special meaning of "unqualified names only" ie names without any dots in them. A non-standard port may be specified as part of the IP address using a # character. More than one --server flag is allowed, with repeated domain or ipaddr parts as required.

More specific domains take precedence over less specific domains, so: --server=/google.com/1.2.3.4 --server=/www.google.com/2.3.4.5 will send queries for *.google.com to 1.2.3.4, except *www.google.com, which will go to 2.3.4.5

From this reading, I would expect list server '/youtube.com/' to block any *.youtube.com, including www.youtube.com. It's not the case. What am I missing?

[vgaetera]

Most likely one of the following:

• Local DNS cache or DoH/DoT in the browser/OS.
• Missing or incorrect DNS hijacking on the router.

Troubleshooting:

• OpenWrt making DNS connections on port 53 by itself! - #4 by vgaetera
• "possible DNS-rebind attack detected" - hide for specific domain - #10 by vgaetera

[otnert]

@SharkScout

list server '/youtube.com/'

you need to specify a DNS server to forward requests to, in my case I used to use 127.0.0.1 but somewhere along the line OpenWrt now picks this up, with this in the logs

daemon.warn dnsmasq[16895]: ignoring nameserver 127.0.0.1 - local interface

now I just use an IP address that's not pingable e.g.

/youtube.com/10.1.1.1

It blocks youtube.com & www.youtube.com

[AndrewZ]

See also:

-A, --address=/[/...]/[]

Specify an IP address to return for any host in the given domains. Queries in the domains are never forwarded and always replied to with the specified IP address which may be IPv4 or IPv6. To give both IPv4 and IPv6 addresses for a domain, use repeated --address flags. To include multiple IP addresses for a single query, use --addn-hosts= instead. Note that /etc/hosts and DHCP leases override this for individual names. A common use of this is to redirect the entire doubleclick.net domain to some friendly local web server to avoid banner ads. The domain specification works in the same was as for --server, with the additional facility that /#/ matches any domain. Thus --address=/#/1.2.3.4 will always return 1.2.3.4 for any query not answered from /etc/hosts or DHCP and not sent to an upstream nameserver by a more specific --server directive. As for --server, one or more domains with no address returns a no-such-domain answer, so --address=/example.com/ is equivalent to --server=/example.com/ and returns NXDOMAIN for example.com and all its subdomains. An address specified as '#' translates to the NULL address of 0.0.0.0 and its IPv6 equivalent of :: so --address=/example.com/# will return NULL addresses for example.com and its subdomains. This is partly syntactic sugar for --address=/example.com/0.0.0.0 and --address=/example.com/:: but is also more efficient than including both as separate configuration lines. Note that NULL addresses normally work in the same way as localhost, so beware that clients looking up these names are likely to end up talking to themselves.

[SharkScout]

Thanks @vgaetera @otnert @AndrewZ for the pointers.

just looking back into it the following day, the issue was solved, so this seemed it simply was dns caching (I thought it wasn't because I was careful to empty the cache between testing, but I most likely overlooked something).