IP filtering based on their domain names

I have a list of domain names whose IPs I want to block.

There's a great entry in the documentation about this.

I have a few questions regarding it:

1. dnsmasq --ipset
It suggests using ipset-dns and dnmasq. However the ipset-dns documentation seems to suggest to not use the project anymore, but instead use dnsmasq with the --ipset option:

This functionality has now been written directly into dnsmasq, which should be much easier to use than this project. See the --ipset option.

I think it's generally better to use fewer tools, especially if the developer suggests it. Can anyone comment on whether the dnsmasq --ipset option is as reliable on openWrt as ipset-dns?

2. DNS hijacking
The documentation suggests doing DNS hijacking (in the introduction). I want to avoid doing this, as DNS hijacking (and any form of DNS filtering) is notoriously easy to bypass by the client. If I perform a domain pre-resolution (run through my list of domain names to block, and populate their ip into ipset), is it reasonable to not do any dns hijacking?

I am guessing there is an issue of the IPs associated to FQDN being changed every now and then. Can this be solved without DNS hijacking? Maybe if I have a domain pre-resolution performed on a cron job? If that is a reasonable solution, is there a way to know how often I should run this?

3. race condition
There are commands to "Resolve race conditions for ipset-dns". I think I can guess what's going on, but can anyone explain, so that I am sure?


1 Like

Well, it works for me.

Not so easy as both DoH and DoT can be blocked.
In any case, we act on the premise that the client is not deliberately trying to bypass restrictions.
Otherwise, everything is pointless since the client can simply use a VPN.

You can preresolve domains, but that won't work with all possible subdomains.
Although, this is not entirely impossible to populate IP sets with other methods.
But it is not trivial and each method has its drawbacks.

If the firewall service starts later than ipset-dns, then the IP sets are missing and ipset-dns fails.
Restarting the firewall service flushes IP sets unless they are stored in the firewall configuration.
Dnsmasq doesn't repopulate IP sets with cached domains upon the firewall service restart.


Thanks a lot for your help.

Excellent write-up, thanks for that. I had most of these issues in mind, but it's great to see a nice, concise list.

Great, I will give that a go. I am comfortable with configuring linux processes directly.

Your following points are interesting, and I am happy to debate that, in case I am missing something:

Well, even if you block these, an untrusted user can simply go to a website like this one and retrieve the IP address of a prohibited domain name. That seems too easy to me, in the sense that a kid with little technical skill can do it.

I am actually working on the premise that the user is trying to bypass restrictions. If that's not the case, I could do a simple domain name filtering, no need to go down to the IP level.

I agree VPNs are a big hole, and obviously we would need to block IPs to all big-name VPNs. It seems reasonably easy to block most of them, but probably impossible to block all of them...

Which means that if we wanted to have a 100% fool-proof solution, we'd need to do whitelisting, not blacklisting.

That's a good point to keep in mind. I feel this problem though is exactly the same as having a list of domain names to block that is not exhaustive. My list missing a domain name that I should exclude is the same as my list missing a subdomain that I should exclude. I just need my list to include bad subdomains as well as bad domain names.

Thanks for pointing this out. This is interesting. If I understood correctly from a cursory reading (not guaranteed, since some of this document went over my head), I do feel it bumps up the complexity quite a bit, for the benefit mainly of being able to have an exclude list that contains only server names, rather than subdomains. And my feeling is that it's probably easier for me to live with it, and simply try to add subdomains in my exclude list.

Thanks for the clear explanation.
If I use dnsmasq --ipset do I have to worry about this race condition as well? Or does dnsmasq handle more gracefully a late start from the firewall?

This is not enough as many domains don't work just by IP.
You need to grant clients administrative privileges to edit their hosts file.
Anyway, you can populate the IP sets beforehand if you consider the issue critical.

That's unfortunate.
I'm afraid, a whitelist of IPs/protocols/ports is the only way to restrict access reliably.

It can provide a minor script optimization on restart/startup, but the main issue remains.

1 Like

Ah, that’s very interesting. I have a big gap in knowledge here then, as I mistakenly thought the process was as simple as a mapping from domain name to IP and then communicating to the IP. Can you elaborate or provide some links that I can read?

