geodns attempts to be helpful and avoids setting short TTLs (such as those typically used for A records) on NS records, and attempts to keep them above 86,400. There are two bugs here:
It is not possible to set TTL on an NS record below 86,400, even though there are good reasons to permit this.
TTL for NS records is not defaulting to the label TTL record, but was defaulting to the zone default TTL record (because it is added in AddLabel). So if the zone default TTL record is set to (e.g.) 5 seconds, (e.g. because apart from the 2 NS records at the apex, the zone consists solely of A records) the NS records would default to 5 seconds.
This can be illustrated by a simple dig NS example.com @127.0.0.1 on the default zonefiles, and seeing that a TTL of 600 is used (despite the attempt to keep them above 86,400), and that adding a TTL of 12,000 in to the NS records fails to remedy the situation.
geodns attempts to be helpful and avoids setting short TTLs (such as those typically used for A records) on
NSrecords, and attempts to keep them above 86,400. There are two bugs here:NSrecord below 86,400, even though there are good reasons to permit this.NSrecords is not defaulting to the label TTL record, but was defaulting to the zone default TTL record (because it is added inAddLabel). So if the zone default TTL record is set to (e.g.) 5 seconds, (e.g. because apart from the 2NSrecords at the apex, the zone consists solely ofArecords) theNSrecords would default to 5 seconds.This can be illustrated by a simple
dig NS example.com @127.0.0.1on the default zonefiles, and seeing that a TTL of 600 is used (despite the attempt to keep them above 86,400), and that adding a TTL of 12,000 in to the NS records fails to remedy the situation.Both issues are fixed by: https://github.com/abh/geodns/pull/82