its very great feature if the routerOs v 4.x has firewall src add and dst based on IP address and host name like (src add=scs.msg.yahoo.com) and the routerOs resolve the host name to its IP address automatically because some server don't has static IP

its very great feature if the routerOs v 4.x has firewall src add and dst based on IP address and host name like (src add=scs.msg.yahoo.com) and the routerOs resolve the host name to its IP address automatically because some server don't has static IP

my question to you - when and how often would the DNS name would be resolved? And what if you have thousand firewall rules?

Hello normis

i mean the RouterOs should accept not only ip address in firewall it should be accept the hots name.
for example
instead of dst add=62.13.211.12 the routeros should accept dst add=www.xyz.com

Remember that DNS is just for our convenience. The IP address is the only absolute value of any address so it's best to pre-resolve the address with scripts.

At least that's how I see it.

Hello normis

i mean the RouterOs should accept not only ip address in firewall it should be accept the hots name.
for example
instead of dst add=62.13.211.12 the routeros should accept dst add=www.xyz.com

you didn't understand my question. DNS names should be resolved against a DNS server. When and how often would RouterOS do it? It would take a LOT of resources if you have many rules.

DNS names should be resolved against a DNS server. When and how often would RouterOS do it?

Rely upon the existing DNS Cache and existing Caching function of RouterOS running on the router itself.

Presumably the TTL of the DNS record influences how often re-resolution occurs.

To conserve resources FW Rules could limit access to that DNS Cache if desired to a limited set of ip blocks, or just the router itself. And, you would want to limit the use of such a feature.

Hi,
I would like to resurrect this old thread instead of opening a new feature request
I'm currently using host based firewall rules to route specific sites to a VPN interface instead of routing everything.
the mikrotik wiki has a script to achieve this( a bit of a dirty solution but it works)
https://wiki.mikrotik.com/wiki/Use_host ... wall_rules

I used another script from here : http://wiki.azotel.com/mikrotik-use-hos ... e-firewall
I think it's better than the wiki script, it uses the dns cache to update the address list and then i use the address list in the mangle to route the traffic through vpn's route, it can handle websites with multiple IPs well.
I still consider it a dirty solution especially since I have to schedule the script(instead of relying on the DNS record TTL) and the address list will be filled with IP's
I think that RouterOS firewall should handle host names out of the box without scripts, this will be useful when routing specific sites or blocking sites in kid control.
the solution I have in mind is you just add the host name in the dst address(dst host ?) field of a firewall rule and when the user makes a request the firewall should search dns cache for the requested dst ip and if it matches a dst host filed of a specific firewall rule then act accordingly.

Regards

Wish granted:

Do the DNS entries update if the registered IPs change?

Yes, it respects TTL and when it times out, it resolves records again.

Yes, it respects TTL and when it times out, it resolves records again.

Thank you!

Wish granted:

Code: Select all

/ip firewall address-list
add address=www.mikrotik.com list=mikrotik
add address=forum.mikrotik.com list=mikrotik
/ip firewall filter
add action=accept chain=forward dst-address-list=mikrotik

Wow, Didn't think that was already implemented, do you know what was the first version of RouterOS to implement this ? also does this handle sites with multiple IPs?

someone should update the wiki page with this simple solution instead of the script and scheduler solution

Regards

Based on what I have quick access to, it is in 6.36.3 but not in 6.34.2, so between that.

Multiple IP addresses for hostname are supported, although this part may not be completely foolproof for some uses. A site could be giving different addresses to different clients, so if your router would use one dns resolver and connected devices would use another, they can possibly get different addresses for same hostname. And if you'd be using such address list e.g. for blocking or allowing access to something, it could fail. So it's best if all connected devices use router as their dns resolver, to be sure that they have the same data.

There is also quite a low limit on the number of addresses that can be put into a single address list item this way.
(the actual limit depends on the length of the domain name!)
I think this limit is not on the address-list but in the "/ip dns" DNS resolver+cache that is mandatory to use for resolving the DNS name.
Keep that in mind when using this feature e.g. for a blacklist, a whitelist, etc.

