Hello!
I have quite often regsitration losts on my VoIP. I figured out that the provider is changing all the time the IP Address of the VoIP Server. Thus I need to exclude the Provider Domain from the DNS cache. How can I do this? I need to use the mikrotik as DNS server due to the fact, that the DNS Servers are pushed dynamicaly by the Provider.
BR Holger
When your provider changes the IP address frequently he should set a low TTL value on the DNS records,
so the MikroTik will expire the entry from the cache quickly and no issue occurs.
When the provider is clueless and does not want/know to do this, you can set a low cache max TTL in your
DNS service. Unfortunately, only global for all domains. However, in todays internet it does not make much
sense to do long DNS caching anymore, it should be no problem to set it to 00:30:00 or so.
Hello!
I know all this. The IPs TTLs and weightings seems to be wrong. I want to send all DNS queries direct to the ISP DNS and all the rest first to the caching name server. The normal TTL is 1h.
Is there no possibility to force this?
BR Holger
Is it possible to see the priority and the weighting of the records?
When you set the max cache TTL to 00:00:10 or so there should be no issue with caching
and you still have some optimization for stupid software that requests the same DNS name over and over again.
You can see the (remaining) TTL in the cache overview. I do not know what you mean by “weighting” of a DNS record.
I am talking about the SRV record. If there are two or more entries for a canocial name the descission which is taken is made by pritority and weight. → https://en.wikipedia.org/wiki/SRV_record
Ok, but that is not relevant for the problem you brought up. When the TTL is low enough the entry
will disappear from the cache quickly and will be looked up again. Then it should be correct.
Nope! I know that my VoIP Service is some how currupted by wrong DNS entries, The work around is to ask not the mikrotik DNS cache, but the ISP DNS directly. Thus I want a directive to do that only for the VoIP domains. The rest works fine with the “normal” DNS relay. Only if this is not possible with mikrotik, it is necassary to reduce the TTL for all DNS entries dramatically.
As fare as I learned mikrotik lacks this possiblility…
Regardless of the weight, if the provider changes IPs all the time and they don’t have a low enough TTL on their records, it’s not a problem of MikroTik but a problem on their side.
If they change IP so often that will cause you problems due to DNS caching, then everyone would have the same problem regardless of what DNS server they use.
Which lead me to believe that either the ISP is an amateur one that don’t know how to setup their DNS (in which case there’s nothing you can really do except report to them the problem to fix it) or most likely your problem is not DNS related.
Mikrotik DNS cache (no matter how basic or bad it is) will follow whatever TTL they have configured on their records.
SRV weights is irrelevant to Mikrotik. The weight is used by your Voip software/client to do failover essentially.
Are you sure that the problem is DNS related?
Is it possible your VoIP/SIP client/software/device does not properly follow the IP change?
Can you confirm in IP > DNS > Cache that the record does not expire/update itself properly?
I use a custom DDNS setup on Mikrotik with a TTL of 1second for immediate update of my dynamic IPs.
It works flawlessly for over 7 years now. What I mean is that I’ve never had problems with Mikrotik not obeying the TTL as you insinuating.
It used to have issues with static dns records edit/removal not being removed properly from the cache but that’s completely different to your issue.
Either way, what you ask cannot be done in the DNS of Mikrotik directly. The only way I know of in Mikrotik is by using L7 filters. Search the forum, there is a post somewhere explaining in detail how to do it.
I wonder, even if you exclude the domain, and you use another DNS server for it, what will change? If the TTL is not low enough, any DNS server you use will follow whatever the TTL is.
I agree with Cha0s. If it is a DNS problem, it is caused by improper TTL settings on the DNS records by your provider. Let them fix it.
More likely it is a problem with NAT that results from this IP change. NAT is always tricky with VoIP. Use IPv6 whenever possible.
What is the domain name of the records that you think are bad? I would like to do some lookups to see if they really are wrongly
configured. (changing more often than the TTL suggests)
If you add the domain name of the VOIP server to the IP - Firewall - Address-list it will drive your ISP DNS server MAD and the Mikrotik cache only hold that resolved IP for a very very short time.
Just type domain name in the Address field and lets the refreshing begins.
Like others have said, remove or lower the caching feature if you feel the problem is caused by cached DNS records on the MikroTik side.
Additionally you could play with connection tracking timeouts but this is likely going to wreak havoc on your network.
A safer option to prove or disprove it’s a problem with the MikroTik DNS cache would be to set the DNS Server value in /ip dhcp-server network to the upstream DNS server provided by your ISP.
Initially for testing this could be done manually, if it proves to be a working solution create a script that updates the value of the DNS Server on each lease change. I find it hard to believe that your ISP is constantly changing their DNS server IP address though so a static entry likely will suffice. Regardless, the lease script functionality is in 6.39+ so make sure you’re running current code.
Short answer: Mikrotik can’t do what you want. It’s only a simple proxy resolver.
Medium answer: I agree 100% with all of the others who’ve responded. If the ISP is changing their VoIP address in DNS in such a way that it breaks things, then they need to learn what they’re doing and fix it. Caching DNS happens at pretty much every single level of the DNS system, all the way into your own computer. When changing their DNS pointer, they should make sure that the previous IP remains available for at least TTL seconds after they make their change. Period. If it’s something they change frequently, then they should make their TTL something short like 3 minutes.
Any workarounds done on the client side are kludges and should not be necessary.
In the last 24h I forced a TTL of 1sec to all DNS entries and there where no registration losts on my VoIP. So I am pretty sure that the ISPs DNS SRV Records are corrupt regarding TTL, weight, priority.
I am already in discussion with my ISP, but as usual: To get someone on the phone, who is able to follow a discussion like this hard 
…and, if u don’t us their hardware they are very suspisious 
Nerverthe less I send them logs from the packet sniffer, we will c…
And yes, it is a server-side problem and need to be fixed there, BUT until that I have to use this line and I don’t want to drive the ISPs DNS mad, therefore I asked how to send DNS requests for certain domains directly to the DNS of the ISP. I can’t do that on the VoiP client, because the DNS Servers are dynamic (pushed by PPPoE). Ok, that won’t work within the Mikrotik, so i use a TTL of 1sec…
…beside that I tried to write the sniffer log to a Memorystick, without success.
[admin@Router-HH] /disk> print
# NAME LABEL TYPE DISK FREE SIZE
0 disk1 1GB-MEMSTIC fat32 PDU01_1G 71G2.0 968.6MiB 984.0MiB
…that seems ok for me.
I found the disk1 in the files:
[admin@Router-HH] /file> print
# NAME TYPE SIZE CREATION-TIME
0 skins directory jan/01/1970 02:00:01
1 autosupout.rif .rif file 558.5KiB feb/11/2017 20:01:08
2 console-dump.txt .txt file 17.6KiB jul/13/2017 13:51:15
3 disk1 disk jul/15/2017 15:22:39
4 autosupout.old.rif .rif file 477.8KiB jan/30/2017 01:26:03
5 Router-HH-20170314-0153.backup backup 343.5KiB mar/14/2017 02:53:33
6 pub directory jan/25/2017 21:36:16
Within the sniffer i set the file-name to
file-name: /disk1/voip-sniff-ttl-5sec
and
file-name: disk1/voip-sniff-ttl-5sec
without any success. Any hints on that?
BR Holger
Well, there’s a middle-way solution for you, and it’s probably a good step to achieve anyway…
If all of your Mikrotiks are pointing at some centralized caching resolver DNS host that you control, you could implement cache flushes of the SRV records on your DNS host (assuming that it’s BIND or some other fully-featured server).
Having your own centralized on-net caching resolvers would actually be a good thing to implement anyway. Speedy DNS is a key ingredient of a “fast” user experience. Caching DNS at the CPE as a secondary cache behind your own centralized DNS cache will accelerate things because the centralized cache gets filled by requests from users throughout your network, increasing the chance for cache hits. On-net cache hits will be much faster than off-net cache hits (in the case where you’re forwarding cache misses to some public DNS server such as 8.8.8.8 or OpenDNS). These “off-net” caches are going to at least be faster than fully traversing the DNS heirarchy starting at the root would be, but you’re still subject to whatever caching policy is present on those public servers, whereas running a fully independent resolver yourself means that you can control the cache behavior for your network.
I agree with ZeroByte,
Since RouterOS DNS is rather basic (at least) I use a raspberry-pi just for BIND.
It can handle many many DNS requests before exhausting its resources.
This way I have full control (local domains, forwarders, slave zones, etc) of all DNS on my LAN.
It’s not ideal for everyone (you need an extra device) but at least you don’t need a full fledged server box for it (ie: no noise, low power consumption, cheap hardware).
Since I do many DNS transfers etc I need to be able traverse the whole DNS tree to make sure that changes propagate properly.
So I can flush my whole or specific DNS cache on demand to be able to check things right away and not wait for Google or OpenDNS to have their caches expire before I see the changes.
In any case, having a full DNS server brings only positive things to your network
Sure I agree with that, but with the problem posed by the original poster (of which we have seen no evidence and no information allowing us to research it further), it can be helpful to reduce the amount of caching.
Also, in some home routers there are quite serious bugs in the caching resolver implementation. I have not seen examples of that in the MikroTik routers, but for many other home routers it is best not to use the built-in resolver.
Just to be clear - I envisioned the full-featured caching resolver being somewhere at the ISP network core, leaving the ROS local caching resolver doing the grunt work at each site. They’re all pointed at the central cache so that all sites can get speedy DNS for commonly requested RRs, with more chances of cache hits due to the larger number of clients going through the central cache.
Although one might make the argument that in today’s world of geo-distributed load balancing being so ultra-common, that many of the most frequently accessed URLs are in fact going to be short-lived TTL things. (e.g: www.google.com comes back with TTL=300 from ns1.google.com) - thus caching is not going to be as helpful as it once would have been.
Yes, that is what I wanted to hint at in reply #2.
Also, the network is now so fast that trying to save a couple of DNS queries is now no longer as helpful as when we used 28.8 modems and ISDN-2.