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

[Andrew Sullivan]

Hi,

On Wed, Nov 29, 2017 at 06:14:48AM +0100, Giovane C. M. Moura wrote:
> 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).

This is true, but it's also true that, if example.nl is under attack
one of their most useful things to do is change their NS set, possibly
many times.  (That is, one possible mitigation is to start
fast-fluxing the NS set for the target domain, so that a large DDoS
doesn't have time to get going and, if it does, doesn't take the
service offline consistently.)  There are already reports of people
having tried this.

But it only works if the parent NS set doesn't persist too long.  Most
TLD operators won't allow the registrar (presumably at the command of
the regisrant) to set the parent-side NS RRset TTL lower than the
registry operator's default (indeed, I'm unaware of anyone who permits
this[1]), so domain operators have to rely on caches not caching the
parent side records too long.  Most resolver operators don't have an
incentive to do this, but AWS does because their clients are
self-serve.  If the resolver doesn't turn down the TTL from the parent
side pretty aggressively, the old parent-side NS set lives too long.
This could be solved by being child-sticky, but I have recently
learned that certain large operators seem to have reverted to
parent-sticky for these records.  Maybe AWS's resolver of choice is
among them.

Best regards,

A

[1] it has occurred to me that this is a possible product offering
that registries could develop: sell lower TTLs on the parent side.
The reason to charge for this of course is that it increases registry
costs.  I don't think it would be hard to run this idea through the
ICANN RSEP process, but I've been wrong about that before :)

-- 
Andrew Sullivan
ajs at anvilwalrusden.com