I don’t understand why you are talking about the client’s host file. The host file allows the client to map domain name to IP, but how does that help them if I ban the ip on the router?

Ah, too bad, I was hoping that an approach of IP-filtering based on DNS, with blocking VPN would be a reasonable solution (i.e. prevent access to these domain names by a moderately competent, untrusted user). From what you say, that’s not the case. Can you explain how they would bypass my IP-ban and still access the banned sites?

Understood, thank you.

1 Like

There are lots of content delivery type sites that serve resources for hundreds of domain names from the same IP. If you block say a porn site by IP it might also block say an educational site as well. Think of groups like akamai or cloudflare or whatever.


Ah yes, I was aware of that. My thought process on whether that would render my setup unworkable is that it would depend on whether the sites that need to be accessed are sharing IPs with bad ones. My hope is that large sites (for which I want to allow access) tend not to share IPs. If my system blocks small sites, then maybe it’s an acceptable trade-off.

Thanks for explaining, I was worried about missing something else.

Thanks for the links.

I am aware of the fact several domain names share the same IP.
As you said, all methods have downsides, and I am aware this is a big downside of my approach. Whether it will be acceptable will depend on how many sites that should be allowed share IPs with my blocked list. I don’t have a good sense of that. I’ll see how it goes with usage.

Thanks for detailing the other risks (vpn through other protocols, tor, etc). We agree that whitelisting is the only solution against a skilled, untrusted user (and therefore against malware).
Hopefully, the method I implement is good enough against low/moderate skills untrusted user. It’s not clear... Maybe I have to think more on whether whitelisting is tractable.

1 Like

I would consider blocking all internet traffic, and using an HTTP proxy.


These times are over. Unless, you stay with http only.

  1. For https it requires the proxis cert to be installed on the client. Not always possible.
  2. Even then, because of HSTS etc. it will not work in all cases.

Shared IPs you might handle using a whitelist for the "good" domains.


Ah ok, thanks for highlighting this. A proxy seemed a good idea indeed, but HTTPS is obviously a strong requirement.

Ah, that seems interesting. How can I do this? I was planning to use dnsmasq and fw3, do I need another process to do domain whitelisting in the context of an ip filtering?

That is not an issue, if you only require domain filtering.


Non-transparent proxy should work fine for both HTTP and HTTPS.
However it must be configured explicitly on the clients, or provisioned with WPAD/PAC.
And it's limited to HTTP/HTTPS, so filtering other protocols like UDP is a separate problem.

You can populate the IP sets with nomatch entries for the whitelisted domains.


This is not right. If you want to cache or filter on URL you need this. If you want to filter on domain name all you need is to configure explicit proxy on each machine. The client will connect to the proxy and ask the proxy to connect to the given domain name. At this time you can allow or deny.

This is in fact the only effective domain name filtering. I do it at my house for limiting my children's access.


This is very interesting. It sounds like this solution could be the right one for me.

I am comfortable with configuring proxy settings for all my clients (clients are fairly standard mobile devices and desktop so I can just look up for instructions online).

Can you please give more details on the setup you suggest to do this on openWrt? Any tip and trick much appreciated.

Yes, you are correct regarding explicit proxy for domain filtering.

However, I consider DNS-based filtering still to be the best solution.
As it is practically transparent for the clients, and less stress for the router, because otherwise all traffic is also piped thru the proxy software.


Best proxy here is to use "squid" . But it is rather demanding in resources, and not so simple to configure properly.
Check the web for "squid non transparent configuration".


Can you explain why? What can a proxy with no proxy certs installed do, that a combination of dnsmasq/fw3 cannot do? It seems to me that a proxy filtering domain names will have the same challenge as a simple DNS filtering : forbidding VPNs/tor/web proxies, etc...

From reading the link you sent, my understanding is that nomatch simply excludes an IP (or IP range) from the ipset. Also my general understanding of ipset is that it works only with IP. So I do not see how using nomatch can actually help in differentiating two domain names that use the same IP?

To give an example, if domainA is on my allow list, domainB on my exclude list, and they both resolve the the same IP, I do not see how nomatch allow letting one through and not the other?

Thanks for the pointer. It seems indeed that a proxy server is a more involved setup. I will need to figure out first what its advantages are over a simple DNS filtering, to know if it's worth the extra hassle for me.