But what do those uci commands translate to in term of edits to a config file? Or at least which is the config in question (so I can issue the uci commands and see their effect)?
/etc/init.d/dnsmasq does not look like something I should mess with.
In general, I wish OpenWrt documentation, on providing uci commands guidance, would at least say which config files are being so edited.
Thank you again. Then in terms of config files, I'd be looking at /etc/config/dhcp? (Because pavelgl's answer also connects /etc/config/dhcp with the same LuCI item.)
Yes. I was thinking to myself I would need uci commands if one day I am to automate into scripts any of this extensive setup process. I couldn't automate my finding the right config, opening it, looking it over, etc.
If I enter into LuCI /mediacategory2.com/127.0.0.1, the config receives (shows) list server '/mediacategory2.com/127.0.0.1'.
If I enter into config list server /mediacategory3.com/127.0.0.1 in config, LuCI receives /mediacategory3.com/127.0.0.1.
If I enter into config list address /mediacategory4.com/127.0.0.1, LuCI does not show it that at all.
I have not yet test whether config's list address /mediacategory4.com/127.0.0.1 does what it's supposed to do (block the site) regardless of correlation with LuCI.
Anyway, perhaps list address is deprecated since you last used it insofar as correlation with LuCI goes?
It should fail, that's the whole point of testing for another rogue(?) DHCP server on the network (there must never be more than one (aside from very special, fine-tuned exterprise setups) DHCPd on a physical network, therefore dnsmasq checks before starting up if there already is a(nother) DHCPd running in this network segment and refuses to start up, if there is (unless explicitly forced to ignore that)).
You are mixing options "address" and "server".
If you prefer the vgaetera's solution, do not put any IP address after the domain name.
list address '/mediacategory.com/127.0.0.1
list address '/mediacategory2.com/127.0.0.1'
list address '/mediacategory3.com/127.0.0.1'
list address '/mediacategory4.com/127.0.0.1'
list address '/mediacategory5.com/127.0.0.1'
list server '/mediacategory6.com/'
list server '/mediacategory7.com/'
list server '/mediacategory8.com/'
list server '/mediacategory9.com/'
list server '/mediacategory10.com/'
I cannot duplicate your results. I have entered, per your instructions, this line into /etc/config/dhcp (and did the "restart").
list address '/mediacategory5.com/127.0.0.1'
My result is that I don't get an "Addresses" popup in LuCI at all (like the one in your picture). Thus, no question of "5" showing up there or not.
I could not follow your instructions on using LuCI (for entering hosts) because, again, the "Addresses" popup is not there.
My earlier reply to you was about entering "/mediacategory2.com/127.0.0.1" into LuCI's "DNS forwardings" popup, which is indeed mixing up your instructions with vgaetera's. Sorry about that.
I am using a release 19.07.8 for "ath79". I believe the release simply does not give me "Addresses."
Ok, now I see the confusion. I made the tests with release 21.02. I have another device with release 19.07.8 installed and the corresponding field in LuCI is missing. However the option is available and it works as expected. You could try UCI:
Anyway, the “address” option makes the DNS server to return a specific manually entered IP address, corresponding to the domain name (like in the hosts file as you initially asked). The “server” option forwards the request regarding to that domain name to an external DNS server. If the IP address of the external DNS server is not specified, then the request is dropped with a message, that the domain name cannot be found. So, use the “server” option, which as I see is available in LuCI in release 19.07.8. The other advantage of the "server" option (as was mentioned by vgaetera) is that it will drop also the ipv6 requests.
Great! Thanks again. I am selecting your second to last entry as "solution," for its conspicuous display of the differences between the two approaches.
These exchanges also solved for me the mystery of 19.07.8. I thought 19 could not be the year because it's 21 now. I never suspected that development could have stopped for my model of router!
As a general point, this is close to the various ad-blocking solutions that exist, available openwrt utilities such as "adblock" or external DNS servers such as "pi-hole". These trade effort in setting up for more flexible control. Some browsers have built-in adblocking, but that can't handle this problem.