my question to you - when and how often would the DNS name would be resolved? And what if you have thousand firewall rules?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
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.Hello normis
i mean the RouterOs should accept not only ip address in firewall it should be accept the hots name.
instead of dst add=22.214.171.124 the routeros should accept dst add=www.xyz.com
Rely upon the existing DNS Cache and existing Caching function of RouterOS running on the router itself.DNS names should be resolved against a DNS server. When and how often would RouterOS do it?
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?Wish granted:
/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
That's over 2 years in ROS.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
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 cachewiki.example.com
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)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.
Wait a moment! I use it all the time, for many different purposes!I think your use case is rarely used( most people i saw implement it use ip addresses instead of hostnames)
OK this makes sense.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.
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 meanFor that, there is a separate firewall rule to add an address to the list when it matches certain criteria.
processors.wiki.ti.com. 3600 IN CNAME san1.ti.com.edgekey.net. san1.ti.com.edgekey.net. 20291 IN CNAME e7772.g.akamaiedge.net. e7772.g.akamaiedge.net. 20 IN A 126.96.36.199
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 IPsThat 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, 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 IPsAkamai 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.
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)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.
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.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
add action=dst-nat chain=dstnat dst-port=53 protocol=udp to-addresses=188.8.131.52 to-ports=5353
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.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 184.108.40.206: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.
hmmm, right now i have the dst-nat to the opendns server (220.127.116.11 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: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.
..., so obviously my ISP is using dst-nat to redirect all request on port 53 to their own servers, ...
So the question is, does router really connect to 18.104.22.168? If the first quote is correct, it doesn't.- router has 22.214.171.124 (on port 53) as a resolver from the router dns settings(obviously not dst-nated) so it connect to 126.96.36.199 directly through the 53 port
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.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,
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..., so obviously my ISP is using dst-nat to redirect all request on port 53 to their own servers, ...So the question is, does router really connect to 188.8.131.52? If the first quote is correct, it doesn't.- router has 184.108.40.206 (on port 53) as a resolver from the router dns settings(obviously not dst-nated) so it connect to 220.127.116.11 directly through the 53 port
/ip firewall nat chain=output dst-address=18.104.22.168 dst-port=53 action=dst-nat to-ports=5353
/ip dns set servers=22.214.171.124:5353