IP Firewall Address list FQDN resolution expiration

So afaik as an undocumented function you can do

/ip firewall address-list
add address=officeX.example.com list=whitelist

And RouterOS will resolve the FQDN name (every X minutes) to a IP address and add it to the address list as a “dynamic” item (actually static, ie not lost on reboot).
If the FQDN address resolves to a new address that IP will be added to the list and the old IP item will be retained.

Together or separately this enables you to do poor man’s “VPN” to ironclad firewall by allowing only traffic in from predefined DynDNS clients. (comparable with port knocking but doesn’t require any client functionality whatsoever.

/ip firewall filter
add action=accept chain=input comment="Allow trusted IP" src-address-list=whitelist

Now you might want to expire the old addresses, so the newly created list items would inherit an expiration (timeout) value (just like they inherit the resolved IP address).

/ip firewall address-list
add address=officeX.example.com list=whitelist timeout=3d00:00:00

however this doesn’t work as hoped (does however work as expected), this will resolve the IP address and add it as a new static address list item but now the FQDN item starts to expire, resulting in 3 days that no new resolvings will be made as the FQDN item has expired and removed (deleted) while the resolved IP address item(s) is retained.

In comparison, this does produce self expiring items (so the functionality is namely there):

/ip firewall filter
add action=add-src-to-address-list address-list=blacklist address-list-timeout=3d chain=input comment="Blacklist most commonly scanned ports" \
    dst-port=20,21-23,25,53,110-111,135,139,143 in-interface=WAN protocol=tcp

Please note that there are critical benefits from generating new address list IP items when the resolution changes, instead of overwriting a single item, and with expiration we could control this depending wether we want a short “single item” list or a long “history” list of items.

Also note that expiring items are lost on RouterOS reboot which isn’t all that proper since they are literally defined to expire later.

https://wiki.mikrotik.com/wiki/Use_host_names_in_firewall_rules
https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Address_list
http://forum.mikrotik.com/t/allow-access-based-on-f-q-d-n-instead-ip/111614/1

It should be all automatic, resolved addresses simply inherit ttl from dns record, disappear when it expires, and system then resolves hostname again.

As literally emphasised above it should absolutely not happen as you describe, as you loose even more control to yet another party in the process you can’t control. (as an example you can use a single dyndns to allot multiple sources) it could be a additional feature (but as Mikrotik isn’t known for implementing misc features we should focus on having the existing functionality working suitably).

Well, it’s possible that I missed your point. I’ll test what happens with entries added with hostname and timeout (I never tested that combination before), maybe it will make things clearer. In any case, my understanding of hostnames in address list is that it’s for tracking current address of given hostname (subject to ttl), it’s a feature that makes sense. I’m not sure what I could do with previous addresses, but I’m not saying that there can’t be some use for that.

I still don’t know if I get it. What confuses me, is that what seems to be description of current state, is not what happens, I mean these parts:



What happens is:

/ip firewall address-list add list=somename address=hostname.example.net

Adds hostname.example.net to list and automatically resolves it based on dns record’s ttl. When this ttl expires, it’s resolved again. When address changes, old one is replaced by new one. Also works when hostname resolves to multiple addresses, all of them are added to list (then then replaced by others, if they change).

/ip firewall address-list add list=somename address=hostname.example.net timeout=1h

Same as previous one, only the whole thing (hostname and resolved addresses) are completely removed after timeout.

/ip firewall address-list add list=somename address=[:resolve hostname.example.net] timeout=1h

Resolves hostname and adds resulting IP address with configured timeout, so it’s a way how to ignore hostname’s ttl and keep whatever address hostname had at the time the command was run. And same as previous one, after timeout it’s all gone. If you want to refresh it with newly resolved addresses, you can do it using scheduled script. Major downside is that there doesn’t seem to be any good way how to make it work for hostnames with multiple addresses.

What am I missing?

Maybe you have a different version, at least long-term (latest, v6.46.8, on Tile, CCR) doesn’t do replacements, only additions, afaik never has nor should. (nor have I seen it happen on any other of the majority of RouterOS platforms).


Only the inital hostname one is removed after timeout (which obviously voids further resolutions).

Just trying to avoid scripting in general and stay native.


That the current functionality of this feature is undocumented, unexpected and less beneficial than it could with some minor standalone tweaks.

I don’t have anything with Tile architecture, but CHR 6.46.8 works exactly as I describe, and it’s the same as any other version I’ve seen. If yours keeps adding new addresses, but old ones (that the hostname no longer resolves to) are not removed, it’s bug. Replacing expired addresses with current ones is desired behaviour, that’s the idea behind hostnames in address list, to track current addresses.

But I do agree that a new option to keep expired addresses a little longer before removing them would be useful. It would make using DNS-based whitelist less problematic than it’s now (see this thread). It could be like this:

/ip firewall address-list add list=test address=ddns.example.net extra-ttl=30s

00:00 - ddns.example.net first resolves to 1.2.3.4 with TTL 60 seconds
00:00 - 1.2.3.4 is addded to list
01:00 - 1.2.3.4 in address list expires
01:00 - ddns.example.net is resolved again and it’s now 2.3.4.5 with TTL 60 seconds
01:00 - 2.3.4.5 is addded to list
01:00 - 1.2.3.4 stays in the list
01:30 - 1.2.3.4 is removed from list
02:00 - ddns.example.net is resolved again …