We are using Mikrotik CHR as a firewall and its DNS Server as a DNS proxy in our infrastructure. The problem is Mikrotik DNS Server reports it's TTL as domain TTL instead of the real one.
For example if domain example.com has a TTL of 1 hour after 59 minute it reports 1 Minute as the domain TTL and it causes huge increase in our DNS traffic.
There must be an option to choose weather report real TTL or mikrotik TTL in DNS server.

This is the correct behaviour of DNS. When a caching resolver receives a request for a name it does not have in
its cache, it requests the name and puts it in the cache with the TTL that is returned from the originating server
(which can be a caching resolver as well). The TTL then counts down from that value in real time until it is zero,
at which time the record is deleted from the cache. When a client requests the same name shortly before it gets
deleted, it gets a small remaining TTL value returned. When it again requests the name a little later, it is
requested from the upstream by the caching DNS resolver again and the TTL resets to the value returned from the
next upstream resolver.

When that is a caching resolver as well, the same mechanism occurs there and the returned TTL may again be
lower than the specified TTL for the name.

When this behaviour results in unwanted behaviour of your client software, the bug is in the client software.
(e.g. it retrieves the name at startup and records the TTL and then re-requests with that interval without observing
the TTL in later replies. that is bad.)

You are correct, but the problem is DNS server is not usable as a proxy server. Anyway having this option would not hurt anyone.

I don't understand what problem you have. Please elaborate.
The DNS resolver/server works according to standards.
I think it is bad to have options in the software to make it operate in a nonstandard way, as those could be misunderstood and could cause problems when a low TTL is used deliberately (which it often is, on large services that use Geo-aware and System-availability-aware DNS)

It doesn't make sense.

When client first asks CHR, it will get record with e.g. 5 minutes TTL from CHR (because it already had it for 55 minutes). So this client will ask again after 5 minutes. CHR will ask upstream resolver, get new record with 1 hour TTL and return that to client. Another client will get cached record from CHR. So long story short, each client will query CHR once an hour and CHR will query upstream resolver once an hour.

If you'd have your option, first client would ask CHR and would get record with 1 hour TTL. So it would again ask after one hour. And because CHR would have to track the real TTL, it would again ask upstream resolver once an hour.

Where's the difference?

There must be an option to choose weather report real TTL or mikrotik TTL in DNS server.

It is up to domain administrator to decide how long TTL is the best one for her domain. If she has really good reason for setting short TTL then it's probably counter-productive if caching DNS server administrator (e.g. @alli) tries to out-smart her. Because it's quite probable that caching DNS administrator's clients will get in some kind of troubles because of DNS records being cached longer than their intended lifetime.

It is up to domain administrator to decide how long TTL is the best one for her domain. If she has really good reason for setting short TTL then it's probably counter-productive if caching DNS server administrator (e.g. @alli) tries to out-smart her. Because it's quite probable that caching DNS administrator's clients will get in some kind of troubles because of DNS records being cached longer than their intended lifetime.

I'm really confused now. Your first sentence makes it sounds like you want to set a lower DNS TTL than the domain owner specified. Then your second sentence refers ambiguously to a "caching DNS administrator" using a DNS TTL longer than the domain owner specified.

Going back to your original post, it looks like you believe there is a difference between example.com's TTL from their authoritative DNS, and the TTL of the records the Mikrotik has cached. I believe you misunderstand how the caching works. At the time the Mikrotik queried example.com's DNS records, the TTL was part of example.com's DNS response. This is the record and TTL cached by the Mikrotik.

Allowing the Mikrotik to cache DNS records reduces your DNS traffic. It does not increase your DNS traffic.

@tippenring: I'm not admin of RB trying to outsmart DNS domain admin, @alli is. I was just trying to tell him that it's not worth playing with it as potential benefit of doing it is doubtful while possibility to break something for RB's clients is real. I was under impression that @alli tried to force his own TTL (it's not clear to me whether that's shorter or longer than original) to optimize something (again it's not clear to me what's broken according to @alli).