Wow, Didn't think that was already implemented, do you know what was the first version of RouterOS to implement this ? also does this handle sites with multiple IPs?
someone should update the wiki page with this simple solution instead of the script and scheduler solution

That's over 2 years in ROS.
search forum: Blocking facebook mikrotik
I think in the release notes that was: dynamic_blacklist

Yes it does handle sites with multiple IPs & IPv6.
Try: tapatalk.com, whatsapp.com

Ok,
After testing, it seems there is one thing missing from this feature which is adding a wildcard hostnames, so instead of adding

wiki.example.com
forums.example.com
blog.example.com

the address list should accept wildcards like .example.com and add dynamic rules to anything in the dns cache and check every so often for new entries in the dns cache

It would require to change how it works. Now you give it hostname and router actively resolves it. It's obvious that it can't try to resolve all possible combinations. So it would have to be as you suggest, not actively resolve anything, only look for what's already in cache. But it wouldn't work for all use cases. For example, I may want to use address list to allow remote access from somewhere and the source will be whatever address some hostname points to. Now it works, but it wouldn't work if addresses would be only taken from cache, because nothing would be resolving the hostname on router, so it wouldn't be cached. Perhaps it could stay as it is now for regular hostnames and what you suggest would be used only for wildcards. But people would have to understand how it works and many wouldn't, so it could be a little confusing.

It would require to change how it works. Now you give it hostname and router actively resolves it. It's obvious that it can't try to resolve all possible combinations. So it would have to be as you suggest, not actively resolve anything, only look for what's already in cache. But it wouldn't work for all use cases. For example, I may want to use address list to allow remote access from somewhere and the source will be whatever address some hostname points to. Now it works, but it wouldn't work if addresses would be only taken from cache, because nothing would be resolving the hostname on router, so it wouldn't be cached. Perhaps it could stay as it is now for regular hostnames and what you suggest would be used only for wildcards. But people would have to understand how it works and many wouldn't, so it could be a little confusing.

Yes, I realize it's a bit hard to implement especially for all use cases, but let's be honest most use cases that use a hostname would be to block a website or route a specific website though a specific interface, I think your use case is rarely used( most people i saw implement it use ip addresses instead of hostnames)
I don't think this is confusing at all it will simply have these rules
1- if the rule doesn't contain wildcard then it will add dynamic addresses to the list with each ip address (A record) (this is the current behavior)
2- if the rules contains a wildcard then it will add dynamic address to the list from the dns cache, now this will add all the records from the cache but what if the user request a new subdomain that is not available in the cache? well, there should be a parameter let's call it "refresh time" based on this the rule will refresh the address from the cache,so new subdomains will be added

for your use case yes it will not work but the old behavior should still work so you can add your subdomains manually, or you can add your dns records as static dns record, or make a script that resolves your hostnames regularly

