Why can't I have two records for the same name with different TTLs?

Question

I just renewed my TLS certificates, but I haven't installed the new ones yet. I thought I'd add new TLSA records, lower the TTLs of the old ones, wait a while, then swap the certs out and delete the old records. BIND doesn't seem to like having multiple records with the same name and different TTLs, though: it wrote TTL set to prior TTL to its log and now serves both records with the TTL I gave the first one. I wrote out a quick test zone and ran it through named-compilezone, with the same results:

$TTL 1w

$ORIGIN foo.example.

@                       SOA     bar     hostmaster      (
                                2016020600      1d      3h      1w      1d
                                )

@                       NS      a.ns.example.
@                       NS      b.ns.example.

bar             1w      A       203.0.113.5
bar             1d      A       198.51.100.143

/dev/stdin:11: TTL set to prior TTL (604800)
zone foo.example/IN: loaded serial 2016020600
foo.example.            604800 IN SOA   bar.foo.example. hostmaster.foo.example. 2016020600 86400 10800 604800 86400
foo.example.            604800 IN NS    a.ns.example.
foo.example.            604800 IN NS    b.ns.example.
bar.foo.example.        604800 IN A     198.51.100.143
bar.foo.example.        604800 IN A     203.0.113.5
OK

I've searched RFC 1035 and the BIND manual, but I couldn't find anything saying that records for the same name have to have the same TTL. So what gives?

Answer 1

First off I would ask why you want to do this, what's your use case? There's almost certainly a better way,,,

This has been enforced for a long time now, which is why you get a log message stating which TTL it normalized both records to have (604800 in this case).

The simple reason for this -- and makes complete sense if you think about it -- is so both records are flushed from cache at the same time on a resolving DNS server out on the Internet somewhere, and both are freshly retrieved the next time that A record is asked about in that far-flung place. This is the only control you have as a domain owner over remote DNS caches. If it didn't do that, then your shorter record TTL would be flushed first leaving the longer TTL one in cache all by itself. If this is for a web server, then you just lost redundancy in that far away place because that local DNS server will only return that one A record for the rest of the week. This ultimately leads to erratic behavior that can be hard to troubleshoot.