Hello!
I have v6.47.6, and Static A type record in DNS like *.example.com, additionally I have there another records at the same domain like a.example.com etc.
Wildcard record does not works.
Regexp goes not solve the issue in view that is has higher priority.
Thank you for advice.
You provided very little information on what you have tried.
Regex can vary substantially between different types (Perl, Posix, etc). Try something like “.*.example.com”. That works for me.
Regex procedured the first it means a.example.com will be never procedures by Mikrotik DNS
There are numerous cases showing that DNS server, built into ROS, is severely limited. It is not a replacement for proper DNS server if anything but limited number of plain simple records are in the play.
In case of wildcard entries … well, it doesn’t work on ROS. Fullstop. Forget about it and move on, no point in bitching around.
There’s no support for wildcard records in RouterOS (not counting regexps, but it has own problems), it’s just the lack of input validation. If you add static record for .example.com, it understands it as single hostname (literally ".example.com"), and if you manage to send such query, you’ll get response. The problem is, it’s useless, because normally nothing will send such query.
Same thing happens with international characters, e.g. you can add ěščřžýáíé.example.net, which you might expect to be internally translated to punycode version ěščřžýáíé.example.net, because why else would RouterOS accept it, right? But it doesn’t happen, it will store exactly what you entered. So useless again.
In fact, it’s even more useless, because RouterOS also lacks support for anything above basic 7-bit ascii, it stores anything else you enter as exact bytes. Additionally, since WinBox doesn’t support Unicode, whatever is stored uses system default single-byte charset, so it differs between different computers. It’s inconsistent even between WinBox and WebFig on same machine. Of course with dns it doesn’t matter, because anything above 7-bit ascii was was already useless, but you can see this behaviour with comments and other texts.
Little optimism please, didn’t we get per-domain forwarding recently? Not exactly perfect, because it requires regexp, and it took ten years, but it’s there. 
That’s not really a problem here, as you can enter punycode, no.
Of course automatic conversion would be nice, but that one is not a deal breaker.
(Correct handling for regexp and higher priority for static records would be really nice, though.)
I didn’t mean it like that, it was just additional example of lack of input validation.
I didn’t say that nobody should make a feature request (not that such request would get my ++ anyway), I just wrote that currently DNS server in ROS is pretty much useless and looking for ways around is futile. One should just deploy proper DNS server on some network gadget (could be anything between Rpi running DNS server in a docker container and full-blown DNS server running on heavy iron).
While it is true that the DNS server in RouterOS is not very well designed, I doubt that the scenario asked above would work well in a standard DNS server.
Concepts like wildcards and CNAMEs are defined in a very strange way in the DNS standard, and usually they won’t work like you want or expect them to do.
It is better to stay away from wildcards, especially directly under the registered domain name (like example.com in this case)…
Wildcards do work with regular servers. If there are records for a.example.com, *.example.com and nothing else under example.com, then queries for a.example.com get data from that and queries for <anything_else>.example.com get data from wildcard record.
I’d agree that it made some things more difficult (like DNSSEC where you also need to prove that some records do not exist), but it was solved and it works. Not that you’d need to worry much about DNSSEC in RouterOS. Except the fact that it directly conflicts with any locally defined records. So if any client actually validated DNSSEC, it would not work. But “luckily” no regular client does that.
And CNAMEs, they also work, it’s just that people sometimes have wrong expectations about them, or don’t understand limitations. What doesn’t work very well is new support for static CNAME records in RouterOS. You can add them and server will return them when asked, no problem there. But if you’d like to use them to “track” some remote hostname (/add cname=forum.mikrotik.com name=mikrotik.alias type=CNAME), it won’t work well, because client will ask for A/AAAA and RouterOS will answer that it doesn’t have data for that.
I did not mean the implementation in RouterOS, I mean “that people sometimes have wrong expectations about them, or don’t understand limitations”.
There are unfortunate limitations and unexpected results which are defined in the standard but do not correspond to reasonable expectations.
For using * or CNAME records on a domain there often is a conflict because there also need to be NS records not matched by those wildcards/CNAMEs and that makes most convenient usages impossible.
Most of time no extra NS records are needed. NS recorss are needed if authoritative DNS server delegates subdomain to a different authoritative server. If first server resolves subdomain by itself, no further NS records are needed. And this is true for any subdomain, doesn’t have to involve wildcards.
But indeed not everything may be covered by a wildcard, some things have to be defined properly.
Here’s example where server resolves subdomain:
example.com. IN SOA ns1.example.com dnsadmin.mail.example.com (
202010251 604800 86400 2419200 604800)
NS ns1.example.com.
NS ns2.example.com.
MX 10 mail.example.com.
ns1 A 192.168.88.101
ns2 A 192.168.188.101
mail A 192.168.88.5
master01.k8 A 192.168.190.11
master02.k8 A 192.168.190.12
master03.k8 A 192.168.190.13
gw.k8 A 192.168.190.10
*.apps.k8 CNAME gw.k8
myapp CNAME myapp.apps.k8
The above may be a typical (not complete) example for a kubernetes cluster k8.example.com.
So when a client requests say A record for master03.k8.example.com, server will hapily resolve it although it’s authoritative “only” for example.com.
At the same time server will resolve e.g. example.apps.k8.example.com as CNAME pointing to gw.k8.example.com. Or myapp.example.com will be resolved to myapp.apps.k8.example.com (which in turn resolves to gw.k8.example.com which finally resolves to IP address … that’s why it’s called recursive resolving).
Another possibility is to delegate apps.k8.example.com (or even k8.example.com) to different DNS server, and in this case complete definition of that subdomain is needed (including SOA and NS records).
Interesting, I have a dynu hostname and c-name it to the cloud name of mikrotik. Are you saying that the IP of dynu will not be updated because when it queries the cloud name it wont get returned the updated information (in other words I will have to put my script back in???)
Actually client asks a series of questions to get to final answer. First question will resolve CNAME to cloudname, independent query will resolve cloudname to IP. Each record will have independent time to live and cloudname can have much shorter one than CNAME, which will result in shorter time when resolution returns wrong IP address in case when your IP address changes.
Hmm crystal mud clear.
So are you saying in the instant the IP address actually changes, the DYNU hostname may not be accurate/updated until 1, 2, 5, 10 minutes after or NEVER.
Is my script required again (I thought using c-name would bypass need for script boohoo)
Not sure what you’re doing, so let’s stick to MT cloud and some third party DNS with CNAME.
So when you have ddns-enabled=yes, then your router will update corresponding DNS entry (xxxxxxxx.sn.mynetname.net) automatically. And that A record comes with TTL of 60 seconds. If some caching DNS server resolves (on behalf of final client) this record, it’s free to cache the result for TTL (i.e. one minute). If your router changes its IP address in the mean time, then clients of that caching DNS server will not know it until TTL of cached result expires.
Another thing is third-party CNAME (e.g. anav.dyndns.org pointing to xxxxx.sn.mynetname.net), which comes with its own TTL. I’d expect such records would have longer TTL because they are not expected to change very often. If a change is planned, then good practice is to shorten TTL to a few hours around 2*TTL before change (and again to a few minutes shortly befire change) so that change propagates faster. After change TTL can be extended again.
So when only IP of your router changes, then TTL of xxxxxx.sn.mynetname.net matters. If you actualy change router (and thus xxxxxxx changes to yyyyyyy), then you have to update the CNAME record and if TTL of that record is much longer, then service (bound to anav.dyndns.org) outage will be longer - up to TTL of CNAME record.