This is now 2018. please add this. even windows servers from 2008 has it and its easy to set up in bind.

Come on! Give us TTL control, please, please, please! According to the information on Wikipedia then Plesk was launched 15 years ago.... and still no TTL.

Must Have

wth?
this is out of the question a _must have_.

Why hasn't this started already ? We have 2018, if you want to play with the big guys, this is a must have feature. Look at the RFC's for DNS Servers..there's also no "Minimum TTL" anymore, like you call it in plesk, that's Negative Caching and so on ! PLEASE implement this !

Hello, it's me, 2018.
I was wondering if after all these years you'd like to give me TTL control.
So I can change Time To Live.
They say that Time To Live is supposed to change everything
But I can't do any Time To Live editing.

But seriously, I've been the nagging and disgruntled customer for the past few months and raised the big TTL question with the Plesk support on more than one occasion. From my last correspondence I got this answer from Plesk.

"Our developers are aware of this feature and consider to implement it not earlier than the second half of 2018 since this function requires serious changes in the business logic of the product.
This information is preliminary, the timing, as well as the actual implementation, may change over the time."

So, I'm crossing my fingers that Plesk will implement TTL support in Q3 or Q4 this year.

Please include this functionality.

Need this!!!

And i need text input field for priority and weight if i set SRV Records. Not a dropdown with predefines values.

Thanks

I need This feature.

This feature needs some more attention! This is a foundational component of being on the web. Not supporting TTL limits plesk DNS to only "cheap mass hosting of simple CMS sites". It is not reasonable for medium or large businesses with perhaps multiple applications/servers, sub domains, etc that all have varying requirements to not have control over TTL.

+1

It's 2017.. Please prioritize this feature.

This feature is necessary for us as a multihosting company since .is register requires a minimum TTL for NS records which is 86400 secs (1 day). Their reasoning is the following.

"
"Popular documentation like [RFC 1033] recommended a day for the minimum TTL,
which is now considered too low except for zones with data that vary regularly.
Once a DNS stabilizes, values on the order of 3 or more days are recommended.
It is also recommended that you individually override the TTL on certain RRs
which are often referenced and don't often change to have very large values
(1-2 weeks). Good examples of this are the MX, A, and PTR records of your
mail host(s), the NS records of your zone, and the A records of your nameservers."

and according to RFC1030:

"Most host information does not change much over long time periods. A good way
to set up your TTLs would be to set them at a high value, and then lower the
value if you know a change will be coming soon. You might set most TTLs to
anywhere between a day (86400) and a week (604800). Then, if you know some
data will be changing in the near future, set the TTL for that RR down to a
lower value (an hour to a day) until the change takes place, and then put it
back up to its previous value."

A recent study on DNS performance concludes that

"It is not a good idea to make the TTL values low on NS records, or
for A records for name servers. Doing so would increase the load on the root
and [g]TLD servers by about factor of five and significantly harm DNS scalability."

"

I have a few single subdomains where i maybe need to change the ip quickly (on failure of the server) thus this feature would help a lot. As of now i need to decrease the TTL for the entire domain while only a few subdomains require it. Thus this feature would be more than just nice to have, it would be a real improvment.

would be nice and is quiet easy to implement.

chef.tech-recipes.com. 1 IN A 192.168.5.100 <-- the 1 is the TTL for this record (overwrites SOA)
tech-recipes.com. 1 IN MX 10 mx1.tech-recipes.com. <-- the 1 is the TTL for this record (overwrites SOA)