It took me a year to convince Mikrotik that their current implementation of DNS cache is not workable. They have said that they are going to improve it but the is no TTL on that as always with Mikrotik.

Mikrotik was beating my DNS server to death with constant requests for local domains which have a TTL of zero.

I have now a separate DNS server to force DNS cache by Mikrotik, to comply by setting an longer TTL for those local domains.

Mikrotik was beating my DNS server to death with constant requests for local domains which have a TTL of zero.

I have now a separate DNS server to force DNS cache by Mikrotik, to comply by setting an longer TTL for those local domains.

Why do people always expect MikroTik to fix other people's stupid mistakes???
TTL of zero on a DNS reply is simply invalid. Fix the server that sends that.

Mikrotik was beating my DNS server to death with constant requests for local domains which have a TTL of zero.

I have now a separate DNS server to force DNS cache by Mikrotik, to comply by setting an longer TTL for those local domains.

Why do people always expect MikroTik to fix other people's stupid mistakes???
TTL of zero on a DNS reply is simply invalid. Fix the server that sends that.

The problem is not the server sending it but that Mikrotik uses it themselves RouterOS in addresslists with domains. Look in DNS cache how the TTL countdown goes for static domains defined in static DNS.

@tippenring: I'm not admin of RB trying to outsmart DNS domain admin, @alli is.

Dang it. Sorry about that. I don't know why I didn't notice you were not the OP. I read your reply from the context of the OP. No wonder it didn't make sense to me.

The problem is not the server sending it but that Mikrotik uses it themselves RouterOS in addresslists with domains.

As far as I can tell, hostnames in address list work fine. RouterOS sends DNS query, gets address from answer, waits for TTL to go down to zero, then sends another query, etc...

Look in DNS cache how the TTL countdown goes for static domains defined in static DNS.

This seems to be only a display inconsistency in WinBox. E.g. if I create static record with TTL 5 minutes, in WinBox there's 05:00, then it goes down to 04:59, 04:58 and then it resets to 05:00. Sometimes it's down to 04:59 and resets to 05:01. But if I send DNS query to router, I always get response with TTL exactly 5 minutes. So I guess it's just WinBox doing the countdown and it's missing some exception for static records. Possibly a slightly confusing, but no biggie.

TTL of zero on a DNS reply is simply invalid. Fix the server that sends that.

This does happen with RouterOS. As record's TTL in RouterOS cache goes down, when I send query at the right moment, I get answer with zero TTL.

Edit: Zero TTL is not taboo for others either, I can get it for just expiring record from local Unbound or 1.1.1.1 too.

TTL of zero on a DNS reply is simply invalid. Fix the server that sends that.

This does happen with RouterOS. As record's TTL in RouterOS cache goes down, when I send query at the right moment, I get answer with zero TTL.

Edit: Zero TTL is not taboo for others either, I can get it for just expiring record from local Unbound or 1.1.1.1 too.

I am not referring to replies from a caching resolver, but to those DNS servers that always return TTL 0 on every query for local names, so they have to be re-queried every time.

Microsoft (our favourite standards-embrace-and-extend people) have done that for a while, but they have now understood that it was wrong.
Maybe people still running older problems are still affected by it. I don't know if there is a workaround and what it is.
But I don't thing other companies (e.g. MikroTik) should implement workarounds for such things.

Having problems with DNS resolves with zero or very short TTL then Mikrotik could enforce a minimal TTL applied to the cache in RouterOS.

In this way address lists are limited in its frequency sending DNS requests.

This can be set to a fixed time by Mikrotik or made user configurable and being disabled by the user.

Interesting issue(

An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the last update by the client. Newer DNS methods that are part of a disaster recovery (DR) system may have some records deliberately set extremely low on TTL. Look what is ttl and how it works. For example, a 300-second TTL would help key records expire in 5 minutes to help ensure these records are flushed quickly worldwide. Time to live (TTL) or hop limit is a mechanism that limits the lifespan or lifetime of data in a computer or network, you know?) and it could be always stable.