Another difference (edit: well, it's actually the same principle) is that now it's independent, the address list will have address(es) even when nothing uses router's DNS resolver (device can have e.g. hardcoded 8.8.8.8). It's true that it's not foolproof now either, some sites can have multiple addresses that they give out randomly, so it's not reliable for them if it's like this. Sure, it's possible to solve this by redirecting all DNS queries to router.

So "confusing" may be too strong word, but let's say a little less predictable, with slightly higher chance to not do what's expected. But a way to match all subdomains would be useful, that's true. You have to find a way how to convince MikroTik to come up with something.

I think your use case is rarely used( most people i saw implement it use ip addresses instead of hostnames)

Wait a moment! I use it all the time, for many different purposes!
I cannot help that others type literal IP addresses. DNS is so much more convenient.

W.r.t. your other suggestion: you have to understand that this method of setting up an address list is not at all related to actual traffic.
The DNS queries are made (once everytime the TTL runs down to zero) no matter if there is any related traffic, and any traffic only matches what is in the address list, it does not manage the content.
For that, there is a separate firewall rule to add an address to the list when it matches certain criteria.

W.r.t. your other suggestion: you have to understand that this method of setting up an address list is not at all related to actual traffic.
The DNS queries are made (once everytime the TTL runs down to zero) no matter if there is any related traffic, and any traffic only matches what is in the address list, it does not manage the content.

OK this makes sense.

For that, there is a separate firewall rule to add an address to the list when it matches certain criteria.

I don't understand this statement ? do you mean we can match subdomains using firewall rules and use "add dst to address list" as an action? I don't see how this can be accomplished if that's what you mean

I've face another problem, I'm trying to apply a mangle rule to this site:
http://processors.wiki.ti.com
but I can never get it to work,If I add processors.wiki.ti.com to the address list it adds the ip "23.9.34.154" but if i ping or run dns lookup on the hostname my laptop shows the following: so the ip is "104.90.152.10" I don't understand why i get different IPs from the router vs the laptop(I used the same dns server on both, so if the host has multiple IPs I should have picked the 23.9.34.154 ip in the dns lookup that i made).
Maybe it has something to do with the CNAME record ? and the Address list mechanism doesn't handle CNAME properly ?

That is the issue that Sob mentioned above. You need to carefully read and understand it.
Basically, this method is not going to work for what you want to do unless you use the MikroTik DNS resolver on all your internal systems.
Having "the same DNS server" is NOT going to cut it! You need to have your MikroTik address handed out to your internal systems (e.g. via DHCP) and preferably you also should have a dst-nat rule that redirects all attempts from your internal systems to use other DNS servers.

And even with all that in place, it could fail.

Akamai is CDN, i.e. huge network with servers all over the world, doing load balancing and stuff. Everything is dynamic. Address of given website is CNAME with decent TTL, but target e7772.g.akamaiedge.net really has only 20 seconds TTL. You might get the same address again and usually you will, but there's no guarantee. You mentioned multiple WANs, so if you'd have the same resolver (some public one), but laptop would use one connection to reach it and router another, that could be the reason why you might get different addresses. But it's not the only one.

The best chance is to let laptop use router (and only router, nothing else) as its DNS resolver. Then both router's address list resolution should have the same data as laptop will get. There can still be problems when the address actually changes, because not everything respects TTL to a second.

The whole thing is problematic. If you'd need to just block things, and it would be enough to block https, there's "tls-host" matcher and it works on per-connection basis, so it's reliable (so far, until they come up with encrypted SNI). But it's unusable for routing purposes, because when the info about hostname becomes available, it's already too late to send connection elsewhere. You could use "tls-host" to match first connection, add destination address to list and use that for routing of all following connections. And it would work. Well, sort of. In theory, there could be new address every 20 seconds. And old addresses could be hanging out in your list for too long.

That is the issue that Sob mentioned above. You need to carefully read and understand it.
Basically, this method is not going to work for what you want to do unless you use the MikroTik DNS resolver on all your internal systems.
Having "the same DNS server" is NOT going to cut it! You need to have your MikroTik address handed out to your internal systems (e.g. via DHCP) and preferably you also should have a dst-nat rule that redirects all attempts from your internal systems to use other DNS servers.

And even with all that in place, it could fail.

Yes I already have a dst-nat rule to redirect all dns resquest and my laptop has the router as a dns server and still it gives two different IPs

Akamai is CDN, i.e. huge network with servers all over the world, doing load balancing and stuff. Everything is dynamic. Address of given website is CNAME with decent TTL, but target e7772.g.akamaiedge.net really has only 20 seconds TTL. You might get the same address again and usually you will, but there's no guarantee. You mentioned multiple WANs, so if you'd have the same resolver (some public one), but laptop would use one connection to reach it and router another, that could be the reason why you might get different addresses. But it's not the only one.

The best chance is to let laptop use router (and only router, nothing else) as its DNS resolver. Then both router's address list resolution should have the same data as laptop will get. There can still be problems when the address actually changes, because not everything respects TTL to a second.

Yes, as I replayed pe1chl above, I'm using the router as a DNS resolver and have a Dst-nat rule to redirect all traffic to the opendns servers, and still i get different IPs

The whole thing is problematic. If you'd need to just block things, and it would be enough to block https, there's "tls-host" matcher and it works on per-connection basis, so it's reliable (so far, until they come up with encrypted SNI). But it's unusable for routing purposes, because when the info about hostname becomes available, it's already too late to send connection elsewhere. You could use "tls-host" to match first connection, add destination address to list and use that for routing of all following connections. And it would work. Well, sort of. In theory, there could be new address every 20 seconds. And old addresses could be hanging out in your list for too long.

Unfortunately, my use case involves routing(some websites are blocked for me, i have an OPENVPN client setup in the router but I don't to route everything to it, so i add the blocked sites in the address list and route only them through the VPN)

Regards

What you want to do is not really possible for sites like that.
It would work OK for sites that are hosted on their own server with one or a few IP addresses that are static.
But when it is hosted on a CDN, you will have those issues.
Not only will it fail to catch all possible connections because the content of the addresslist does not closely match the returns fro the DNS resolver, but also it will work too broadly because other clients of the CDN may use the same addresses for different content.

Edit: I did not notice you wrote "dst-nat to opendns resolvers". Of course it will not work then. You need to dstnat to your own router, e.g. 192.168.88.1

I'm using the router as a DNS resolver and have a Dst-nat rule to redirect all traffic to the opendns servers, and still i get different IPs

Sounds contradictory to me. Either the laptop uses router as resolver, i.e. it has router's address as its only resolver, and there's no dstnat. Or you redirect laptop's queries to opendns, because there's no dstnat for queries sent by router (both for own use and on behalf of clients using it as their resolver). Well, technically there's a way to have dstnat for that with one very ugly hack, but I don't suppose you have that.

@pe1chl @Sob I probably should've explained why I'm using dst-nat, the reason is that my ISP is advertising his own dns server that they use to block some sites(e.g protonmail.com resolves to 127.0.0.1) and even if i set another resolver i get the same DNS record, so obviously my ISP is using dst-nat to redirect all request on port 53 to their own servers, and since most operating systems don't allow you to set a resolver with a different port than 53 i had to use a workaround.
I leave the dns settings empty on the routerboard (i.e the clients get the router IP as the only resolver) and then i use a dst-nat rule to redirect all dns request to a dns server with a port different than 53 (208.67.222.222 and port 5353)

Problem is, it doesn't do what you think. You need the router to use the right resolver (i.e. not ISP's) and client to use router (default is 192.168.88.1; you can have different config) as resolver. What actually happens is that when client gets 192.168.88.1 and tries to use it, dstnat forwards all client's queries to 208.67.222.222:5353, so it completely bypasses router as resolver. But the router itself still uses whatever it has in "/ip dns" (so ultimately always ISP's resolver), because dstnat does not apply to router's own output.

