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

[Giovane C. M. Moura]

Thanks everyone for their input.

So first of all, a bit of context: my intention is not to bash EC2 (or
any provider), it is actually to understand their design choices. I work
at .nl's  research team (SIDN Labs). We strive to deliver a better
service to our clients, which of course include EC2. Since we control
only our .nl authoritative servers, we need to understand how resolvers
behave in order to improve our services to these resolvers (e.g.: [1]).

Now, I'm also worried about DDoS  attacks against DNS authoritative
servers [2,3]. It's been routinely argued resolver's cache help in
keeping services reachable while auth servers are not available during a
DDoS. For example, if you resolver caches the A record of example.nl,
its clients can still reach example.nl  in regardless of the
availability of the auth servers of .nl (.nl zone has 1hour TTL).

And I wonder how manipulating TTLs on the resolver side can actually be
an issue during a major DDoS attack. I mean, shorter TTLs may lead to
caches on applications/stub resolvers/recursive resolvers to expire much
more quickly, which under normal operations are fine, but we may be
discarding prematurely a valid  answer that could  be an issue during a
major DDoS against authoritative servers (any thoughts on that?).

Again, this is all speculation; as we all know, when you start measuring
DNS in the wild, you see a lot of unexpected behaviors.
I'll do some measurements and get back to the list. And thanks everybody
once again.

/giovane


[1] https://conferences.sigcomm.org/imc/2017/papers/imc17-final12.pdf
[2] https://www.isi.edu/~johnh/PAPERS/Moura16b.pdf
[3] http://www.iepg.org/2017-11-12-iet100/02-moura-iepg-ietf100-overlap.pdf

On 11/28/2017 05:37 PM, Paul Hoffman wrote:
> On 28 Nov 2017, at 7:15, Andrew Sullivan wrote:
> 
>> What's wrong with this?
> 
> In short, what's wrong is that 172800 is so much larger than 60 they 
> seem disconnected.
> 
> Does Amazon caps every TTL at 60? (This might be the case; I don't 
> currently have a way to check)
> 
> 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. And, if the caps
> are not identical for every zone, it could seem punitive to some zone
> operators.
> 
>> 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.
> 
> --Paul Hoffman _______________________________________________ 
> dns-operations mailing list dns-operations at lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
> dns-operations mailing list 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>