[dns-operations] EC2 resolver changing TTL on DNS answers?

Andrew Sullivan ajs at anvilwalrusden.com
Tue Nov 28 17:35:11 UTC 2017


On Tue, Nov 28, 2017 at 08:37:29AM -0800, Paul Hoffman wrote:
> In short, what's wrong is that 172800 is so much larger than 60 they seem
> disconnected.

They're both integers ;-)
 
> Does Amazon caps every TTL at 60? (This might be the case; I don't currently
> have a way to check)

Me either, but so what if they do?  Why not?  "Your network, your
rules."

> Making the TTL for NS records for a stable TLD like .nl three-and-a-quarter
> orders of magnitude shorter seems wrong. It says that Amazon believes that
> it knows better than the operator of a stable TLD what the users of that TLD
> would want.

No, it most certainly doesn't.  It says that Amazon believes it knows
better than the operator of the TLD what is best for its own
operation.  If I run a resolver, your TTL is not an instruction to me
on how long my cache should live.  It's information to me on how long
you will wait before you assume I must have expired my cache.  So as
long as I stay inside your guidance, I am doing what you told me.

> And, if the caps are not identical for every zone, it could seem
> punitive to some zone operators.

I don't see how.  Admittedly, my employer charges its customers by the
query, and so it could be _expensive_ for the zone operators so hit.
But that's a risk you take in publishing things on the Internet, I
think.

> > The TTL isn't an instruction, it's a constraint.  "Don't cache longer
> > than $ttl," not, "Cache for $ttl."
> 
> That's completely true, but not all that relevant to "What's wrong with
> this?". When given an option, taking an almost pathological extreme seems
> wrong.

I don't see why.  Amazon has a customer support cost problem: if
anything goes wrong they have to cope with the complaints and costs.
Their resolver environment is subject to a lot of churn anyway, and
given their network presence and size bandwidth has to be nearly free
for them.  Why would they respect long TTLs?

Many of us think that TLDs' TTLs ought to be much shorter than they
are today.  The consequences for TTLs that are long is that changes in
the delegation turn out not to take effect as quickly as people would
like.  In a business like that of Amazon, that's an obvious cost.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com



More information about the dns-operations mailing list