There's the ugly hack I mentioned before that can help with that. It really isn't nice, but as a desperate solution it can work.

Problem is, it doesn't do what you think. You need the router to use the right resolver (i.e. not ISP's) and client to use router (default is 192.168.88.1; you can have different config) as resolver. What actually happens is that when client gets 192.168.88.1 and tries to use it, dstnat forwards all client's queries to 208.67.222.222:5353, so it completely bypasses router as resolver. But the router itself still uses whatever it has in "/ip dns" (so ultimately always ISP's resolver), because dstnat does not apply to router's own output.

There's the ugly hack I mentioned before that can help with that. It really isn't nice, but as a desperate solution it can work.

well it works fine for me, I know it doesn't dst-nat the router requests but the important is that it dst-nat all the clients requests so it bypasses the ISP blocking.
I made a quick look at the hack and it looks very convoluted and for my setup not necessary, thanks for the tip though

Regards

I'm not a fan of that hack either. But what I'm trying to say is that as it is now:

- client doesn't use router as resolver
- router doesn't use the same resolver as client

So getting different addresses for same hostname (which uses CDN) is very possible.

I'm not a fan of that hack either. But what I'm trying to say is that as it is now:

- client doesn't use router as resolver
- router doesn't use the same resolver as client

So getting different addresses for same hostname (which uses CDN) is very possible.

