bump ttl for ns records to 86400 as some registries require this

[nordurljosahvida]

Fixes #1381

[nordurljosahvida]

This should not be destructive in any way for other domain policies but I'd love some input to make absolutely sure no policies for other TLDs get infringed

[JoshData]

👍 We'll leave this up for discussion for a bit. The change seems totally reasonable/fine to me. A one-day TTL for a NS record seem about right.

[hija]

I feel like 24h is quite high if you ever want to change your nameserver from MIAB to another one.
But from my point of view we don't really have a choice if we do not want to distinguish the TTLs between the different TLDs. Maybe that's something we could think about in the future (i.e. for .is domains a higher TTL than for others )... But for now it seems reasonable.

(30.12.2020) Following information is wrong as pointed out by @thomae but left here for the record:

Domain	TTL	📫- Provider?
google.com	5 minutes	✔
yahoo.com	30 minutes	✔
live.com	60 minutes	✔
outlook.com	5 min	✔
aol.com	60 minutes	✔
icloud.com	60 minutes	✔
youtube.com	5 minutes	❌
facebook.com	5 minutes	❌
amazon.com	60 seconds	❌
wikipedia.org	10 minutes	❌
reddit.com	5 minutes	❌

--> Checked with https://mxtoolbox.com/SuperTool.aspx
(Just considering US websites)

So with out 24h TTL we are definitely on the higher end of TTLs.

[thomae]

I get different results when querying SuperTool using the syntax dns:example.org:

Domain	NS Record TTL
google.com	4 days
yahoo.com	48 hrs
live.com	5 min
outlook.com	5 min
aol.com	48 hrs
icloud.com	24 hrs
youtube.com	4 days
facebook.com	48 hrs
amazon.com	60 min
wikipedia.org	24 hrs
reddit.com	48 hrs

[jvolkenant]

I have not had a problem with the current setting running MIAB the last few years. DNS Lookups are cheap (low bandwith and low resources). I rather like that changes are quick to age out with a low TTL.
I would like a way to override this if possible. Perhaps in /etc/mailinabox.conf.

[hija]

I get different results when querying SuperTool using the syntax dns:example.org:

Domain | NS Record TTL

------------- | -------------

google.com | 4 days

yahoo.com | 48 hrs

live.com | 5 min

outlook.com | 5 min

aol.com | 48 hrs

icloud.com | 24 hrs

youtube.com | 4 days

facebook.com | 48 hrs

amazon.com | 60 min

wikipedia.org | 24 hrs

reddit.com | 48 hrs

Well that's embarrassing 😀 I just checked again and did not notice that if you enter a new url (without specifying dns: in the beginning), it looks up the a record instead of the ns record. Don't know how I overlooked that yesterday. Thank's for pointing that out :)

[nordurljosahvida]

I don't think we need to distinguish by tld, i would simply make it 86400 by default and have a checkbox somewhere to "use low TTL for NS records [advanced - only use this if you know what it means and really need it]".

[nomandera]

Is there ever really going to be a burning need for someone to require to make an unplanned sub 24h ns server change?

IMHO document this delay so users know to plan for it, change the TTL and push this.

[nordurljosahvida]

@anoma Yeah if no users really claim this as a necessity we could do as you say and - if anything, to avoid cluttering the UI - make a script under management directory that simply lowers the TTL to 5 minutes, to give migrating users an option to prepare for the migration in advance.

[JoshData]

Thanks for the research everyone. Merging!

[nordurljosahvida]

Thanks!

[User1000001]

Is there ever really going to be a burning need for someone to require to make an unplanned sub 24h ns server change?
IMHO document this delay so users know to plan for it, change the TTL and push this.

As discussed here, I am the user with the burning need for sub 24h ns changes. I use Miab's custom dns api to forward a subdomain to my home server running Nextcloud, which gets a new IP every 24 hours.
I have now temporarily fixed this problem by reverting the TTL to 1800 s. Since this change will be overwritten by the next update, I would really appreciate a permanent solution, e.g., by an entry in the mailinabox.conf. Should I try my luck with a pull request?

[JoshData]

The original issue was about NS records. You are probably talking about A/AAAA record. The fix probably applied to all records inadvertently.

I would accept a PR to make this configurable that way if and only if you also write good documentation for it at https://github.com/mail-in-a-box/mailinabox.email/blob/master/maintenance.html.

[User1000001]

I would accept a PR to make this configurable that way if and only if you also write good documentation for it at https://github.com/mail-in-a-box/mailinabox.email/blob/master/maintenance.html.

I have now created a pull request that hopefully fixes the problem. However, I don't believe that the maintenance guide is the right place to document this. From my point of view, two scripts in tools (something like set_ttl_to_5_minutes.sh and set_ttl_to_1_day.sh) would be better.