hmmm, right now i have the dst-nat to the opendns server (208.67.222.222 and port 5353) and I have added the same resolver in the routerboard dns settings(port 53 of course since it doesn't allow custom ports) so:
- router has 208.67.222.222 (on port 53) as a resolver from the router dns settings(obviously not dst-nated) so it connect to 208.67.222.222 directly through the 53 port
- clients are getting the same resolver 208.67.222.222 (port 53) but when they connect the router use dst-nat to nat their request to 208.67.222.222 (port 5353)
I used the above setup assuming that the opendns resolver has the same records no matter what port i use to connect.
Now I'm still getting different IPs so maybe my assumption is wrong? maybe opendns resolver has different records depending on the port you connect too

If a FQDN resolves into multiple IP addresses (which is customary for some CDNs) and obviously only single IP address is needed to establish connection, it is customary to return IP address in round-robin fashion. Thus subsequent requests to DNS resolver will return different results.
It is vital for the magic to work that result, passed on to LAN client, is exactly the same as what router is supposed to use. And the only way is that clients actually use router as resolver ... this way router will get (and cache) resolved result when client requests one and won't have to resolve it (again) for its own use because result will be already cached and it will be exactly the result used by client.

The issue of course is that he wants to use opendns via port 5353. It is not possible to set that in the route DNS resolver, only the server can be specified and not the port number.
That should really be fixed by MikroTik, but for now he needs to use the ugly hack mentioned by Sob to make that work.

Once the router DNS resolver uses the proper next DNS resolver, the local systems can then use the router DNS resolver (simply by setting it in the DHCP server, or enforced using dst-nat when required), and then there can be some chance that the whole thing is going to work. But it still is not guaranteed, I think.

..., so obviously my ISP is using dst-nat to redirect all request on port 53 to their own servers, ...

- router has 208.67.222.222 (on port 53) as a resolver from the router dns settings(obviously not dst-nated) so it connect to 208.67.222.222 directly through the 53 port

So the question is, does router really connect to 208.67.222.222? If the first quote is correct, it doesn't.

The issue of course is that he wants to use opendns via port 5353. It is not possible to set that in the route DNS resolver, only the server can be specified and not the port number.
That should really be fixed by MikroTik,

That won't be easy to fix, if the routerboard advertises the dns settings with port number to the clients, I don't think operating systems support such functionality (using custom port for the resolver) It is not possible in linux and Android and I don't think it's possible in windows either, I think the only OS that support custom port for resolver is OpenBSD, it could be solved by mikrotik of course by advertising the resolver with normal 53 port and then automatically dst-nating in the router for the custom port, so we're back to square one.

..., so obviously my ISP is using dst-nat to redirect all request on port 53 to their own servers, ...

- router has 208.67.222.222 (on port 53) as a resolver from the router dns settings(obviously not dst-nated) so it connect to 208.67.222.222 directly through the 53 port

So the question is, does router really connect to 208.67.222.222? If the first quote is correct, it doesn't.

Hmmmm, that's probably where my mistake is, so the router is not using the resolver really, I never thought of that, I will try the dst-nat trick and report back

Regards

Regarding your previous reply, your problem is not with clients, the only resolver they should get is 192.168.88.1:53 (or whatever local address your router has, but still with standard port). It's the router that needs to talk to upstream resolver on non-standard port. It's exactly what the ugly hack does.

The proper solution could be either:
a) support for dstnat in output: b) direct support for non-standard ports for DNS: But neither is possible in current RouterOS.